先确保解决方案简单可用，再考虑通用性和复用性
系统的复杂性往往是架构师基于通用性和复用性的设计而引入的，很多具体问题往往不需要通用性和复用性的解决方案。如果存在多个可实施方案难以取舍，先简单后通用原则可以成为最终的评判标准。架构师提供具体解决方案时，无需排斥通用和灵活，但是如果过早脱离具体情况，只会迷失在无限的可能性里，被复杂的配置选项、超负荷的参数列表、冗长罗嗦的接口，以及存在缺陷的抽象所淹没。先简单满足需求，当重复需求再次发生时，通过重构来达到复用是一种不错的方式。
架构师应该亲力亲为
架构师干久了往往会脱离技术本身，迷茫在抽象之中，这是很危险可怕的。架构师要取得其他同事的信任，应该比业务人员更懂业务，比开发人员更懂具体的编码，比测试人员更懂如何有效地测试，就像航班的主驾驶员，虽然不需要亲自操作，但经验丰富，持续地监视着情况，一旦发现异常随时采取行动。架构师应该项目的交付和质量负有最终的责任。架构师应该尽可能地参与项目，不能把技术决策和方向上的难题拆分出扔给别人，需要采取更务实的办法，比如亲自动手研究或和其他成员讨论。
持续集成是架构师的重要任务
普通的开发人员会focus在各自负责的小模块，只会对单个模块负责，而架构师需要对整个系统负责，持续集成是一种对整个系统进行有效控制的好方法，架构师有责任让它运行起来。
避免进度调整失误
虽然保障进度是PM的职责，但变更要发生的时候，作为对技术最有发言权的架构师应该站出来，把变更的必要性和风险进行仔细分析，最大限度地支持PM的决策。
取舍的艺术
我们做系统，特别是互联网系统，绝不是做一个变形金刚，而是做一个有缺陷但却满足了现阶段商业需求的系统，因此架构师需要有取舍的艺术，你的架构是能用有限的资源满足最迫切的需求，舍掉那些看是光鲜却无太多用处的东西。
打造数据库堡垒
在上层的程序设计中，架构师一般都会推崇先简单实现，然后在逐步重构的敏捷方式，但对于较为稳定的后端数据库，我们需要采取更为谨慎的态度，因为数据库是整个系统的基石，无论是业务设计还是技术设计都得保持它的稳定性，这是整个系统稳定的基础。我们往往会发现这么一个现象，当程序第一版上线后，数据库里表只会增加不会删除，也不会删除多余的字段，每次数据库变更都会引起所有人的紧张，也会使得本已混乱的数据库设计更为混乱。
重视不确定性
优良的架构能够从整体上降低设计决策的重要性，糟糕的架构则会使得常常突出选择的重要性。如果出现两个合理地选择，架构师应该停下来，设法找出介于两者之间的、具有更低重要性的决策，了解两者之外还存在其他选择，比决策结果本身更有价值。
不要轻易放过不起眼的问题
项目的失败或线上故障往往是由于项目过程中的不起眼问题所引起，比如一些特殊的边界情况，而这些问题绝不能指望开发主力们去发现和解决，因为他们的注意力都会focus在主要矛盾上，作为时刻监控项目的架构师应该担当起发现这些“小bug”的义务。
让大家学会复用
架构师有义务提高开发人员可复用地解决问题的意识，比如以上几种措施：
先尝试后决策
设计中有很多需要决策的点，很多架构师喜欢在象牙塔里凭借经验做决策，感觉这就是架构师需要干的。其实，这样的做法往往会让你很被动，不如延迟决策，把需要决策的点抛出来，让大家去尝试，在实践比较中，其实无须决策，正确的选择自然就出来了，这样也更能拉近你和大家的距离，提高大家的积极性和你的权威性。
掌握业务领域知识
架构师的角色任务在于理解业务问题、业务目标、业务需求、并设计技术架构来满足它们。掌握业务领域知识将有利于架构师选择合适的架构模式，更好地制定针对未来的扩展计划。
coding是属于设计范畴
系统的复杂性往往是架构师基于通用性和复用性的设计而引入的，很多具体问题往往不需要通用性和复用性的解决方案。如果存在多个可实施方案难以取舍，先简单后通用原则可以成为最终的评判标准。架构师提供具体解决方案时，无需排斥通用和灵活，但是如果过早脱离具体情况，只会迷失在无限的可能性里，被复杂的配置选项、超负荷的参数列表、冗长罗嗦的接口，以及存在缺陷的抽象所淹没。先简单满足需求，当重复需求再次发生时，通过重构来达到复用是一种不错的方式。
架构师应该亲力亲为
架构师干久了往往会脱离技术本身，迷茫在抽象之中，这是很危险可怕的。架构师要取得其他同事的信任，应该比业务人员更懂业务，比开发人员更懂具体的编码，比测试人员更懂如何有效地测试，就像航班的主驾驶员，虽然不需要亲自操作，但经验丰富，持续地监视着情况，一旦发现异常随时采取行动。架构师应该项目的交付和质量负有最终的责任。架构师应该尽可能地参与项目，不能把技术决策和方向上的难题拆分出扔给别人，需要采取更务实的办法，比如亲自动手研究或和其他成员讨论。
持续集成是架构师的重要任务
普通的开发人员会focus在各自负责的小模块，只会对单个模块负责，而架构师需要对整个系统负责，持续集成是一种对整个系统进行有效控制的好方法，架构师有责任让它运行起来。
避免进度调整失误
虽然保障进度是PM的职责，但变更要发生的时候，作为对技术最有发言权的架构师应该站出来，把变更的必要性和风险进行仔细分析，最大限度地支持PM的决策。
取舍的艺术
我们做系统，特别是互联网系统，绝不是做一个变形金刚，而是做一个有缺陷但却满足了现阶段商业需求的系统，因此架构师需要有取舍的艺术，你的架构是能用有限的资源满足最迫切的需求，舍掉那些看是光鲜却无太多用处的东西。
打造数据库堡垒
在上层的程序设计中，架构师一般都会推崇先简单实现，然后在逐步重构的敏捷方式，但对于较为稳定的后端数据库，我们需要采取更为谨慎的态度，因为数据库是整个系统的基石，无论是业务设计还是技术设计都得保持它的稳定性，这是整个系统稳定的基础。我们往往会发现这么一个现象，当程序第一版上线后，数据库里表只会增加不会删除，也不会删除多余的字段，每次数据库变更都会引起所有人的紧张，也会使得本已混乱的数据库设计更为混乱。
重视不确定性
优良的架构能够从整体上降低设计决策的重要性，糟糕的架构则会使得常常突出选择的重要性。如果出现两个合理地选择，架构师应该停下来，设法找出介于两者之间的、具有更低重要性的决策，了解两者之外还存在其他选择，比决策结果本身更有价值。
不要轻易放过不起眼的问题
项目的失败或线上故障往往是由于项目过程中的不起眼问题所引起，比如一些特殊的边界情况，而这些问题绝不能指望开发主力们去发现和解决，因为他们的注意力都会focus在主要矛盾上，作为时刻监控项目的架构师应该担当起发现这些“小bug”的义务。
让大家学会复用
架构师有义务提高开发人员可复用地解决问题的意识，比如以上几种措施：
- 让大家把自己能复用的代码及时共享给他人
- 加强复用代码的易用性，避免误用
- 让大家认识到已有资源好过自己动手
- 架构文档的抽象程度要适中
先尝试后决策
设计中有很多需要决策的点，很多架构师喜欢在象牙塔里凭借经验做决策，感觉这就是架构师需要干的。其实，这样的做法往往会让你很被动，不如延迟决策，把需要决策的点抛出来，让大家去尝试，在实践比较中，其实无须决策，正确的选择自然就出来了，这样也更能拉近你和大家的距离，提高大家的积极性和你的权威性。
掌握业务领域知识
架构师的角色任务在于理解业务问题、业务目标、业务需求、并设计技术架构来满足它们。掌握业务领域知识将有利于架构师选择合适的架构模式，更好地制定针对未来的扩展计划。
coding是属于设计范畴
很多人常常把软件开发类比于传统行业，把coding比作是生产过程，因此很多一线开发人员称作自己为代码工人，很多架构师也是这么认为，只是把开发人员当作实现自己设计的生产工具而已。其实coding相对于传统行业应该属于设计范畴，真正生产过程实际上是由工具来完成的编译、构建和发布过程。架构师更应该把coding当作设计来看，从纸上的设计到coding后的代码还有很多设计点可挖，同样的输出的背后也许来源于完全不同的coding，其软件成品的价值也是完全不同的。
