软件架构师是什么？他们应该写代码吗？

作者：Ahmad Nassri 文章来源： Medium

这几年来，我发现自己常常做着“软件架构师”的工作，这让我意识到，公司很少了解软件团队的真正需求，反而倾向于依赖所谓“软件架构师”来解决问题。

随之而来的，就是因交付前产品不符合商业预期、而导致的产品架构大规模修改，但这甚至不会影响产品交付日期。毕竟，软件架构师的责任正如其名：建立宏大而优美的软件架构。软件架构师并不需要对架构实现过程负责，他们也并不想参与代码编写工作。

我记得有一回，我在团队中作为开发者，着手实现一个大型、复杂的架构。我是在开发已开始后加入团队的，并没有参与架构设计，所以没过多久，我对整个架构的设计就产生了一系列疑问，比如软件架构师打算用 MySQL 作为数据库，配合一套复杂的前端缓存程序、一些自制的库和函数，完成软件的国际化和本土化。

产品是个简单的应用程序，作用是将译文字符串用多种目标语言展示，我认为软件架构师明显杀鸡用牛刀了。

团队讨论这个问题时，我建议我们用免费轻量的现成替代品，比如 gettext，它支持几乎所有系统和主流编程语言。不幸的是，我的建议被否决了，因为软件架构师的话是神圣不可侵犯的。我意识到：

• 这位软件架构师没有听过 gettext，也没有任何兴趣去了解它。

• 他喜欢用“自己的方式”解决问题，就算其他方案更简单，他也不喜欢改变。开发成本、产品效率什么的，统统与他无关。

• 如果他要去写代码，实现自己的架构设计，他肯定会意识到这个方案将问题复杂化了，坚持这么做会浪费非常多时间，然后也许会考虑修改架构。

一个不写代码的软件架构师，对于软件开发团队、产品甚至公司，会有什么影响？

安东尼·兰斯沃斯（Anthony Langsworth）在著名的 《软件架构师是否应该写代码？》 一文中对此进行了精辟的分析，文章开头提到了一些软件架构师的反面形象典型：

不写代码的软件架构师，有时被称为“PPT 架构师”、“宇航员架构师”、“象牙塔架构师”，他们有特殊的说服技巧，能让不懂技术的股东们觉得他们很厉害，同时把真正困难而待解决的问题交给开发者，这个现象屡见不鲜。（编注：这些名称指不写代码的软件架构师指不接地气，“特殊的说服技巧”原文为  archibabble and talkitechture ，分别取前后两端为 talkybabble，“夸夸其谈的架构师”之意）

这文章同步到 LinkedIn 后也遭到了 热议 ，人们对于“软件架构师是否应该写代码”这一问题有许多不同意见，部分意见很有意思，但很难令人信服。然而这些讨论中全都忽视了一个重要前提：具体情境。

准确的说，如果想要对“软件架构师是否应该写代码”得出确切结论，必须讨论这些前提：

• 项目属于哪个行业？银行、科技、电信、广播……？

• 公司规模多大？

• 有现成开发团队吗？还是正在打造开发团队？

• 开发团队规模如何？

• 预期产出是什么？（应用程序、服务还是创新？）

咱们一个个来看——

行业

软件本身和行业无关，难道不是这样？

我为不少互联网公司服务过，它们所属行业包括在线发布、广告和社交媒体，这些行业相似且相关，这让我了解了这些行业中的先进技术、行业间有何联系、一些变化会造成什么影响以及跨行业的创新情况。

如果对当前工作行业的相关行业不能深入了解，软件架构师就不能成为这个行业的专家。我会花上一定时间了解相关行业，尝试新的东西：比如去化工行业的公司考察后，我就能思考，如果到时候需要为他们设计软件，会遇到什么问题。

但我十年的网页和移动程序开发经验有什么用呢？在设计化学流程模拟器架构时，我怎么样才能比那些有过化学行业开发经验的人做得更好？此外，化工公司大多甚至不需要软件架构师b，而是需要有计算机科学背景的化学家、化学工程师，他们更适合做这类软件开发的领头人。

同样的，音乐行业也不需要软件架构师，他们需要的是音乐家（亦是有计算机科学背景的）和软件开发商，后者并不用懂得音乐理论。Spotify 和 iTunes 并不算意外情况，它们甚至不属于音乐行业，具体业务与音乐本身无关，它们更像是科技和娱乐项目，用于传播音乐。

让我们将范围限制到科技产业，简化讨论。

公司规模

一个开发团队，需要两名软件架构师吗？你听过成功的小规模创业公司有专业的软件架构师吗？

这不是“是否需要这个角色”的问题。创业公司根本无力承担专业软件架构师的成本，每个人都身兼数职，分担不同任务，就连创始人、CEO 和 CTO 有时候都要撸起袖子来顶工。

如果说不考虑创业公司，你的公司规模有多大？几百、几千、几万人？他们都专攻同一领域吗？工作都与科技有关吗？实际上，就连 Google、Apple 和 Facebook 这样的巨头，都会有一部分工作人员职责完全不与科技相关。

我们再缩小讨论范围至“软件开发部门”，这个部门完全专注于业务的技术部分。那么，这个部门真有必要雇佣专人，来协助部门之间的沟通、收集需求、最终把握项目方向吗？

如果你真的认为，不论如何都需要一位软件架构师来完成这些任务，那你有必要恶补关于产品开发管理的 基础知识 。

归根到底，软件架构师在大公司软件开发部门到底有什么职责呢？或者这么问：“专业的软件架构师，对于这个部门有什么贡献呢？”

下面我从团队规模的角度来为你解答。

团队规模

你的软件开发部门像小团队一样整体运转吗？还是被分割成几个团队，分别专注于不同的项目？

根据我的经历，如果任务和责任明确，软件架构师在任何软件开发团队中都会成为累赘。

“这和我的职责无关！”、“这就是我的职责，我来决定我们应该怎么做！”我已经听厌倦了这两种论调，这些论调持有者都是团队蛀虫，影响团队协作。

斯科特·W·安布勒（Scott W. Ambler）警示了这点，并总结了“象牙塔架构”的 危险所在 ：

通常“象牙塔架构”由一名或多名架构师设计而成，他们与真正的开发团队和流程相对生疏。这些貌似大牛的架构师们，会给出一系列模型用于描述架构，不明觉厉的开发者就只能乖乖就范了，因为架构师永远伟大光荣正确。

由多个小规模团队（大约 15 人或以下）组成的大型软件开发部门，与多个小规模团队并没有什么区别，每个团队都要面对待解决的问题、项目完成期限和随之而来的压力。

那么谁来为这些小团队的软件架构负责？

安布勒写道：

对于小规模团队有个较为简单的解决方案：所有人都对项目架构负责。与其他人 一起设计 能够让你懂得合作的必要性，而且说真的， 不论一个人有多聪明，他都很难完全掌控项目架构 ，让团队来做效果会更好。

每个人都参与了设计，所以每个人都会更进一步了解和接受架构，而且这样做还能提高架构灵活性，当发现缺陷和问题时，开发者们会更加愿意让它作出改变。

当软件架构师一人设计出“成果”时，他会将其视为“自己的孩子”，没有人愿意听到别人批评自己的孩子，同理，架构师会抵触任何批评。而若由团队设计架构，成员们更多时候会考虑团队因素，“这不是一个人的事情”，从而乐于反思。

当软件开发部门就是一个整体时，这个策略就无效了。

团队很大，或成员地理位置很分散，这两个敏捷调整模型（Agile Scaling Model，ASM）中的因素能够影响“所有人共同设计架构”的策略，此时你应该把整体打散成几个小团队，因为“共同设计”策略要求整体协作。

有时候软件开发部门需要某种形式的整体方向和指导，以确保部门生产力用在了正确方向、以及与其他部门能够顺利沟通和协作。

在我看来，这就是少数需要软件架构师的时刻。然而，软件架构师应该代表软件团队与其他团队进行什么互动呢？或者它仅仅是个单向输送信息的角色？ 并非如此，软件架构师的职能不因环境而变：除了设计架构外，还要承担起促进沟通、攒写文档的责任，统一认识并作记录，起指导作用。

终于为软件架构师找到一处用武之地了！

预期产出

你的团队在设计应用程序，还是写网页？/

我们已经讨论了行业、公司和团队规模，但最终我们要做的是项目本身。如果你团队唯一的“项目”仅仅是制作简单网页，只需要一点 HTML/CSS 技能，还讨论架构的话……

现成开发团队 vs. 打造开发团队

你现在的开发团队结构存在缺陷吗？你是否打算雇佣软件工程师来解决问题？

如果你目标是扩大团队，那很有可能你已经有了软件架构师的候选人，他/她是领域专家，而团队其他成员需要加强合作跟上他的步伐，领会并实现架构。 “软件架构师”的名分并不重要，如果某个员工为这名分斤斤计较、特别想成为“软件架构师”时，我会考虑这个人是否适合继续留在团队中。

有句名言是：“那些没法干活的，教他们应该怎么做。”我强烈反对这一点，但具体原因这里不赘述，请移步 这个博客 查看。

乔·温彻斯特（Joe Winchester）把这个名言 改编了一下 ：“能写代码的写代码，不能写的去写架构。”虽然这观点看起来充满偏见，但文中有个好例子，说明了软件架构师这角色职责错位的状况：

当项目遇到问题、项目管理者问责时，软件架构师可以把原因归咎于程序员，“嘿，我早说了，要你们应该用 BOJOX 和 NADA 2.0 ，现在出 bug 了吧。”项目管理者有了这些“原因”，就能把开发报告写得冠冕堂皇，证明团队需要一年来重写这个项目。然后管理者大可以趁着“不做就不犯错”的这段时间，将期权变现后跳槽。

乔尔·斯波斯基（Joel Spolsky） 这么 描述他遇到的挫折：

有时候这些聪明的思想家不知道什么时候应该止步，他们能创造荒诞、无所不包的宇宙，但，那毫无意义。

如果你正在打造一个开发团队，那么请专注于项目本身。

“自下而上”的打造团队，聪明、勤奋、有强烈学习欲望的程序员是一切的基础，让每个人对项目架构有同等发言权，不要遏制创新，“软件架构师”的名分并不重要。这样你的队伍就会变得乐观而高效率。

总结

不是所有行业都需要软件架构师，一般能遇到的大多问题都已经有解决方案了，你需要的是执行者，全栈工程师（Full stack software developer）才能完成公司目标，保证产品质量和客户体验。

不管一个人有多聪明，他都很难完全掌控项目架构。

当项目架构由整个团队设计和完善时，团队成员们会更有协作意识：乐于承担责任，接受意见和进行修改。

关注最终目标：如果团队预期产出是软件上的创新，那你应该考虑雇佣软件架构师，让他来写解决方案、指导团队。如果你公司是 B2C 平台，不要浪费时间考虑这个问题，专心做好业务。

看到这里，希望你对软件架构师的职责、价值和雇佣时机有了清晰认知，那么回到最初的问题：“软件架构师应该写代码吗？”我想用一段话来回答——

几个世纪以来，熟练的石匠、建筑熟练工、细木工、半吊子、有天赋的外行，和专业建筑师（architects）之间的界限已经越来越模糊。以文艺复兴时期的建筑为例，很多就不是由建筑师设计：布鲁内勒斯基（Brunelleschi）曾是一名画家和金匠，米开朗基罗（Michelangelo）是雕塑者，达·芬奇（Leonardo da Vinci）是画家，阿尔贝蒂（Alberti）是律师，只有布拉曼特（Bramante），作为画家，曾专业地学习过建筑学。这些人之所以被成为建筑师，仅仅是因为他们设计了著名建筑，就是这么简单。——《世界上最漂亮的房子》，加拿大建筑设计师维托尔德·雷布津斯基（Witold Rybczynski）