《架构师应该知道的97件事》阅读体会之一

虽然离架构师还很远，但是团队购买了这本书，这里也大概领会了下，这些言简意赅的原则不仅对于架构师，对于开发人员、项目经理、决策者都是有用的

 

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

不要为了追求技术而技术，为了时髦而时髦，这样做无异于舍本求末、缘木求鱼。忽略了客户最根本的需求，往往让自己境地也很难堪，当我们有能力满足客户的基本需求时，再来谈时髦的技术，因为我们做项目无异于向我们的储钱罐里存钱，只有踏踏实实的完成了，才能作为光鲜的一笔记入简历，积累好我们的信誉。

 

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

 

3.关于沟通：

不要把对话当成对抗

不要带着情绪沟通

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

起立发言：两人以上沟通要起立，不容易被打断。

和上层沟通时要权衡利弊，在最满足基本需求的情况下节省开支，注重谈判技巧。

多方沟通的平衡能力。当被要求增加需求和加快速度时，要坚决拒绝，因为这会造成bug数量增加，增加测试中可能出现的问题，最终引发产品质量问题，解决质量问题的代价会更高。

 

 

4.学会分析客户需求背后的意义

 

有时候需求人员拿出来的需求非常的抽象，感觉没有落到实处，架构师要学会挖掘这背后的意义，定位真正的意义，把最有价值的需求放在第一位。

 

5. 不存在放之四海而皆准的方案,不要在一棵树上吊死

架构师需要情境意识（常识），给定情境下对合理性的把握，胡猜乱想和矫枉过正都是要不得的。

 

世界是复杂的，业务也是复杂的，想找一个一劳永逸的方案，无异于水中捞月，参考ETL实现对数据进行抽取、转换、装载，导入数据是自由的，展现数据也是多样的，能够满足不同的需求，在子系统的设计上，要充分利用非功能性参数的差异性，实现对不同表现形式的管理。

 

6. 先确保方案简单可用，在考虑通用性和复用性

这条我在刚刚做过的设计里深有体会，刚开始就将各个入口统一起来，既满足触发调用，又满足任务调用，结果后来不得不进行特殊的限定，在任务处理时不做哪些操作，在触发时不做哪些操作。

 

在存在多个方案可供选择时，一定要坚持“先简单后通用”的规则，修改简单方案往往比修改通用方案容易很多。

过早脱离具体情况可能导致陷入无限可能的迷宫里

 

7. 对于技术难点等，架构师要亲力亲为，保持和团队紧密合作，不是在象牙塔里发号施令，同时也应该和同行保持紧密的联系。

 

8. 取舍的艺术

没有十全十美的设计，既有高性能，又有高可用性，既安全，又高度抽象（一半来说隔离性好的安全性高，而这又导致你抽象不够，复用性不好）。瑞典国王建造的Vasa号战舰的故事，可以很好的说明这一点，一个没有相关经验的架构师设计出来的意图两用-既能攻击又能运人的东西，可能的结果就是鸣了礼炮以后，直接就沉入水底了。

在设计时，可以通过架构权衡分析方法和成本收益分析方法作出判断。

 

 

 

精益软件开发？