架构师的行为准则（三）

转自：走向架构师之路

 
让开发人员自己做主 
架构师虽然需要为系统的设计负责，但无须包揽所有的设计工作，应该给予团队成员足够的自主权，让他们发挥自己的创意和能力，你的工作是确保大家的工作能很好的组合在一起，帮助他人解决棘手困难。当你发现同事遇到麻烦时，可以主动给出建议，但更可取的做法是创造良好的氛围，让大家主动向你征求意见。
控制项目规模 
架构师要试图避免做那种“超大型”系统，因为这种系统往往难以控制，控制项目规模的办法通常有：抓住真正需求分而治之设置优先级尽快交付原则
架构师不是演员，而是管家 
有些架构师误解了证明自己价值的含义，以为是炫耀技术才华，甚至是***难开发团队，把自己放在高高在上的位子，试图让别人来崇拜你。其实架构师的职责和管家类似，承担着管理技术资产的责任，要深入了解系统里各个细节，要精打细算，而不是浮在表面做无实文章。
关注性能 
高性能往往和代码优美性常常没法兼容，有些架构师往往不在乎性能上的点滴损耗，为了代码更重用或更优美，不惜多查一次数据库，多与外系统交互一次，这种做法会让后期的性能提升很被动，性能压力会逼迫你打破原有的设计，为提升性能把代码搞得支离破碎。架构师需要珍惜任何一点的性能损耗。
对复杂性要有前瞻意识
在实际的运行环境中，往往简单的系统都有可能变得非常复杂，简单的远程接口可能调不通、稳固的数据库可能down掉、消息顺序可能会错乱、服务器可能会无缘无故地down机，不要假设这些情况不会发生，架构师应该对复杂的情况有前瞻意识，要在假设类似于前面的状态存在的情况下设计软件。
关注边界和接口 
任何系统或模块的边界和接口都是与外交互的门面，有交互就暗藏着误解和不恰当的划分，保持接口的顺畅交互是架构师的重要职责。往往bug发生在模块与模块之间、系统与系统之间，项目的失败也往往因为系统间交互问题，因此架构师需要给予足够的关注
助力开发人员 
架构师的完美设计需要开发人员是实现，因此有业务想办法提升开发团队的战斗力，常有以下方式：寻找或开发工作需要的工具，并附上使用技巧做定期的分享或提高团队学习气氛，保持团队技术上的先进性参与开发团队的招聘工作给予开发人员更多的决策空间，帮助其成长保护好开发人员，让他们尽可能地免于杂事之中直接参与开发，分担压力
记录决策的理由 
架构师常常需要权衡和决策，但决策过后却没有把决策的过程和理由记录下来，其实这是在浪费很大的一笔财富。
质疑假设 
架构师往往需要假设一种情境，然后在这种情境下给出方案和做出决策，很多人包括自己从来都是纠结于这个方案的优劣，并不断改进，但却忽视了这种假设的情境是否成立，而这个可能是万恶之源。
关注系统的支持和维护 
架构师通常是由开发人员成长而来，因此天然地把注意力放在功能开发上，常常忽视系统的支持和维护方面，给支持人员和维护人员造成不便。架构师需要清晰知道一个系统生命周期80%在于维护上面，而系统的价值需要支持人员去不断传递给客户，他们的需求需要得到重视。有以下几点需要注意：清晰性可测性正确性可跟踪性
不要急于求解 
很多架构师都有解决难题的欲望，一遇到问题，就立马陷入解决问题的泥潭中。而更可取的是审视问题本身，看是否可以改变问题，或是干脆绕开问题，很多时候技术上的难题在通过业务上的优化是可以避免的。我们不要立足点设为解决特定问题，而是应该立足于客户需求
优秀软件是培育出来的 
很多架构师需要在软件的第一版本就一鸣惊人，拿出完美的作品，其实真正受欢迎的系统是在不断发布中演化而来，对于互联网软件更是如此。架构师需要做的是打好系统的基础，使其容易修改和扩展，倾听用户的反馈，不断地在无数次改进中培育我们的软件