框架师总结一<摘抄>

      一个优秀的软件架构师，首先一定是一个出色的程序员。

      支付宝架构师说架构师是一个比较“虚”的岗位，主要的问题都在“落地”的过程中

      而一个架构师确认一个想法究竟能不能落地的最直接的方法，就是自己编写代码，尝试“实现一个系统最难实现的一部分”

      eBay的架构师是这样总结架构师在项目中的职责的：

1. 产品团队要做一个新产品，架构师开工了。架构师要帮助产品团队把可行性、技术需求以及权衡取舍等因素一一剖析清楚。

2. 技术需求出来了，架构师的主要工作开始了：设计整体的技术实现步骤。Randy在后面补充说“大多数成功的架构师都喜欢与其他团队成员一同完成架构和设计这一块的工作”，而认为自己应独自完成这个步骤则是新手架构师常见的误区。

3. 与开发团队一起，完成设计与实施的细节

4. 与开发团队和运维团队一起，完成部署的过程

5. 与运维团队一起，进行部署之后的维护和故障排除

 

      在这个过程中，一个架构师至少有一半以上的工作是需要与开发团队一起进行的。按照Randy的描述，这是“一个架构师不能将实施细节抛之脑后”的体现。而且与开发团队一起工作，命令式的领导方式并不被推崇，一个架构师必须通过自己的个人影响力来对开发团队进行指导工作。而什么是影响力？说的直白一些，就是通过自己写代码以及和其他成员一起写代码，来指导团队成员实现每个架构细节的思路。

 

      只要稍微思考一下，就会明白此举的重要性。如果一个架构师靠命令管理开发团队，告诉他们“要实现这个模块”，“要实现那个功能”，而团队也尝试照办。可是或许是架构师的要求太高了，或许是团队的开发实力不够，团队成员便会向架构师求助：您看这个我们不知道如何实现，您能否指导一下？架构师可能知道怎么处理，也可能没有仔细思考过这个问题，但又觉得自己做大事者不拘泥于小节也，于是一皱眉头扔下一句：这是你们的事，你们自己解决！

然后就是矛盾的开始了。架构师只觉得团队技术不够，而团队则对架构师愈发不满。项目黄了不说，开发团队中也会传出各种说法，比如说“此君其实是个一行代码也不会写的大忽悠！”

 

      综上所述，便映证了Fred的那句断言：“不编程的架构师的职业生涯是短暂的”。一个架构师不仅要会写代码，还必须要能够写出自己设计的系统中最难实现的那段代码。这样他才能够放心的把“落地”的这个重担交给开发团队来做。

让我用Fred的这句话做为本篇的总结：“一个架构师的价值在于，他不仅能看到系统的美，而且能够在建造系统的时候能够把这些美创造出来。”

 

     总结：1，架构师需要与开发人员一起在将问题“落地”

              2，不能依靠命令式管理开发团队

              3，架构师的职责是保证技术开发的质量，所有关于技术的问题架构师有责任去处理。所以，没有“你们”和“我”之分。有的，只有“我们”一起解决

             

摘自：

     《架构师害怕程序员知道的十项技能》中的优秀程序员篇。

       http://developer.51cto.com/art/200912/170080.htm