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. 掌握业务领域知识

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