架构之美--“混乱大都市”“设计之城”

“混乱大都市”

1、不好的公司结构和不健康的开发过程将在糟糕的软件架构中得到反映。

2、重要的是要保持软件设计的品质。坏的架构设计会招致更坏的架构设计。

3、开发团队中健康的工作关系将直接有益于软件设计。不健康的关系和个性膨胀会导致不健康的软件。

4、好的设计考虑到内部组件连接的连接机制和连接数（以及连接性质）。系统的单个部分应该能够独立存在。紧耦合将导致不可测试的代码。

5、松弛而模糊的架构将导致每个代码组件编写得不好，并且相互之间匹配得不好。它也会导致重复的代码和工作。

6、不良架构的影响不仅限于代码。它会进一步影响到人、团队、过程和时间表。

7、重要的是要在开始设计系统之前知道你打算设计什么。如果你不知道它是什么，也不知道它将做什么，暂时不要开始设计它。只设计你知道需要的东西。

 

不良的架构会产生深远的影响和严重的反弹。在“混乱大都市”中缺少预见性和架构设计，导致了下面的问题：
• 低品质的软件和漫长的版本发布周期。
• 系统没有弹性，不能够适应变更或添加新的功能。
• 无处不在的代码问题。
• 员工问题（压力大、士气低、跳槽等）。
• 大量混乱的公司内部政治。
• 公司不能成功。
• 许多痛苦和面对代码深夜加班。

“设计之城”

1、架构有助于定位功能：添加功能、修改功能或修复缺陷。它为你提供了一个模板，让你将工作纳入到一张系统导航图中。

2、清晰的架构设计将导致一致的系统。所有决定都应该在架构设计的背景下做出。

3、清晰的架构有助于减少功能重复。

4、软件架构不是一成不变的。需要时就改变它。要想做到可以修改，架构就必须保持简单。牺牲简单性的修改要抵制。

5、延迟设计决定，直到你必须做出这些决定为止。不要在你还不知道需求的时候就做出架构决定。不要猜测。

6、必须保持架构品质。只有当开发者们相信它并对它负责时，才能做到这一点。

7、你的系统应该有一组不错的自动化测试，它们让你在进行根本的架构变更时风险最小。这为你提供了工作的空间。

8、对你的代码进行单元测试将带来更好的软件设计，所以设计时要考虑可测试性。

9、好的项目计划将带来优质的设计。分配足够的时间来创建架构杰作，它们不会立即出现。

10、团队的组织方式必然对它产生的代码有影响。随着时间的推移，架构也会影响到团队协作的好坏。当团队瓦解时，代码的交互就很糟糕。当团队协作时，架构就集成得很好。

 

好的架构是很多因素的结果，包括以下方面（但不限于此）：
• 确实进行有意为之的前端设计。（许多项目甚至还没开始，就因为这一点而失败了。）
• 设计者的素质和经验。（以前犯过一些错误是有帮助的，这能在下一次为你指出正确方向！“大都市”项目肯定教会了我一些东西。）
• 在开发过程中，保持清晰的设计观点。
• 授权团队负责软件的整体设计，而团队也承担起这一责任。
• 不要害怕改变设计：没有什么是一成不变的。
• 让合适的人加入到团队中，包括设计者、程序员和经理，确保开发团队的规模合适。确保他们具有健康的工作关系，因为这些关系将不可避免地影响代码的结构。
• 在合适的时候做出设计决定，当你知道所有必要信息时再做出决定。延迟那些暂时不能做出的决定。
• 好的项目管理，以及合适的最后期限。

                                                                                                                                                               

 

                                                                                      乐仔

                                                                                  2010.12.14