《架构之美》三

在后来的章节中，又介绍了“混乱大都市”和“设计之城”两个项目，将两种比较，形象的说出了好的架构与差的架构的一些特性。“混乱大都市”的最大问题是重复，它没有考虑好软件设计中最关键的品质，内聚和耦合。它的失败经验很值得我们借鉴：缺乏预见性和对架构的整体思考。版本的发布周期过于漫长；系统没有弹性，可扩展性差；代码问题很严重，没有统一的命名规则和命名结构，导致新员工面对复杂的代码结构，感觉压力比较大，从而又造成了员工的跳槽和士气低等问题；团队的内部政治问题严重，没有团结精神，缺少凝聚力。

 相比之下，“设计之城”的成功就是吸取了它的经验教训，从一开始，项目的目标就很明确，在以后的开发过程中的代码必须支持所设定的要完成的功能，这样就形成了一个通用的目标的代码集，在以后的使用过程中可以适用于很多产品的配置。开发团队动态的遵守架构设计，开发人员们密切合作，共同创建一组干净、一致、密切合作的软件。如何Conway法则中所说的，团队的组织方式也如同软件的组织方式；坚持保持品质的信念；

要有单元测试和很好的自动化测试。它的里面提到了一个新的原则：YAGNI（You Aren’t Going To Need It）即在你不需要他的时候，不要急着先去设计它。这大大提高了架构的品质，在设计之初只是设计系统中最重要的部分，余下的部分延迟到需要的时候再进行分析和设计，这样可以很好的解放思想。

 一个好的架构的形成不仅是架构师的功劳，还有团队的集体合作，主要因素：确实进行有意为之的前端设计；设计者有很好的素质和经验；在开发过程中，保持清晰的设计观点；授权团队负责软件的整体设计；不要害怕改变设计；让合适的人加入到团队中，让团队保持健康的工作关系；在合适的时候做出决定；好的项目管理和合适的最后期限。

在后来介绍架构伸缩性的时候以常见的在线游戏的设计为例，这类软件对系统的伸缩性要求很高，要能实时伸缩，减少延时。随即提出了两种解决方案：分区和基于地理位置，每个地理区域的玩家运行在一台服务器上。

    在介绍数据增长对架构影响的时候以以Facebook为例，说明了Facebook的独特平台是如何解决了数据迅速增长的情况下系统的架构是如何维持稳定的。Facebook的独特平台主要是有一下几个部分组成的：

Facebook API是为了实现通过一个外部可以访问的Web服务来提供Facebook数据，实现应用可以利用在Facebook上的用户社会关系数据，但是不能直接访问。

Facebook的FQL的提出是为了解决从其平台API获取数据比获取内部数据的开销大得多的问题，FQL提供的是一种查询服务。类似内部数据采用的模式，实现外部数据访问模式。它能让开发者更快的处理它的请求，能够以比API更好的力度来访问数据，同时保持了SQL类似的语法。

FBML的提出时基于这样一个实际问题：对于社会关系应用来说，要获得引人注目的关键性用户数，支持它的社会关系网络上的用户必须要能注意到其他用户在利用这些应用进行交互；外部应用不能够使用Facebook没有通过Web服务暴露出来的哪些核心数据元素。FBML是一种数据驱动的标记语言，在社会关系站点上创建应用执行和显示的内容，让用户在一个受信任的环境下操作。