Question

既然我创建了一个叫作编码架构的网站1，我猜这个问题的答案就不出人意料了。在我理想的世界观中，软件架构师应该编码。曾经有人告诉我，优秀架构师的重要特征是抽象思维能力，也可以理解成不把所有时间都耗在细节里的能力。这没错，但你画的那些框框线线终归要形成代码。

1http://www.codingthearchitecture.com

编写代码

我的建议是让编码成为你作为软件架构师角色的一部分，只要把自己当作软件开发团队的一份子就行了。换句话说，你有一顶软件架构的帽子和一顶编写代码的帽子。你不见得要成为团队里写代码最厉害的，但参与到实践和交付流程的好处非常大。毕竟，“知”和“行”还是不同的。

团队欣闻你要贡献代码，通常会受到鼓励，确保你的设计能落到实处。如果没有，那么一旦你站在开发者的角度明白了这个问题，很快就能体会到那种痛苦。

创建能实际实现的软件架构，这样做的好处显而易见，除此之外，贡献代码还能帮助你和团队建立起融洽的关系，有助于缩短存在于很多软件团队的架构师和开发者之间的距离。引用瑞秋·戴维斯（Rachel Davies）和丽兹·赛德利（Liz Sedley）在《敏捷教练：如何打造优秀的敏捷团队》2一书中说的话：

2http://pragprog.com/book/sdcoach/agile-coaching

如果你了解如何编程，往往会忍不住对开发者该如何编写代码提出建议。小心，因为你可能在浪费时间：如果你没有参与项目的编程，开发者多半会无视你的编码经验。他们还会认为你越权，影响了他们的工作，所以尽量别在这方面指指点点。

构建原型、框架和基础

当你被看作开发团队的一员时，软件架构的角色可能会轻松得多，然而有时这却不太可能。晋升或被指定为软件架构师带来的一个问题在于，你可能会发现自己不能像期望的那样写很多代码。这可能因为时间压力，因为你有很多“架构”工作要做，或者只是公司政策不允许你写代码，我见过这样的情况。如果是这样的话，对软件系统中有疑问的概念构建原型和证明是一个很好的参与方式。这让你可以和团队建立起融洽的关系，也是评估你的架构是否管用的好办法。

作为替代，你可以帮助建立团队可用的框架和基础。试着抵挡住构建好这些东西再交给团队的诱惑，因为这样可能会适得其反。软件开发非常容易赶潮流，所以小心别构建出一个东西却被团队当作毫无价值的过时破烂！

进行代码评审

显然没有什么能代替给真正的项目编码，我也不推荐把代码评审作为一个长期的战略，但参与（或做）代码评审至少能让你了解新技术及其应用。对于你没有经验的技术，挑剔或参与讨论可能会损害你的名声。我记得自己曾不得不向一个从未写过一行Java代码的架构师解释自己的Java代码。那很无聊。

实验并与时俱进

你需要保持一定水平的技术知识，才能称职地用它来进行方案设计。但是，如果无法对交付做出贡献，作为架构师的你要如何维持编码技能？

在工作之外你往往有更多的空间来维持编码技能，从贡献开源项目，到不断尝试你感兴趣的最新语言、框架、API。书、博客、播客、会议和聚会都能达到这个目的。但有时候你必须跳出代码。这些事我当然都做过，乘坐公共交通工具长途通勤的一个好处是你有时间去玩技术。当然了，前提是你经过一天的辛勤工作还不犯困的话！

软件架构师和雇主之间的矛盾

我很幸运，我的软件架构角色中有相当部分的实践元素，大多数我参与的项目都有我的代码。我坚定地认为，机会是自己创造的。我仍然动手实践的原因可以这样表述：它是这个角色的重要组成部分。对我来说这很简单。设计软件时，编码是必不可少的，因为我需要熟悉最新的技术，搞清楚我设计的哪些东西能工作。另外，我得承认编码很有趣。

可惜，许多组织似乎认为编码是软件开发过程中最容易的部分，因此他们通常让另一个国家的其他人来做这件事，以为这样能省钱。好的代码在这样的组织看来也是“低价值”的。组织中软件架构师的资历和编码工作的价值就脱节了，矛盾由此产生。

以我的经验，小组织不会发生这种事，因为需要人手时每个人都要参与进来。是的，那些大型组织里的矛盾最严重。我曾在一个中等规模的咨询公司工作过一段时间，我的职位等级把我归入管理团队，但我仍会写代码。在某些方面，顶着“行政经理”的头衔，又能每天写代码，真是了不起的成绩！但有时这也让人很不舒服，因为其他经理经常会试图在其组织架构图里加上我的名字。

陷入这种情况是很麻烦的，只有你自己能摆脱它。无论你是在一个正在发生这种事的组织，还是想要离开是非之地，都要搞清楚你对软件架构师这个角色的看法，并准备好坚守自己的立场。

你不必放弃编码

说到这一点，我会经常被问及“如果软件架构师打算在公司的职业道路上有所作为，是否还能继续编码”，也就不奇怪了。这真是羞耻，尤其是如果这些人真的很喜欢他们所做的技术。

对此我的态度绝对是肯定的，你可以继续写代码。对我来说，听到人们说“好吧，为了成为架构师或在职业道路上更进一步，我明白自己不得不放弃编码了”，是相当令人沮丧的。有很多组织是这样的，肯定有很多人被告知组织中的高级职位不需要写代码。

软件架构师在满足非功能性需求、进行技术质量保证、确保软件符合其用途等方面，要承担很大的责任。这是一个领导的角色，编码（以身作则）是保证项目成功最好的方式之一。此外，如果软件架构师不保持技术能力，谁来培养更多未来的软件架构师？

不要把全部时间都用于编码

重申一下我的建议，软件架构师不必放弃编码。无论你怎么做，在不断变化的世界中，编码是一个保持技术能力的好办法。很多人认为软件架构是一种“后技术”的职业选择，但除了丰富的经验和更宽的知识面，它还需深厚的技术能力，需要能够回答设计是否真的管用这类问题的T形人才。把这归为“实现细节”是不可接受的。只是别把时间都花在编码上。如果你花全部时间写代码，那软件架构角色的其他部分由谁来扮演？