The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
你很可能知道我对软件项目中架构师角色的看法——他是一个独裁者，负责所有技术决策，并对最终结果承担全部责任。我写过这方面的文章，甚至在2016年的BuildStuff大会上发表了一个演讲谁是软件架构师？。然而，你可能会问的一个显而易见的问题是：如果架构师错了怎么办？这是否意味着整个项目面临失败的风险？与其只有一个单点故障，是否让整个团队对结果负责会更好呢？
这个问题确实很明显。独裁是一个很好的管理模式，前提是独裁者是聪明的。这意味着，首先，他要有能力1）分析现实情况，2）收集所有可用的不同意见，3）寻找最佳选择，摒弃个人情感。有多少人真正能做到这一点？ 没有 很少。
其他大多数人很可能会滥用权力，变成一个不听任何人的坏独裁者，不关注不同的意见，凭个人感情做出技术决策。有多少这样的软件架构师存在？ 全部 很多。
解决办法是什么呢？
我们是否可以首先摒弃独裁者，让团队决定正确的架构？我们是否可以用民主取代独裁，并让软件开发人员以某种方式进行投票，以避免单点故障？他们都将对产品负责，并且当产品出现问题时，他们都将负有责任。对吗？
“质量和责任除非个人承担，否则毫无意义。”我在我的书《Code Ahead》(/code-ahead.html)中这样说道。团队责任是一个团队可能犯的最可怕的错误。所以，不要！不要投票，也不要民主。
想象一个真实的项目，其中一位建筑师决定使用MongoDB（一种NoSQL数据库）来持久化用户支付信息。这是一个值得质疑的决定，因为传统上，关系型数据库被认为是处理金融数据的更好选择。然而，我们知道这位建筑师是独裁者，我们不能反驳。我们不能告诉建筑师这个决定是错误的。而且，我们也不应该要求建筑师说服我们。决定已经做出了。
我们可以回忆一下，架构师唯一真正的上司就是需求。架构师可能不听我们的话，不听开发人员的话，不听客户的话，也不听任何人的话。但需求是无可争议的上司。需求文档中是否提到了数据库的选择？很可能没有提到。所以架构师的做法是正确的。需求要求支付必须持久化，而且它们确实持久化了。需求要求系统每秒能处理多达一百笔支付，而且它确实做到了。那么，问题出在哪里呢？
嗯，我们只是感觉选择MongoDB可能是个糟糕的主意。这只是直觉。但也许我们错了，架构师是对的呢？
为了使情况更明确并解决冲突，我们必须修改需求文档。我们必须说出这个特定决策需要的其他要求。比方说，我们添加这一行：
一旦批准了这个需求条款，架构师就必须改进产品文档。必须对MongoDB、PostgreSQL、Oracle和其他一些数据库进行分析。将定义一些选择标准，架构师将提供一些数据来使选择MongoDB看起来合理。
一旦完成，架构师的意见将变成一个数字化的工件，可能会存在缺陷。有多少缺陷以及我们多快找到它们成为一个管理问题，相对容易解决。我们只需要几对额外的眼睛来查看这个工件，并告诉我们其中有什么问题。例如，我们可以要求团队中的某个人审查分析并告诉我们存在什么问题。或者我们可以雇佣市场上的某个人，虽然很昂贵，但是是数据库管理领域的专业人士。
一旦有缺陷被报告，架构师必须以某种方式解决它们。要么改进分析，要么改变决策，如果事实开始对决策不利。
项目的风险容忍度越低，我们就需要更多的眼睛来审视架构师所做的决策。如果质量非常重要或者架构师的专业水平有问题，我们需要记录更多的决策并进行更频繁的审查。这是一个简单的数字游戏。如果完全信任架构师，并且项目不昂贵且只是短期的，我们就让架构师随心所欲。
另一方面，如果架构师是初级的，而项目对我们非常重要，我们必须要求大多数技术决策都要被记录和分析。我们必须尽可能多地组织对这些文件的审查，甚至邀请独立专家。
因此，总结我的观点，我们不能期望架构师是一个能够解决所有问题的专家。另一方面，我们也不能用民主投票来取代架构师。这两种想法都是错误的。正确的方法是通过定期审查来控制架构师所做决策的质量。
你的项目中有这样的审查吗？如果没有，为什么没有？
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 13:42
