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

 

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

不要为了学习新的知识或丰富自己的简历而选择新技术解决问题，要尽量选择切合实际的技术解决客户的难题。

脚踏实地的为客户着想，选择正确的方案可以降低项目的压力，团队工作起来更开心，客户也会更满意，从而你也会有更充裕的时间学习新的知识。

 

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

根本复杂性是问题本身就很复杂，所以它是无法避免的。偶发复杂性是在解决根本复杂性的过程中衍生的，即解决方案本身带来的新问题。

如为了解决某个问题而设计的一个软件框架，设计该框架本身，就是引入的偶发复杂性。所以，如果原本问题比较简单，但设计或引入一个太过灵活的框架，可能得不偿失。(避免过度设计)

 

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

简单的项目也可能会出现问题，这并不是因为我们选错了某种语言或者系统，根本原因还是“人”

所以，要帮助团队完成项目，多与项目成员沟通，及时改正团队成员不正确的工作方式。

沟通的技巧：

a) 不要把对话看成对抗

改变心态，发现他人的优点，把沟通视为请教，就会有所收获，并且能避免引入对方的戒备之心。

b) 不要带着情绪与人沟通

当你处于愤怒、沮丧、烦恼等情绪中时，对方可能会误认为你的举动不怀好意。

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

 

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

架构师要避免只发号施令，让开发人员执行的弊病。要让开发人员了解项目的蓝图和决策过程，让大家共同验证你的架构，让开发人员参与你的架构的制订过程，这样开发人员才能更心甘情愿的去执行。

架构师应该提高自己的沟通技巧，帮助大家快速、精准的理解项目的目标。要言简意赅的表达观点，用简单的图表来表达自己的想法。

用相机拍下自己在向团队成员表叙时在白板上写写画画的想法，会后分享给大家，并且自己好好整理一下。

 

5. 架构决定性能

如果架构有问题，仅仅通过优化局部，不足以获得理想的性能的。找出性能瓶颈，优化瓶颈，如果需要的话，重新设计架构的内在逻辑和部署策略。

 

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

分析客户提的需求，为什么提这样的需求。即要知道客户要求的功能和需求的真正意义，这样或许我们可以在达到客户目的的情况下，采取更简单的办法。

 

7. 起立发言

在多人场合发表意见时，起立发言非常重要，尤其是其他人坐着的时候。站立时，无形中增添了一种权威和自信，容易控制了场面。听众不会轻易打断你的发言。

站立时可以更好的利用肢体语言，且在十人以上的场合，起立发言方便与每位听众保持视线接触。眼神交流和肢体语言等表达在沟通中的作用不可小觎。起立发言也更容易控制语气、语调、语速和嗓门，让声音传播的更远。讲到重点时，注意语速的减缓，发声技巧也能改善沟通效果。

 

8. 故障终究会发生

为了防止A程序出错，增加了监控程序B，但监控程序B本身就可能会出错。所以故障及错误是无法避免的，即要做好错误的防范措施。

 

9. 我们常常忽略了自己在谈判

项目投资人为了削减预算，可能会去掉一些“东西”。当投资人问“我们真的需要这东西吗？” 很多工程师把自己摆在了工程师的位置，会回答一些不使用这些东西的替代方案，但往往这些替代方案是极差的。在投资人看来，有其它方案可选，他不关心是什么方案，他往往会让你去掉这些“东西”。

我们这时应该把自己放到谈判者的角度上，说明不使用该方案的坏处，以及使用该方案的好处。让投资人清楚的认识到该方案的重要性。

 

10. 量化需求

“速度快”、“响应灵敏”都不能算需求，需求一定要可量化。比如响应时间在500ms以内。如果没有这些具体数字，也要有一个描述范围，如上限、下限等。

 

11. 一行代码比500行架构说明更有价值

要牢记我们的目标是可工作的代码，设计只是手段。很多架构师往往被抽象的架构所吸引，沉迷于设计过程。没有天生完美的设计，设计都是在实现过程中逐步完善的。如果有机会亲自开发，珍惜这个机会。

 

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

没有通用的解决方案，遇到的问题也是千差万别，架构师需要运用情境意识来解决问题（类似于常识）。情境意识需要培养和训练，架构师要不断的积累案例和经验才能建立足够的情境意识。要解决系统层次的问题，通常需要十年的磨练。

 

13. 提前关注性能问题

尽早进行性能测试，如果在某个时候性能表现大幅下滑，更容易找到性能下滑是由哪些变化引起的。如果以两周为一个迭代周期，性能测试的开始时间最迟不要晚于第三次迭代。尤其是对性能要求苛刻的系统，验证的早晚直接关系到能否及时交付项目。

 

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

软件架构不仅包含系统建模、定义接口、划分功能模块、大胜模式、性能优化等，还包括系统的安全性、易用性、产品支持、发布管理、部署方式等问题。

架构师不仅要为用户创造实用的软件，还要平衡兼顾不同部门的目标，如CEO要求控制成本，运营部门要求易于管理，二次开发人员要求代码易读易维护等。

 

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

如果在提交代码前，需要浪费很多时间进行测、验证，则开发人员很可能会为了节省时间草率的提交了任务。一旦出现问题，就会浪费别人很多时间。所以架构师有必要改善这个过程，通过引入自动测试、持续集成等来纠正开发人员的行为。

架构师应沉下心来改善系统的生产效率，缩短流程，缩短开发时间，提升开发体验，减少构建代码时间等，这样也利于杜绝开发员草率提交任务的念头。