架构师要不要写代码

　　最近，这个话题在群里接连爆发，这次是由于群里一个朋友所在公司的架构师只给他了个PPT，他期望架构师能给一个DEMO，然后问大家PPT能不能算DEMO引起的，且不说能不能算，不过如果能用PPT表达清楚，我倒是觉得也没什么。

　　争论的核心自然是架构师要不要写代码，我倒是觉得这事和架构师本身没什么关系，多数是看公司规定，总之围绕着这个问题产生了很多争论以及延展：

　　1.架构师需不需要会写代码：

　　认为必须会写代码的自然举了很多见过的架构师写DEMO之类的案例；认为不需要的基本是说架构师是搞架构的不一定需要会写代码，只要一个能实现业务的模型就可以了。

　　首先，这得排除业务架构，咱只说技术架构，然后是伪代码算不算代码。。。？，我是站在架构师不一定要会写实现的代码这一边上的，因为他有时候只需要关心能否实现，怎么能更好的实现，而具体到怎么用某种语言实现倒并不那么重要了，当然，写DEMO最好，因为程序员接受的快，理解上的压力也是压力。

　　2.架构师要不要懂技术：

　　这个我觉得实在没啥好争论的，架构师最终是要制定一个技术架构来实现业务的，只懂业务的哪种叫领域专家或者信息专家，做的应该是业务顾问之类的职位；至于有些朋友说的，某些官僚机构的架构师只需要会忽悠就可以了之类的事。。。，似乎有些微妙的不太好反驳。。。

　　3.架构师要不要关心具体技术：

　　怎么说呢，比如我们公司有个职位叫首席科学家，咱对这个职位不太了解，这类高大上的职位是不是架构师。。。；至于负责落地的。。。要选型总需要懂吧，不懂该怎么选呢？

　　4.如果选用了某种技术，架构师是不是一定要用过：

　　我是站在不是的一边的，之前听过一个微软的架构师说，微软认为一个架构师至少要十年工作经验，这里就是工作经验的作用了，凭经验去分析这项技术合适不合适，说明理由就足够了。

　　5.架构师是不是只要凭想象就够了：

　　如果真有这样凭想象就能解决问题的，那一定是非常大的牛，一般架构设计是要说明用什么不用什么，为什么用这个而不用那个，道理是要说清楚的，只给出个怎么做，这种其实就不是完整的架构设计。　　　　

　　6.架构师要不要会忽悠：

　　必须会啊，你没有感染力，表达不清楚你的设计，人家就是想用也得用明白啊，而且程序员多数都是比较倔的，你不给他说服了，他才不会相信你的设计呢，不过会忽悠也是要有东西可忽悠的，什么都没有纯靠忽悠的，不能否定说一定没有，但那肯定不是真正意义上的架构师。

　　其他还有些诸如项目经理要不要懂技术的争论就不说了。

　　说一个大师级人物经历过的真实项目，当然或许会有片面的地方，但我觉得很有代表性：（摘至 《DDD》）

　　我曾经在一个项目中负责协调不同的应用程序开发团队，帮助开发可以驱动程序设计的领域模型。当管理层不允许写代码或与程序员讨论细节问题。

　　开始还算顺利，我们建立了个不错的核心模型。但该模型却没排上用场，原因有两个：

　　一，模型的一些意图没有向开发人员说清楚。模型整体效果受细节影响很大，这些细节并不总能在UML图或讨论中遇到。如果我能直接与开发人员一同工作，提供一些参考代码和近距离技术支持，那么他们也许能理解模型中的抽象概念并开发。

　　二，模型与程序实现及技术互相影响，而我无法直接获得这种反馈。例如，程序实现过程中发现模型的某部分在我们的技术平台上工作效率极低，但是经过几个月我才一点一点获得了关于这个问题的全部信息。也许较少的改动就能解决，但几个月过去了，该不该已经不重要了。因为程序员自行编写了可以运行的软件---完全脱离了模型的设计。他们再也不愿意冒险任由呆在象牙塔里的架构师摆布了。

　　大师的案例结束。

　　从案例中，能很清楚的看出来架构师写不写DEMO的好处，不过这里还是要分清楚，伪代码算不算代码，当然，即使是算代码，案例中也没有说一定要写，有能解决问题的近距离技术支持就好了，只给个设计就再也不管实际是一种不负责任的行为，而且与案例类似的情况非常普遍，我自己也遇到过几次这种情况。

　　设计无处不在，而且开发人员可能意识不到某些细节的改变会造成对模型的改变，我觉得因为需求的不稳定没有什么需要架构师设计的架构能一次成型没有理解压力并且完全不需要调整，架构师写不写代码不重要，重要的是能不能及时对架构的实现做支撑，帮助程序员理解和实现软件。