架构师的行为准则（三）

 

让开发人员自己做主

架构师虽然需要为系统的设计负责，但无须包揽所有的设计工作，应该给予团队成员足够的自主权，让他们发挥自己的创意和能力，你的工作是确保大家的工作能很好的组合在一起，帮助他人解决棘手困难。当你发现同事遇到麻烦时，可以主动给出建议，但更可取的做法是创造良好的氛围，让大家主动向你征求意见。

控制项目规模

架构师要试图避免做那种“超大型”系统，因为这种系统往往难以控制，控制项目规模的办法通常有：

抓住真正需求
分而治之
设置优先级
尽快交付原则
架构师不是演员，而是管家

有些架构师误解了证明自己价值的含义，以为是炫耀技术才华，甚至是***难开发团队，把自己放在高高在上的位子，试图让别人来崇拜你。其实架构师的职责和管家类似，承担着管理技术资产的责任，要深入了解系统里各个细节，要精打细算，而不是浮在表面做无实文章。

关注性能

高性能往往和代码优美性常常没法兼容，有些架构师往往不在乎性能上的点滴损耗，为了代码更重用或更优美，不惜多查一次数据库，多与外系统交互一次，这种做法会让后期的性能提升很被动，性能压力会逼迫你打破原有的设计，为提升性能把代码搞得支离破碎。架构师需要珍惜任何一点的性能损耗。

对复杂性要有前瞻意识

在实际的运行环境中，往往简单的系统都有可能变得非常复杂，简单的远程接口可能调不通、稳固的数据库可能down掉、消息顺序可能会错乱、服务器可能会无缘无故地down机，不要假设这些情况不会发生，架构师应该对复杂的情况有前瞻意识，要在假设类似于前面的状态存在的情况下设计软件。

关注边界和接口

任何系统或模块的边界和接口都是与外交互的门面，有交互就暗藏着误解和不恰当的划分，保持接口的顺畅交互是架构师的重要职责。往往bug发生在模块与模块之间、系统与系统之间，项目的失败也往往因为系统间交互问题，因此架构师需要给予足够的关注

助力开发人员

架构师的完美设计需要开发人员是实现，因此有业务想办法提升开发团队的战斗力，常有以下方式：

寻找或开发工作需要的工具，并附上使用技巧
做定期的分享或提高团队学习气氛，保持团队技术上的先进性
参与开发团队的招聘工作
给予开发人员更多的决策空间，帮助其成长
保护好开发人员，让他们尽可能地免于杂事之中
直接参与开发，分担压力
记录决策的理由

架构师常常需要权衡和决策，但决策过后却没有把决策的过程和理由记录下来，其实这是在浪费很大的一笔财富。

质疑假设

架构师往往需要假设一种情境，然后在这种情境下给出方案和做出决策，很多人包括自己从来都是纠结于这个方案的优劣，并不断改进，但却忽视了这种假设的情境是否成立，而这个可能是万恶之源。

关注系统的支持和维护

架构师通常是由开发人员成长而来，因此天然地把注意力放在功能开发上，常常忽视系统的支持和维护方面，给支持人员和维护人员造成不便。架构师需要清晰知道一个系统生命周期80%在于维护上面，而系统的价值需要支持人员去不断传递给客户，他们的需求需要得到重视。有以下几点需要注意：

清晰性
可测性
正确性
可跟踪性
不要急于求解

很多架构师都有解决难题的欲望，一遇到问题，就立马陷入解决问题的泥潭中。而更可取的是审视问题本身，看是否可以改变问题，或是干脆绕开问题，很多时候技术上的难题在通过业务上的优化是可以避免的。我们不要立足点设为解决特定问题，而是应该立足于客户需求

优秀软件是培育出来的

很多架构师需要在软件的第一版本就一鸣惊人，拿出完美的作品，其实真正受欢迎的系统是在不断发布中演化而来，对于互联网软件更是如此。架构师需要做的是打好系统的基础，使其容易修改和扩展，倾听用户的反馈，不断地在无数次改进中培育我们的软件

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/cutesource/archive/2010/07/25/5765374.aspx

 

扩展阅读：《架构师应该知道的97件事》豆瓣链接http://book.douban.com/subject/4745287/