软件架构师应该知道的97件事

《软件架构师应该知道的97件事》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、软件架构师应该知道的97件事笔记by:ciahihttp://blog.csdn.net/ciahi1.客户需求重于个人简历不要为了学习新的知识或丰富自己的简历而选择新技术解决问题，要尽量选择切合实际的技术解决客户的难题。脚踏实地的为客户着想，选择正确的方案可以降低项目的压力，团队工作起来更开心，客户也会更满意，从而你也会有更充裕的时间学习新的知识。2.简化根本复杂性，消除偶发复杂性根本复杂性是问题本身就很复杂，所以它是无法避免的。偶发复杂性是在解决根本复杂性的过程中衍生的，即解决方案本身带来的新问题。如为了解决某个问题而设计的一个软件框架，设计该

2、框架本身，就是引入的偶发复杂性。所以，如果原本问题比较简单，但设计或引入一个太过灵活的框架，可能得不偿失。(避免过度设计)3.关键问题可能不是出在技术上简单的项目也可能会出现问题，这并不是因为我们选错了某种语言或者系统，根本原因还是“人”所以，要帮助团队完成项目，多与项目成员沟通，及时改正团队成员不正确的工作方式。沟通的技巧：a)不要把对话看成对抗改变心态，发现他人的优点，把沟通视为请教，就会有所收获，并且能避免引入对方的戒备之心。b)不要带着情绪与人沟通当你处于愤怒、沮丧、烦恼等情绪中时，对方可能会误认为你的举动不怀好意。c)尝试通过沟通设定共同

3、的目标4.以沟通为中心，坚持简明清晰的表达方式和开明的领导风格架构师要避免只发号施令，让开发人员执行的弊病。要让开发人员了解项目的蓝图和决策过程，让大家共同验证你的架构，让开发人员参与你的架构的制订过程，这样开发人员才能更心甘情愿的去执行。架构师应该提高自己的沟通技巧，帮助大家快速、精准的理解项目的目标。要言简意赅的表达观点，用简单的图表来表达自己的想法。用相机拍下自己在向团队成员表叙时在白板上写写画画的想法，会后分享给大家，并且自己好好整理一下。5.架构决定性能如果架构有问题，仅仅通过优化局部，不足以获得理想的性能的。找出性能瓶颈，优化瓶颈，如果

4、需要的话，重新设计架构的内在逻辑和部署策略。6.分析客户需求背后的意义分析客户提的需求，为什么提这样的需求。即要知道客户要求的功能和需求的真正意义，这样或许我们可以在达到客户目的的情况下，采取更简单的办法。7.起立发言在多人场合发表意见时，起立发言非常重要，尤其是其他人坐着的时候。站立时，无形中增添了一种权威和自信，容易控制了场面。听众不会轻易打断你的发言。站立时可以更好的利用肢体语言，且在十人以上的场合，起立发言方便与每位听众保持视线接触。眼神交流和肢体语言等表达在沟通中的作用不可小觎。起立发言也更容易控制语气、语调、语速和嗓门，让声音传播的更远

5、。讲到重点时，注意语速的减缓，发声技巧也能改善沟通效果。8.故障终究会发生为了防止A程序出错，增加了监控程序B，但监控程序B本身就可能会出错。所以故障及错误是无法避免的，即要做好错误的防范措施。9.我们常常忽略了自己在谈判项目投资人为了削减预算，可能会去掉一些“东西”。当投资人问“我们真的需要这东西吗？”很多工程师把自己摆在了工程师的位置，会回答一些不使用这些东西的替代方案，但往往这些替代方案是极差的。在投资人看来，有其它方案可选，他不关心是什么方案，他往往会让你去掉这些“东西”。我们这时应该把自己放到谈判者的角度上，说明不使用该方案的坏处，以及使

6、用该方案的好处。让投资人清楚的认识到该方案的重要性。10.量化需求“速度快”、“响应灵敏”都不能算需求，需求一定要可量化。比如响应时间在500ms以内。如果没有这些具体数字，也要有一个描述范围，如上限、下限等。11.一行代码比500行架构说明更有价值要牢记我们的目标是可工作的代码，设计只是手段。很多架构师往往被抽象的架构所吸引，沉迷于设计过程。没有天生完美的设计，设计都是在实现过程中逐步完善的。如果有机会亲自开发，珍惜这个机会。12.不存在放之四海皆准的解决方案没有通用的解决方案，遇到的问题也是千差万别，架构师需要运用情境意识来解决问题（类似于常识

7、）。情境意识需要培养和训练，架构师要不断的积累案例和经验才能建立足够的情境意识。要解决系统层次的问题，通常需要十年的磨练。13.提前关注性能问题尽早进行性能测试，如果在某个时候性能表现大幅下滑，更容易找到性能下滑是由哪些变化引起的。如果以两周为一个迭代周期，性能测试的开始时间最迟不要晚于第三次迭代。尤其是对性能要求苛刻的系统，验证的早晚直接关系到能否及时交付项目。14.架构设计要平衡兼顾多方需求软件架构不仅包含系统建模、定义接口、划分功能模块、大胜模式、性能优化等，还包括系统的安全性、易用性、产品支持、发布管理、部署方式等问题。架构师不仅要为用户创

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