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频道或任何其他信息在空中飞行并停留在我们的脑海中的工具。相反，我们把一切都写下来，只有在明确要求并支付费用的情况下，我们才会交谈—在工作票中。
Bugs
考虑到这一点，一个合理的问题可以提出：如果软件架构师无法与团队进行沟通，他/她如何能够实施他/她对团队的技术愿景？下面是我们的答案：架构师必须使用“bug”。
bug是一个具有报告人、问题和解决人的票证，就像这篇文章所解释的那样。假设一个架构师审查了一个现有的技术解决方案，并发现了与他的愿景相矛盾的东西。当发现这样的矛盾时，它就成为了一个很好的bug候选。有时代码中的信息还不足够，这也是一个很好的bug候选。
因此，架构师报告的bug成为他和团队之间的沟通渠道。架构师不解释需要做什么，而是要求团队按照他认为正确的方式修复产品。如果票证的解决人，也就是团队的成员，不同意这种方法，就会在票证中开始讨论。
有时架构师会有疑虑，需要与团队讨论几种可能的解决方案，或者只是收集意见。我们再次使用bug来实现这一点。但是这些bug并不是报告源代码中的问题，而是抱怨文档不完整。例如，假设架构师不知道该使用哪个数据库，MongoDB还是Cassandra，并需要更多关于它们的优缺点的信息。一个bug将会是“我们的设计文档中没有现有NoSQL数据库的详细比较，请修复它。”被分配到这个票证的人将进行比较并更新文档。
bug是架构师的一种积极工具。通过报告bug，架构师影响项目并“发号施令”。
Reviews
在我们的项目中，每个工单都在自己的分支中实施。当实施完成后，所有工单都要经过强制性的代码同行评审。换句话说，开发人员会相互审查彼此的代码。架构师不参与此过程。
但是，在同行评审完成后，每个工单都会交给架构师，他必须在代码通过我们的合并机器人Rultor进入主分支之前给出最终的“确认”。
这是架构师控制的机会。这是他可以防止他的构想被破坏的地方。当由开发人员创建的代码违反项目设计原则或整个技术理念的任何部分时，架构师会说“不”，分支会被拒绝。
评审是架构师的一种“被动”工具。通过严格和不妥协的代码评审，架构师强制执行他的设计和架构原则。
附注：架构师向项目经理报告的方式如下：我对软件架构师的三个期望。
Translated by ChatGPT gpt-3.5-turbo/36 on 2023-09-30 at 05:15
