软件架构师 — 做不好士兵的将军不是好将军

上周，一位同事来到我的座位想和我聊天，当他看到我正在看程序代码，于是问了我一句，“你在写还是看程序？”。我当时正在看程序，于是我的回答是，“我正在看程序，但我自己也写程序”。于是，他又问道，“你觉得软件架构师需要自己写代码吗？”。我说，“其实是需要的”。他又回了一句，“是不是做不好士兵的将军就不是好将军？”。我说，“你这提法到是很有新意的，我很赞同！”。

    还有一次在上MBA课程时，我的一位同学看到我在教室里写程序（其实是在写书），他问我“你现在还要自己写程序？”，我当时回答“是的”，但心里在想，是不是人家觉得我现在（都在读MBA了）怎么还要自己亲自写程序呢？（或许是多想了）

    今天我想就软件架构师应不应当自己写程序谈一谈自己的看法。作为开始，我们多方面要区分两类架构师。一类是应用层软件架构师。这类人对于应用（及相关规范）非常的熟悉，其工作重点在于编写需求相关的文档，而不关心软件的具体实现。通常这类人是属于系统工程（system engineering）部门的，后面称其为系统架构师。另一类人则完全不同，他们除了对于应用有相当的了解（但可能不如系统架构师），还对于软件的结构和设计有很好的认识，这类人通常来自于开发工程（development engineering）部门，后面称其为开发架构师。

    对于开发架构师，我认为他应当懂什么是软件设计。至于是不是他自己最后完成代码的编写工作，或是指导他人完成代码编写工作，那就不重要了。最近在与一位MBA同学聊天时，我们在谈到软件设计问题时，他突然问我，“什么是软件设计？我觉得软件设计太虚了！”。对这一突如其来的问题我当时愣了一下，因为在我的头脑里设计就是设计（看来有必要写文章表达我所理解的设计?）。但我立刻意识到，这位同学道出了软件行业的一个难题，即在软件行业中，并没有度量软件设计质量的方法。可能有人会说，从软件的bug数量不就可以看出软件设计是否好坏吗？这一说法乍一听有道理。但问题是，有谁会先用了软件得到bug数量后反过来看软件质量以决定是否购买呢？通常，在购买一款软件（或相关产品时），之前应当是先了解软件的（设计）质量，然后再决定购买。另外，bug数量并不能真正的反映软件的设计质量，bug少可能是因为产品的复杂度小，但可能设计质量还是很差，表面的上的高质量其实是后面用大量的痛苦换来的。还有人会说，现在不是有CMMI吗？或是其它的质量认证体系，难道这些都不足于证明软件的设计质量？是的，我认为现在的认证很多是着重于软件开发流程的，但是并没有提供对设计质量的认证。要知道好的软件设计流程并不意味着能获得好的设计质量，可以说流程与设计质量在某种程度上是正交的。由此可见，不论是XP或SCRUM等敏捷开发方法，都不能让我们直接获得高设计质量的软件。那为什么业内就没有推出设计质量认证体系呢？这不得不提到软件行业中著名的一个故事 —— 人狼的故事，这个故事告诉我们“软件行业没有银弹”。其本质是说软件开发（设计也包括在内）是高度地依赖于人脑的，因此，很难找到生产高质量软件的通用方法。从设计的角度来说，要得到一个评估软件设计质量的体系几乎是不可能的，因为对设计的好坏很难达成一个广泛的共识和抽取出可操作的准则。

    开发架构师如果明白设计的重要性，那他往往需要自己动手去写一些代码，去展现自己的设计思想，或者验证自己的设计想法。做开发架构师不可能只通过画UML图就完全表达自己的思想。另外，一个不能站在工程师的角度去思考问题的开发架构师，很难说他是一个好的架构师。开发架构师除了承担技术方面的工作，我认为他在一定的程度上还应当承担管理方面的工作。比如，激励团队采用好的设计方法、重构等等。所有这些都表明，开发架构师应当身体力行地带领工程师去工作，而不是“高高在上，只懂应用”，更不能成为一个Super Editor（一味地从开发人员那里了解要怎么写，然后将其写入需求文档中）。

    与开发架构师不同的是，系统架构师不写代码可能一点也不奇怪，相反他们也不应当关心代码的具体实现。那是不是这类架构师在其成长过程中就一直不用写代码呢？显然不是。我相信，一名意识到软件设计重要性的系统架构师其所编写的需求文档将更具指导性和开发性。

    最后，我想着重强调开发架构师的重要性。在我看来，现在的软件行业其实很是困难，其根本在于这个行业缺乏高质量的开发架构师。我没有看到哪一个公司因为理解不了应用需求而开发不出软件，相反不明白什么是设计而使得大家倍受煎熬的情形却较为普遍。

    软件质量源于设计！