架构师的行为准则（一） (转)

最近看了一本书《软件架构师应该知道的97件事》，本来并没对它抱有太多期望和兴趣，毕竟这种讲大道理的书不可能带来什么实际收获，但看的过程中被里面中肯实在的建议给吸引，对于我这种在走向架构师这条路上常常迷失方向的人，实在是雪中送炭。读完后，决定选择其中对我有触动的条目，加上实际工作中的感悟，形成一套自认为正确的架构师行为准则，以此来矫正自己的行为。

客户需求高于一切

不要为了自己的项目经历上添加光彩而去一味追求时髦而光鲜的方案，而是应该扎根客户需求，脚踏实地地为客户着想，这样才能更体现技术的价值，不至于迷失方向。架构师首先不要把自己当做技术人员，而是业务人员，把实现业务需求作为至上的目标，学会拒绝成本高，性价比不高的技术。

简化根本复杂性

常常为了解决某一局部复杂性引入了更为复杂的框架或产品，使得复杂性不减反增。往往正确的方式是做减法而不是加法，把最根本的复杂源找到，把根铲除。

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

总结失败的项目常常会纠结于选择了错误的技术。其实技术并没有错，而是在使用技术上或是在执行过程中人为的偏差导致。而架构师解决这种人为的问题比较好的方式是沟通，通过有效地沟通把技术贯彻下去

以沟通为中心，坚持简明清晰和开明的风格

架构师不要坐在象牙塔里，命令开发人员实施你的设计和决策，而是应该尽量简化你的设计，透彻地与他们沟通，并且关键在于开明地接受他们的建议并勇于推翻自己的决策

架构决定性能

最好提升性能的方法不是痛苦地做一次次对即将上线的产品做性能测试和提升，而是在架构设计的时候就把性能作为重要因素，从架构底层考虑分布式、缓存、系统交互划分等影响性能的重点。提前关注性能，是解决性能问题代价最小的方式

分析客户要求背后的真实需求

合同上或UC上只是客户的要求，而并非100%是客户真实的需求，架构师的重要责任就是挖掘隐藏在要求背后的真实需求，这个不但可以最大化满足客户，也往往可以帮助我们避开技术壁垒，当真正抓住客户需求的时候，我们也许能用更为简单的替代方案满足客户

沟通是架构师达成目标的核心技能

常用的沟通技能和准则有以下几点：

不要把沟通当做对抗
不要带有情绪与人沟通
表达自己方案之前倾听他人观点
站立发言是扩大沟通影响力的一种好方式
学习业务或技术领域中的行话，降低沟通成本
不要为预防故障引入更多的故障

架构师常常会为识别出的可能故障点加入监控措施，但往往会忽略做些监控措施也是会有故障的，不要试图让你的系统天衣无缝，这往往是使系统更为复杂和脆弱的来源。先承认是系统总会有缺陷的，只是把这些缺陷设定为容易察觉和维护的点

量化非功能性需求

往往功能性需求容易量化，因为这些是看得见和摸得着的，但像性能好、可扩展性好、高可用性等这些非功能性需求却不好量化，但作为架构师要有意识地去定义和量化这些需求，只有这样才能更好地和其他部门更好沟通，谋求更多资源，也便于系统更有效地验收

一行代码比500行架构说明更有说服力

架构师往往喜欢待在象牙塔里，堆砌大量架构文档，然后希望其他开发人员能乖乖地去实施。这样做的效果往往是不好的，一方面很难有这样的牛人能洞察所有的细节，在文档里就预测性地解决了所有问题，另一方面也不利于架构师与开发人员的沟通。比较好的做法是架构师参与具体实施，在实施中验证和改进架构设计，与大家达成一片也便于加深彼此配合的默契程度。

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

不存在最好的架构，只有最合适的架构。不会有一种架构方案，在任何项目里都适用。虽然我们承认模式的重要性，但在实际项目里要有选择性吸收，根本上要本项目和实际困境出发，不要被既有的模式和经验先入为主，因为没有一种已有方案能完全不修改地适用于你。

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

架构师从某种角度来讲就是一剂胶水，把业务部门的需求、项目进度的需求、测试的需求和开发工程师本身的需求有效地捏合在一起，平衡与兼顾以至达到皆大欢喜。其他职能的人都只是focus在某一局部，需要架构师这样的人来通盘考虑，因此他的工作是最杂的，绝不是简简单单地拿出一份架构文档就OK了，需要考虑系统安全、易用性、可测性、商业价值、长期规划、发布管理和部署方式，使得各个部门人的需求得到响应



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