The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
一个软件架构师在任何规模的软件项目中都是一个关键人物。架构师在技术成果上负有个人责任。一个好的架构师知道需要做什么以及如何进行架构和设计。为了在实践中强化这个想法，架构师使用两个工具：错误和审查。
在Zerocracy中，我们不鼓励开发人员之间的任何沟通，除非他们正式附属于我们正在处理的票据或任务。请在这篇文章中阅读更多关于这种方法的细节。
对架构师也适用同样的原则。我们不使用会议、站立会议、Skype电话、IRC频道或任何其他信息在空中传播并停留在我们脑海中的工具。相反，我们将所有内容都以书面形式记录下来，只在明确要求并付费的情况下才进行交流—通过票据。
考虑到这一点，可以提出一个合理的问题：如果软件架构师无法与团队进行沟通，他如何能够执行自己的技术愿景呢？这是我们的答案：架构师必须使用“问题”。
问题是一种具有报告者、问题和解决者的工作票，就像这篇文章所解释的那样。假设一个架构师审查了现有的技术解决方案，并发现了与他的愿景相矛盾的地方。当发现这种矛盾时，问题就成为了一个很好的候选对象。有时候在代码中还没有足够的信息，这也是一个很好的候选对象。
因此，架构师报告的问题成为他和团队之间的沟通渠道。架构师不解释需要做什么，而是要求团队以他认为正确的方式修复产品。如果问题的解决者（团队成员）对这种方法持不同意见，讨论就会在问题中开始。
有时候，架构师会有疑虑，需要与团队讨论几种可能的解决方案，或者只是收集意见。我们再次使用问题来实现这一点。但是，这些问题不会报告源代码中的问题；相反，它们会对不完整的文档进行投诉。例如，假设架构师不知道要使用哪个数据库，MongoDB还是Cassandra，并且需要更多关于它们的优缺点的信息。问题会是“我们的设计文档没有对现有的NoSQL数据库进行详细比较，请修复。”被分配到这个问题的人将进行比较并更新文档。
问题是架构师的一种积极工具。通过报告问题，架构师影响项目并“发号施令”。
在我们的项目中，每个工单都在自己的分支上实现。实现完成后，所有工单都要经过强制的代码同行评审。换句话说，开发人员会相互审查彼此的代码。架构师不参与此过程。
但是，当同行评审完成后，每个工单都会交给架构师，他必须在代码通过我们的合并机器人Rultor进入master分支之前做出最终的“OK”。
这是架构师掌控的机会。这是他可以防止自己的设计被破坏的地方。当开发人员创建的代码违反了项目设计原则或整个技术理念的任何部分时，架构师会说“不”，并拒绝该分支。
评审是架构师的一种被动工具。通过严格而不妥协的代码评审，架构师强制执行自己的设计和架构原则。
附注：以下是架构师应向项目经理报告的三个期望：《我对软件架构师的三点期望》。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:30
