#核心观点梳理
##现阶段的主流软件开发技术
- Rails
- Java EE平台。值得一提的是Java VM已经成为一种新的宿主平台，Scala、JRuby更为活跃并引人瞩目
- LAMP平台。Linux/MySQL/Apache并没有多少变化，PHP社区从Rails社区获得了不少养分，出现了许多更加优秀的开发框架
- Microsoft .NET平台
- Django
这里列举的主要都是与Web开发技术，不得不承认Web开发才是当前软件开发的主要需求，无论一些大型的企业级的ERP,CRM系统以及其他管理系统，传统的电子商务站点构建，或者小型的各种Android,iOS应用引入WebView，都与之相关。而且随着JavaScript能力的增强，可以畅想一下未来Web技术是否有可能在一定程度上侵入到如今桌面软件的阵地。
##项目构建时间过长的解决方案
本地构建超过5分钟的时候就变得难以忍受；大多数情况下你希望这个反馈时间越短越好。
- 升级工作环境
- 分阶段构建
- 分布式构建
- 采用JRebel或者Spork
##架构腐化的原因
规模的变大才是导致架构腐化的根源
人们喜欢简洁。但这更多的看起来是一个谎言——没有多少团队能够自始至终保持简洁。人们喜欢简洁只是因为这个难以做到。并不是说人们不愿意如此。很多人都知道软件开发不比其他的劳动力密集型的行业——人越多，产量越大。《人月神话》中已经提到，项目增加更多的人，在提升工作产出的同时，也产生了混乱。短期内，这些混乱能够被团队通过各种形式消化；但从长期看来，随着团队人员的变动（新人加入，老人离开），以及人正常自然的遗忘曲线，代码库会逐渐失控，混乱无法被消化，而项目并不会停止，新功能不断的加入，架构就在一天天的过程中被腐蚀。
人的理解总有一个边界，而需求和功能不会——今天的功能总比昨天的多；这个版本的功能总比上个版本的多。而在长时间的开发中，忘记之前的代码是正常的；忘记某些约定也是正常的。形成某些小而不经意的错误是正常的，在巨大的代码库中，这些小错误被忽视也是正常的。这些不断积攒的小小的不一致、错误，随着时间的积累，最终变得难以控制。
##架构腐化的解决方案
解决方案的终极目标是：在混乱发生之前，在我们的认知出现障碍之前，就将项目的规模控制在一定范围之内。
###1.采用新技术
充分吸收现有各开源项目的经验
###2.重构到物理隔离的组件
很多常规的策略往往是针对组织的：例如将代码库按照功能模块划分（例如ABC功能之类）或者按层次划分（例如持久层、表现层），但这些拆分之后的项目依然存在于开发人员的工作空间中。无论项目如何组织，开发者都需要打开所有的项目才能完成编译和运行过程。我曾经见到一个团队需要在Visual Studio中打开120个项目；我自己也经历过需要在Eclipse中打开72个项目才能完成编译。
- 解决方案是物理隔离这些组件
就像团队在使用Spring / Hibernate /Asp.NET MVC / ActiveRecord这些库的时候，不用将它们对应的源代码放到工作空间进行编译一样。团队也可以将稳定工作的代码单元整理出来形成对应的库，标记版本然后直接引用二进制文件。
或者可以引入包管理系统，二进制化已经稳定的代码。
- 对各模块进行版本控制而不是对整个项目进行版本控制
###3.将独立的模块放入独立的进程
这种方案更多的是要对系统进行面向业务层面的思考。
充分利用多核环境的优势，多进程能够简单并且显著地利用多核能力。
###4.形成高度松散耦合的平台+应用
以Facabook App为例，介绍了系统层次的松散耦合方案。利用HTTP和JSON传递信息。
##结语
###1.没有糟糕的架构，变化使之
###2.关于文档
依赖隔离，各模块独立文档
###3.创建应用程序的生态环境，而非单一的项目
是创建一个日益庞大的、缓慢的、毫无生机的产品，还是将其有机分解，成为一个生机勃勃的具有不同依赖的生态系统?
#值得考虑的评论
分解，分解以进一步分解
想要实现项目的分拆，架构的分拆，实现模块的解耦，彻底的解耦，不仅仅是代码的解耦。是那种可以独立升级，独立维护，独立部署的解耦。是一种调用关系的解耦，通信解耦。不能项目之间进行引用，模块之间的通信要使用JSON，或者是REST，之类的基于某种格式的的通信。
另一种视角
作者的观点简言之就是在规模扩大时没有适当适时分解。但后面的原因呢？难道都是维护架构演进的负责人傲慢或者愚蠢吗？ 这样推断当然省事，但真的不解决问题。
我的观点，架构适应性大部分是水面下的“内部质量”，在内部质量不怎么可见，在外部质量（需求符合度）还凑合的情况下，项目投资者不太愿意投入更多资源在维护架构上，架构演进的负责人需要克服这种倾向，需要清晰的理念，坚定的执行，和有效说服的技巧。
很多情况更糟，项目或产品的外部环境就决定了这个项目或产品的短期行为。那些为政府镀金的项目哪需要什么长期维护啊？到时候重新做一个还能重复赚钱呢。按人月付费的项目也没有改良的冲动，最好产品需要更多人维护，只要糊弄得了客户，或者糊弄得了客户的上头就可以了。上述这些项目的架构负责人，需要多大的理想主义的支持，才能做好架构的维护呢？
所以最初要弄清楚对于架构的真正的需求： 假设是不需要长期维护的架构，就别折腾吧，一个支持事务脚本的贫血模型，包含一切的大项目，一堆lib方式复用的组件，一队毕业生劳力，足矣。架构的腐化就忍受吧。 精力放在理解业务和搞定客户上，更有利于个人价值的增值。如果不能忍受，请考虑去另外类型的项目组吧。
