读书笔记-软件架构师应该知道的97件事【2012-10-15更新】

很不爱看书的一个人，这次改用新的方式，边看边笔记，希望能把书看完吃透！

计划每天10条，最后7条，通过10次来读完此书。言归正传！

 

1、客户需求重于个人简历

        不要追求时尚的技术，以客户的需求为出发点去考虑。脚踏实地的为客户着想，选择正确的解决方案降低项目的压力。

        把客户的长远需求摆在自己的短期利益之上

2、简化根本复杂性，消除偶发复杂性

        “根本复杂性”是指问题是与生俱来的，无法避免的；

        “偶发复杂性”是指在解决根本复杂性的同时衍生出来的问题；

        主要是不要只解决表面的问题，要寻其根源。降低耦合

        解决其根本复杂性以避免偶发复杂性

3、关键问题可能不是出在技术上

        项目的失败，往往不是出在技术上。项目是人来做的，问题往往出在人的身上。对话（沟通）是解决项目过程中问题的重要手段。

        尊重他人，并给与对方足够的信任。沟通的几个技巧：

        a）不要把对话当成对抗

        看到他人的优点，把沟通视作一次学习的机会，降低对方的戒备心理

        b）不要带着情绪与他人沟通

        不要让自己的情绪，影响对方的情绪，误认为你不怀好意

        c）尝试通过沟通设定共同目标

        每个人的性格不一，通过不同的手段来调动大家参与度

        与同事达成一致目标，把解决问题的过程视作一次学习的机会，控制好自己的情绪

4、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格

        提高自己的沟通技巧，帮助大家理解项目的目标

        沟通必须简明清晰。项目初期，尽量能简则简。不要一头扎进WORD中，尝试用图片或白板来表达想法，尽量简单，并记录讨论的结果。

        让项目才参与者尽可能多的了解整个项目。特别是质量控制小组、项目经理等。

        加强沟通的练习，言简意赅的表达观点

5、构架决定性能

        产品的性能是无法通过简单的替换软件，或调优底层架构来改善的，必须在架构设计上投入更多的精力

        架构设计决定了产品性能的极限

6、分析客户需求背后的意义

        不要只简单的根据用户提出的需求来解决问题，要弄清客户需求背后的真正用意。

        弄清客户要求的功能和需求的真正意义。理顺需求的轻重缓急。

        引导客户回答“为什么”，不要跟客户讨论技术问题

7、起立发言

         通过沟通，推销自己的想法。当会议超过2个人时，请起立发言。

         起立是为了增加自信和权威，尽量少有人打断你的发言。更好的利用手语，更所有听众保持视线接触。更好的控制语气、语调、语速。

         提高沟通技巧，请起立发言

8、故障终究会发生

        故障无法避免，通常为了避免一个故障而增加了故障发生的可能性。

        硬件故障，通过增加冗余来避免，但同时增加了新的硬件，带来了新硬件可能的故障

        软件故障，通过监控程序来控制，同时增加了监控程序的故障

        减少故障的发生，或降低故障的影响范围

9、我们常常忽略了自己在判断

        有时候的沟通像是一场谈判，不要像程序员一样，退让。

        把对方的话题引开，让他觉得你现在的方案在很大程度上为其着想

10、量化需求

        现实中很多需求往往都是很含糊的，例如：“灵活”、“可维护”、“易于使用”等等。

        我们可以通过一些简单的量化需求，例如：数量有多少？在什么阶段？有多频繁？不能超过多长时间？增加还是减少？占多大比例？

        对那些无法量化的需求给出范围，例如：上限、下限等

        正确的描述：“必须在1500毫秒内响应用户的输入。在正常负载（定义如下……）的情况下，平均响应时间必须控制在750~1250毫秒之间。由于用户无法识别500毫秒以内的响应，所以我们没必要将响应时间降低到这个范围以下。”

        量化的需求可以很好的帮助开发人员开发，帮助质量人员进行质量控制，帮助客户进行验收等

11、一行代码比五百行架构说明更有价值

        架构设计知识手段，不是目标。我们的目标是建立生产体系，即可执行的代码。

        善于倾听，如果有人对设计提出质疑，那很有可能是设计确实存在问题，或者不够清晰。

        亲自参与的项目要把更多的精力放在编码上

12、不存在放之四海皆准的解决方案

        不存在通用的解决方案

        培养“情境意识”

13、提前关注性能问题

        对性能要求高的项目，性能问题要提前考虑。按敏捷开发的方法来说，最晚要在第三个迭代周期开始。

        提早进行性能测试，解决性能问题

14、架构设计要平衡兼顾多方需求

15、草率提交任务是不负责任的行为

16、不要在一棵树上吊死

17、业务目标至上

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

19、架构师应该亲力亲为

20、持续集成

21、避免进度调整失误

22、取舍的艺术

23、打造数据库堡垒

24、重视不确定性

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

26、让大家学会复用

27、架构里没有大写的“I”

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

29、先尝试后决策

30、掌握业务领域知识

31、程序设计是一种设计

32、让开发人员自己做主

33、时间改变一切

34、设立软件架构专业为时尚早

35、控制项目规模

36、架构师不是演员，是管家

37、软件架构的道德责任

38、摩天大厦不可伸缩

39、混合开发的时代已经来临

40、性能至上

41、留意架构图里的空白区域

42、学习软件专业的行话

43、具体情境决定一切

44、侏儒、精灵、巫师和国王

45、向建筑师学习

46、避免重复

47、欢迎来到现实世界

48、仔细观察，别试图控制一切

49、架构师好比两面神

50、架构师当聚焦于边界和接口