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

原则大于个人口味

很多架构师都有着丰富的经验和个人风格，以至于在平常工作中常以个人口味作为决策的依据，对于普通的开发人员也许是可行的，我们鼓励大家有个人特色，但架构师更应该依据原则办事，需要维护和遵守一套大家公认的原则，以此作为判断是非的工具

从“可行走骨架”开始

敏捷管理崇尚尽早集成，在架构设计这一块，这个原则也行之有效。架构师在开始阶段无需陷入某些难题或细节里，应该尽快地把各个核心模块串接起来，并能发动开发人员使其简单地运转起来，骨架一旦就绪，再进入健身环节。这样做的好处，一方面可以尽早消除大家之间的误解，也可以带来正朝着正确方向前进的信心

数据是核心

数据为王是大家深知的道理，只要这个系统拥有有价值的数据，那么这个系统就有生命力。架构设计中，数据无小事，任何数据只要是存在于系统中，就需要给予足够的重视，也许是个废弃的字段，但它也许会有一天被人错误的引用到，或是时不时地遭到别人的询问是干嘛用的。

根据投资回报率进行决策

很多架构师认为计算和分配资源是PM要做的事情，与自己无关，自己要做的是设计最优的系统。其实，这个最优不光是技术上的最优，往往在实际项目中大家所关注的是投资回报率最优，老板想用最少的投资获取符合需求的产品， PM想用最少的人力发布项目，开发人员想用少的代码完成功能等等，作为架构师应该把投入产出比作为决策的一个重要因素

起码有两个可选解决方案

一个经验丰富的架构师会对一些关键的问题给出多个解决方案，并能分析其优缺点，并最后一般取舍之后做出选择，这是一种令人信服的说明问题和解决问题的方式。

不能不了解硬件

软件架构师常常无法正确考虑硬件因素，有多种原因，但大多和缺乏硬件的了解脱离不了干系。最好的解决办法是加强与基础设施架构师合作，共同对架构和设计进行评估

架构无小事

很多系统建设初期的琐碎事情在架构师看来是些小事情，比如单元测试、多余的库依赖、版本号的升级、开发人员不合理的代码风格等等，这些事情不给于重视尽早解决，会在将来的某天去解决会需要数倍的成本，有效率的架构师会尽早解决这些“小事”

警惕新技术，不轻易抛弃老技术

很多架构师包括大部分的开发人员都有新技术的追求倾向，但暗藏在每个新玩意后面的是风险和缺陷，在引入每项新技术之前，需要给予足够的评估，不要只看到它power的一面，更应该熟知其潜在的危害。而对于已接收过现实检验的老技术不要轻易抛弃，可能它存在些缺陷是某些新技术可以取代的，但我们应该更珍惜对它的了解和成熟，更可取的态度是试图去优化它而不是抛弃

拉伸关键维度，发现设计中的不足

架构师或多或少喜欢在理想的情况下设计产品，一旦异常情况发生或数据量超出了当初业务方提出的假设时，架构就漏洞百出。因此设计初期可以适当拉伸关键维度，把运行环境设想得更复杂一点，把需应付的数据量预想更多一些，这样可以发现设计中更多不足

稳定的问题才能产生高质量的解决方案

最好的架构师不是要去解决难题，而是要围绕难题开展工作，要能够将四处弥漫的软件问题圈起来，并画出其中的各种边界，确保对问题有稳定的、完整认识。如果问题是稳定的，那么解决后就永远不会再来麻烦你

对决策负责

有些架构师做出决策后，把事情交给其他开发人员去实施，认为之后的事情与自己无关了，其实做出设计上决策只是解决问题生命周期的最开始阶段，真正对决策负责可以参考做以下方式：

充分认识决策过程。可以采取记录和沟通的方式
定期复审架构决策
贯彻架构决策，全程跟进实施过程
给把决策的权利委托给团队中的专家
偿还技术债务

系统里或多或少会存在一些已识别的缺陷，比如单元测试覆盖率低、可测性差、性能不达标、代码坏味道多等等，架构师常常会视为眼中钉，想一夜之间把它们都消灭掉，其实更应该把它们作为债务，有计划地可控地去偿还，要把握好偿还的时机，这样我们的成本和收益比才会更好

结束语

以上这些行为准则不是拿来背诵的，而是应该融入到日常的工作中，有句话说得好，成功是一种习惯，只有习惯了这些成功实践，才算是真正的成功



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