“关于架构的讨论：烦人的细节” 读后感
本文先对bob大叔的观点进行了陈述，好的架构让我们直到项目的后期才需要决定使用Rails，或是Spring，或是Hibernate，或是Tomcat，或是MySql等等。好的架构也让我们能够轻松地改变这些决定。而Brown的观点，则与他不同，认为架构不仅仅是包含在“应用程序”中的内容。结构很重要，但是还有很多重要的内容，像非功能性需求、实际的交付机制（技术、框架、工具、 API等等）、基础架构服务（例如：记录日志、异常处理、配置等等）、集成服务（内部和外部的）、满足所有环境的限制（例如：运维和支持）等等。对我来说，所有这一切都与架构相关。
我觉得都有一定的道理，如果是一个成熟的团队，有系统的计划，并且项目比较庞大，那么bob大叔的观点更适合因为他们的合作会使项目一个一个模块更加清晰，而不用担心其他人所负责的模块，只需构造相应的接口，就可以完全的将前台和后台分开，一直也维护起来更加方便，也为因为那些不确定的因素而修改代码提前做好准备。
Bob大叔的结论认：你的架构应该告诉读者与系统相关的内容，而不是你在系统中所使用的框架。也就是说应该首先考虑与用户交互的层面，因为那才是用户直观的感受。
那么如果是个小团队，人手不足，而项目又小，那么按照bob大叔的观点就会很麻烦，此时我更偏向于Brown的观点，一般这种项目的开发过程并不成熟，时间不允许拖，大部分是走一步看一部，那么就需要更早的确定各个模块具体实现的细节，而前台与后台就具有高耦合性，一旦到开发后期再做决定，那么就不便于对之前的代码进行修改，所以需要尽早处理这些烦人的小细节，
Brown认为前台和后台如果没有尽早实现联系，那么一个软件就是虚的，没有脚踏实地，浮于表面，而此时处理数据库这种烦人的小细节就变得异常重要。
Brown的结论是：
1.将应用程序的代码和技术解耦很不错，而且是我们应该尽力做到的。这样得到的代码更易于做单元测试、易于替代、易于维护、易于修改等等。
2.软件架构是与全局相关，而应用程序的代码只是全局中的一部分。
3.如果你仍然把“交付机制”这样的重要决定推迟，并且不考虑如何解决重要的非功能性需求和约束，那么就不得不面临软件项目失败的风险