[转]如何做架构设计

[转]如何做架构设计

首先要牢记一条：

“ 不存在一个适用于所有应用的完美架构 ”

如何去选择一个架构模式并不是首要之事，相较之下，搞清楚你想用架构解决什么问题更为重要。花一些时间去理解你所要解决的问题，这样可以帮助你聚焦于架构模式中能真正起作用的那些特性。踏实地按照以下步骤去操作，可以确保你设计的架构是有效的：

• 掌握代码库当前所处的状态
• 标识出你想要解决的问题或者想要优化的代码
• 评估不同的架构模式
• 在做出选择前，先尝试其中一些模式看是否合适
• 为你的应用定义好架构基线，设立好相关的界限
• 回过头看你的架构是否可以有效地解决那些标识出来的问题
• 与时俱进，不断迭代和优化你的架构

定位问题

通常好的架构设计实践所解决的问题主要有两个：缓慢的研发效率、脆弱的代码质量。当你遇到下面这些情况时，就会导致低效的低质：

• 我能难读懂代码库中的代码
• 我改动代码有时会造成原有功能产生 bug
• 我的应用运行时表现地很脆弱
• 我的代码能难被复用
• 我的改动会导致大规模的代码重构
• 我的同事很难并行协同开发
• 我能难给代码写单元测试
• 我的团队很难把一个需求拆解成小的工作项
• 我的应用编译一次要很久

导致这些问题的根本原因通常有两个：强耦合、大类型。
强耦合指代码库中有大量的高度依赖代码，变量、类型、对象直接连接访问，缺少协议和接口，从而导致牵一发而动全身，读懂代码需要完全掌握所有依赖关系。
大类型是指类、结构体、协议或枚举拥有很长的接口定义（属性和方法），对于开发者而言，在已有的类中加方法比重新设计一个类轻松地多，大类型应运而生，导致实现体也很长，问题也就接踵而至。

另外，好的架构可以帮助我们解耦，为应用增加灵活性，变得更敏捷。这样可以使我们快速响应技术和需求上的变化。当你面临如下情况时，就表示当前代码库不够敏捷：

• 我发现自己被一种技术/实现束缚住了
• 我面临着在项目初期做出技术/实现上的重大抉择
• 我发现很难增加功能开关

架构选型

当你定位了问题，接下来就是调研各种架构模式。好消息是，有大量的架构模式可供选择；坏消息是，有大量的架构模式可供选择。事实上，大多数模式彼此之间都非常相似。所以这里的建议是，可以先对你需要使用的特定领域中的架构模式进行分类，把设计思想上比较类似的模式归为一类，然后着重了解每一类中最具代表性的一个。

当你对这些架构模式有了一定了解后，就该做出选择了。老实说，你选择哪种模式并不重要，重要的是你如何将这种模式付诸实践。因为大多数模式只是触及到表层，没有细化到每一层的定义，选择“正确的”架构并不能让你自动获得良好架构的代码库。决定使用哪种模式的最佳方法是在代码库中多尝试几种模式，这将为你提供关于该模式是否能满足需求的最宝贵信息。另外也不要忽略人的因素，团队有多大？成员的开发经验如何？他们的偏好？是否有时间限制？这些都要考虑进去。这里有一些问题可以帮助你做尝试和选择：

• 你最终会产出很多样板代码吗？如果是，它们是否至少让代码更容易读懂？
• 你最终会产出很多只是把方法调用代理到其他对象的“空”文件吗？
• 这个模式是否很难被理解？
• 你需要进行多少重构才能应用该模式？
• 这个模式是否添加了很多新概念和词汇？
• 你是否需要导入一个库来应用该模式？

这些问题并不代表是坏事，它们只是帮助你去思考。最后请记住，架构设计与其说是科学，不如说是一门艺术。请不断去实践、学习和创新。有很多好的架构方法，也有很多不是那么好的方法，但没有所谓正确的方法。

付诸实践

每个模式都有各自不同的设计思路和细节，如何进行实践，你就起了决定性作用。这里再重复一次最重要的事：这是一门艺术。所以请放开你的想象力，不断去尝试、总结和学习。当然，在实践过程中，有一些我们需要普遍关注的东西，这里罗列了一些：

• 解耦 不管你使用哪种模式，请确保你的代码被分解成小的、松耦合的片段。
• 内聚 确保你的类型具有高内聚性。如果你定义的小类型具有非常专一的职责，那就可能表现出高度的凝聚力。
• 模块 确保你的应用被分解成多个模块。
• 依赖 确保你使用了类似依赖注入 (Dependency Injection)、服务定位 (Service Locators) 等这样的模式来管理对象之间的依赖关系。

最后，愿架构之神保佑，让这些年轻的架构师，把自己的艺术生命绽放在代码上。