架构师的编码情结

 做架构师多年以后，看到研发人员写的不够艺术的代码，还是忍不住把他或她从座位上拉开，甩开膀子写一段痛快淋漓的代码。
       做架构师、乃至做首席架构师是我软件从业20年来不断追求的目标。每天一定量的代码、始终是我对自己的要求。曾经有一段时间以来，我认为系统架构师才是我的目标，建立一个框架把业务展开，把用到的技术写个demo就基本完成任务了。但在这项目中、需求不明确需要架构师去挖掘，主动深刻领会客户的用意，把他当做产品去研发。这个工作只有技术和业务都很强，又能写代码还能写架构设计的时候。项目中，项目经理、高级工程师、高级程序员都束手无策的时候。作为架构师是最后的防线。技术总监都素手无策的时候，首席架构师就责无旁贷。

       开源项目Parrot的首席架构师兼开发组组长Allison Randal，她也是为女性，就曾经很务实地说过：架构师往往容易被抽象的架构所吸引，沉迷于设计过程。事实上，仅有架构说明书是远远不够的。软件项目的最终的目标是建立生产体系，架构师必须时刻关注这个目标，牢记设计只是达成目标的手段，而不是目标。我们的目标是可工作的代码，对软件项目而言，忽略这一点就是灾难。如果你亲自参与开发，应该珍视自己花在写代码上的时间，千万别听信这会分散架构师精力的说法。参与项目所付出的努力，既能拓展你的宏观视野，也能丰富你的微观视界。

结合我的项目经验，对于Allison Randal的话体会是很深的。作为架构师我一直参与开发，我十分珍惜写代码的时间和经验。这其实不会分散架构师的精力，很多时候，技术方案的选择，最好有两种以上，在经过验证后才可以才能够确定。当初我们拿到架构方案书，并不是迷信该方案说明书，而是通过关键应用，搭建了原型系统，一方面验证了架构的可行性，另一方面，可以为开发人员提供更为实实在在的示范指导。对于开发的每个细节，都比较清楚，开发人员有什么问题，也可以得到很快的解决。

国外的架构师为何能够成为大师，而国内的架构师最后无法成为大师，其实主要的区别就在于，国外的架构师还在参与编程，跟项目团队一起解决难题。

由于架构设计很多时候是给出了设计原则，粗粒度的设计，有时候往往与实现还有一段距离。因此，在架构设计与实现会出现断层。这是因为如果架构师不去实践，只是想当然的认为“没问题，这个想法能实现”，那么对于项目的落实而言是个很大的隐患。支付宝架构师冯大辉也表示过，架构师是一个比较“虚”的岗位，主要的问题都在“落地”的过程中。而如何要实现“落地”，取决于架构师是否参与编程。而事实上，我们列举出一个长长的顶级架构师的列表，你会发现无一不是顶级的程序员。

  让我们来看看，eBay的架构师Randy Shoup是如何总结架构师在项目中的承担的职责的：

1. 架构师拿到一个新的项目，架构师便开始工作，首先他要了解业务需求，然后根据需求把可行性、质量属性以及权衡取舍等因素一一剖析清楚。

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

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

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

5. 与运维团队一起，进行部署之后的维护和故障排除
商起网首席架构师兼CTO

从Randy Shoup的描述来看，架构师至少一半以上的时间是跟开发团队在一起进行合作的。试想一下，如果开发人员发现问题不能解决时，架构师说：这是你们开发实现的问题，跟我无关。从而就会产生嫌隙，以至于到最后，开发人员会说，这个架构师没有什么真材实料，似乎是一个只会将理论的技术大忽悠。这样是非常不利于项目的成功的。而架构师确实在对项目成功担负了重要的职责。