The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
二十五年前的1992年，在温哥华的一次OOPSLA研讨会上，肯特·贝克在回答“什么是架构师？”的问题时，根据菲利普·克鲁彻滕的说法，他表示这是“程序员们要求在名片上加上的新光鲜亮丽的头衔，以证明他们丰厚的报酬是有道理的。”自那以后，并没有太多改变。优秀的架构师与聪明的程序员之间有很大的区别。以下是我认为一个好的架构师具备的特点的列表。
免责声明：尽管我一生中从未见过一位女性软件架构师，但为了方便表达，我必须对我的左翼/女权主义读者说，在这篇博客文章中，我假设架构师是男性。这并没有任何冒犯任何人的意图。
程序员来来去去。正如我之前多次提到的，他们是以个人利益为重的自我主义者。他们会更换项目，同时参与多个项目，对任何一段代码都没有个人情感依恋。他们只关心自己的任务和功能分支。分支合并了？一切都不确定了。专业的开发者是“多元婚姻”的，不忠诚的。
然而，架构师是另一种生物。即使项目资金耗尽，失去了最后一个程序员，并证明架构是一团糟，无法处理预期负载的一小部分，架构师仍然留下来并说：“别担心，我们会度过难关的！”如何找到这样一个人以及如何激励他是不同的问题，也许是另一篇博客文章的内容。
他有纪律。
设计模式、代码质量、静态分析、单元测试、高性能、可靠性、安全性甚至可维护性都是需要关注的重要事项。然而，优秀的架构师知道，只要正确雇佣、激励、组织和控制程序员，所有这些问题都可以解决和实现。如何雇佣、激励、组织和控制他们——这是一个好架构师所关心的问题。
他知道过程优先，人员其次。
然而，这并不是大多数软件专家所认为的。例如，根据艾利斯泰尔·科克本在2001年发表在IEEE计算机会刊上的文章《敏捷软件开发：人的因素》：「如果项目上的人员足够优秀，他们几乎可以使用任何过程来完成任务。如果他们不够优秀，任何过程都无法修复他们的不足——“人胜过过程”就是这样说的。」如果一个程序员这样想也可以接受，但对于一个架构师来说就不可以了。
一个架构师把纪律放在首位，不断创造新规则并强制执行。此外，他不仅要让别人服从规则，还要自己遵守规则。例如，这里就有一些要强制执行的规则：
每个想法都起源于一个工单；
主分支是只读的；
静态分析是强制的；
没有单例模式，没有getter/setter，等等；
单元测试对于所有新的更改是强制性的。
不要在票之外进行非正式讨论。
每个项目都有自己的规则。上面的列表是我们在Zerocracy的项目中的一部分。一个好的架构师首先考虑规则，其次考虑架构。
我完全同意Len Bass在他的书实践中的软件架构中所说的“架构应该是一个单一架构师的产物”。然而，问题是架构师将如何创建产品：是独自完成所有技术决策的独奏模式，还是让团队以有组织、有纪律的方式进行贡献。前者容易但效果较差，后者更困难，但能带来更强大的解决方案和更好的团队协同效应（我讨厌这个词，但在这里很贴切）。
马修·麦克布赖德在他的文章《软件架构师》（The Software Architect）中指出，2007年在CACM上发表，他说：“如果没有软件架构师的强有力监督，项目和尝试的解决方案往往会因无法减轻的复杂性而崩溃。”这里强调的是“强有力”。
在这个背景下，“强有力”是什么意思呢？是在办公室里连续待两天，只吃披萨和可乐的能力吗？是在内存中能够做到六位数乘法的能力吗？是能够记住所有类和方法的目的和设计的能力吗？是在与投资者开会三个小时而不查看Facebook的能力吗？很不可能。
架构师的强大之处在于能够在困难时说“不”。例如：
“不，我们不会实施这个功能。”
“不，你还不配得到升职。”
不，你的代码并不像我们期望的那样好。
不，此版本不稳定，不能发布。
不，这个月你不能去度假。
有许多其他的“否定”情况很容易让建筑师成为一个被憎恨的角色，但这就是他的工作：成为坏人。这也是为什么他必须坚强——要冷静处理一切并继续领导项目朝着他自己明确的技术目标前进。
抽象思维是建筑师非常重要的积极特质。程序员可能缺乏这种特质，因为他们主要关注自己的独立任务。建筑师必须全局思考，将产品作为一个整体来看待。细节并不那么重要。在讨论细节时，建筑师必须依靠自己的团队。
软件是人们的产物。无论架构师有多么优秀，如果他找不到合适的人来实现他的想法并带回新的想法，他注定会失败。架构师的关键素质是与人合作的能力：招聘、激励和控制他们的成果。社交技巧是架构师在这方面取得成功所需的，尤其是在寻找新的程序员并让他们参与项目。这到底意味着什么？嗯，以下是一些例子：
以前的项目和团队的长列表；
专业团体的积极成员;
博客圈中的宣传。
换句话说，一个好的架构师是那些在他周围拥有一大群追随者和支持者的人。我在最近的演讲《你值多少钱？》中提到了这一点，演讲链接：How Much Do You Cost?，演讲地点：JEEConf 2017。
一个好的架构师每天都会说很多次：“这是我的错。”如果一个架构师没有经常说这句话的习惯，他就不是一个优秀的架构师。他只是一个害怕责任和权威的程序员。
一个好的经理的黄金准则是：“成功归你，失败归我。”这是一个好的架构师对他的团队必须表达的态度。当他们获胜时，他会找到一种方式来庆祝和奖励他们。当他们失败时，他将全权负责失败的责任。因为这是他的团队，他发现了他们，他激励了他们，他控制了他们，他没有适当地惩罚他们。所以他们失败了。首先，这是他的错。
他会如何处理这个错误是一个单独的问题。也许他会培训和辅导某人，也许他会更积极地执行一些规则，甚至可能会把他的名片交给某人。这取决于架构师。但对于外界来说，他将永远是有罪的，团队必须知道这一点。如果他们知道了，他们会尽一切努力不让架构师失望。
1984年，Edsger Dijkstra说过：“简单是一种伟大的美德。”对于程序员来说，这是一种美德；对于建筑师来说，这是一种生存技能。一个建筑师如果无法用简单易懂的语言向其他程序员解释自己的思想，那他就不是个建筑师。无论他多聪明，无论他的想法多么出色，如果不能以简单的形式传达出来，那就一文不值。
2015年，Yegor Bugayenko说过：“如果我听不懂你，那是你的错。”一个优秀的建筑师会铭记这句话。
Anthony Langsworth在他的文章Should Software Architects Write Code?中支持写代码的架构师，并特别表示：“理解代码意味着架构师可以更有效地运用自己的判断力，而不是依赖于哪个开发人员更有说服力。”事实上，一个只会说话和画图的架构师是一个薄弱的架构师，迟早会让团队和项目失望。
架构师需要编写多少代码取决于项目的年龄。当项目还年轻，处于原型阶段时，架构师会产生大部分代码。然后，当产品成熟后，架构师会退居幕后，主要审查程序员的贡献。最终，当项目进入维护阶段时，架构师可能会退出项目，将他的责任转交给其中一位程序员。
他有雄心壮志。
建筑师除了钱之外还想得到其他东西。他想成为房间里最聪明的人，他想解决其他人之前无法解决的复杂任务，他想拯救世界。他希望这一切都被赏识和奖励。他想成为第一。在大多数情况下，他都失败了。但他总是能重新振作起来并再次尝试。如果你想雇佣一个建筑师，就要寻找有抱负的人，而不仅仅是又一个程序员。
迈克尔·基林在他最近的书籍《从程序员到软件架构师》（值得一读）中说：“在一些团队中，架构师是一个正式的团队角色。在其他团队中，没有明确的角色，团队成员共同承担架构师的责任。一些团队说他们没有架构师，但仔细观察，会发现有人在履行架构师的职责，只是他们自己没有意识到而已。如果你的团队没有架构师，恭喜你，你得到了这份工作！”
迈克尔的观点是，架构师的职位很少是自愿给予的。相反，架构师必须为此而奋斗并要求这个职位。有时甚至可以直截了当地说“我想成为架构师！”
重要的是，他的表达不会像“我想设计这个”。那是一个程序员的声音，而不是一个建筑师的声音。建筑师想成为一个有权力的人，而不仅仅是一个聪明的技术工程师。所以，对他来说，这更多地是关于一个头衔，而不仅仅是他实际的职责。
他是昂贵的。
是的，钱的问题又来了。一个优秀的建筑师是昂贵的。如果他不贵，那他就不是一个好的建筑师。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:17
