软件架构师应该知道的97件事 笔记(二)

16. 不要在一棵树上吊死

没有什么架构、策略、观点能解决所有的业务问题，我们要承认世界是混乱的，解决方案也是多样的、不一致的等。

 

17. 业务目标至上

架构师必须成为业务部门和技术部门之间沟通的桥梁，兼顾双方的利益，用业务目标来驱动项目开发。

架构师要评估项目商业价值，以高的投资回报率作为目录，避免作出错误的技术决策。要谨慎的站在业务团队一边，用业务目标驱动项目开发，才能保证软件开发团队的长远利益。

在软件形成产品过程中，需要持续的根据反馈制定决策，软件开发人员可以制定微观技术决策，业务决策由业务部门来制定。

 

18. 先确保解决方案简单可用，再考虑通用性和复用性

一味强调通用性而不考虑具体应用，会导致许多令人困惑的可选项和不确定因素。多余的功能往往被闲置或被误用。如果有多个可选解决方案时，“先简单后通用”

开始就追求理论上的通用性，往往会导致解决方案脱离实际的开发目标。而且这种理论上的通用性往往是基于错误的假设之上的，所以无法提供有价值的方案，只会带来问题。通用性而来于对需求的理解，理解之后才能简化。

 

19. 架构师应该亲力亲为

称职的架构师即要懂技术，才能代表技术团队发言，又要懂业务知识，才能督促技术团队满足业务需求。而且应该能通过示范领导团队，能够胜任团队的所有工作，从网络布线，到配置，从单元测试代码编写，到进行测试工作等。还要有能力发现问题所在，向大家解释问题产生的原因，或者给出解决方案。

架构师应该尽早的参与项目，与团队成员并肩作战，对细节的关注程度往往决定了项目的质量。遇到难题不要仅仅扔给别人，可以亲自动手研究或者咨询其他优秀架构师的意见。

 

20. 持续集成

源码的提交或变更触发工具对项目进行自动构建、自动测试，反馈结果。

 

21. 避免进度调整失误

欲速则不达,赶进度会引发很多问题，如拙劣的设计、蹩脚的文档，可能引发的质量问题，仓促完成的代码Bug数量也会显著的增加。

作为架构师应该避免赶进度的情况，如果一定要提前发布，则尝试去掉一些不重要的功能，待后续版本再加入。

 

22. 取舍的艺术

鱼和熊掌不可兼得，没有十全十美的设计：高性能、高可用性、高安全性而且高度抽象。也不要妄想将所有的需求都实现。

架构权衡分析方法(Architecture Tradeoff Analysis Method, ATAM)、成本收益分析方法(Cost Benefit Analysis Method, CBAM)都是帮助架构师做出取舍的工具。

 

23. 打造数据库堡垒

不管业务如何发展、人员如何变动，数据总是不变的，且会永远保存下来，所以创建牢固的数据模型要从第一天开始。数据库的出错是灾难性的，一旦数据被破坏，即使后面修复了数据层的设计问题，丢失的数据也无法恢复了。

要充分发挥关系型数据库的作用，让它成为应用的一部分，从开始构建数据库时，就要深刻地理解业务需求。虽然普通开发方法中敏捷被证明是非常好的方法，但对数据库的设计还是要保守，开始之前要认真设计。

 

24. 重视不确定性

在设计过程中，面对多种可能方案举棋不定时，要仔细考虑采用哪一种方案，或者推迟决定，当收集到更多的信息时，再做出后续的更好的选择。但也不能太迟，要赶在这些信息失效前利用它们。

如果对着代码反复琢磨但仍无法决定采用哪种实现方式时，实现时设法利用分离或封装将决策和最终依赖于决策的代码隔离开，这样在决策变更时可以尽量降低成本。优秀的架构会把这个变更成本降的尽量低。

 

25. 不要轻易放过不起眼的问题

莫非法则: 凡事只要有可能出错，那就一定会出错。

不要忽视小的问题，有可能到后面会演变为重大的灾难。团队的每个人通常关注点不同，当别人提出问题时，要尽量重视。

每个人身上都存在自己难以识别和接受的盲点和不足，所以有”不妥“的感觉时，放大这种感觉，重视起来。

 

26. 让大家学会复用

让大家知道你的框架、库或设计，然后让大家知道它如何使用。

一般有经验的人都喜欢寻找已有的解决方案。

 

27. 架构里没有大写的"I"

架构师不能自负，别人批评我们的设计时，要学会接受与学习。

要避免认为自己比客户更懂需求或把开发人员当作资源，要与客户密切合作，驱动架构的是需求，要重视团队合作，架构是属于团队的，经常检查自己的工作以及反省自己，要杜绝“自我意识”引发的一些常见问题。

 

28. 使用“一千英尺高”的视图

要判断软件的质量，从架构图上看不清楚，太过抽象，从源码上看又容易迷失自我，细节太多。选取一个介于两者之间的视图，即能包含足够的信息，又不至于陷于细节的泥沼之中。

 

29. 先尝试后决策

越晚决策，可利用的信息就越多，但多并不意味着足够。完美的决策只可能出现在事后。

在制定决策之前，可以和开发人员商讨解决方案，然后尝试一段时间，在决策点临近时，再根据尝试的结果作出较优的决策。

尝试多种方案看似浪费时间，但实际上可能是代价最低的选择。

 

30. 掌握业务领域知识

掌握业务领域知识，有助于选择合适的架构模式，而且可以更好的制定未来的扩展适应不断变化的产业趋势。还能自如地运用企业高管和用户熟悉的行业术语与他们沟通。