最近读到一篇很棒的软件开发文章，讲述了大型团队如何有效合作开发，做一下翻译。

首先贴一下原文链接

项目挑战

        如果经理想了解项目状态的真相，他们应该在twitter上关注开发团队的动态了。

        虽然编写代码很容易，但是开发软件却是一个很困难的事情。这种困难体现在很多方面，但是其中最具挑战性的方面之一却不是技术，而是简单的团队沟通。

        团队沟通的重要性体现在：

• 如果你解决了错误的问题，那么你的解决方案毫无意义。
• 如果你不知道到哪里寻求帮助，那你就是在浪费时间。

        如果你的团队陷入困境，解决错误的问题，浪费时间，那么作为一名经理，你就是失败的。特别是远程工作时，这些问题会被放大，因为你看不到你的队友在电脑桌前因为一些问题而苦苦挣扎不能得救的样子；即使他们知道该向何处求助，他们可能仍要等待12小时才能得到回应，比如一个开发团队在美国的中国维护团队，或者相反。

        所以显然，我们想解决团队沟通的问题。如果几个小小办公室的小团队都这么艰难，那么分布在世界各地的大型OpenSource项目如何能够在预算内按时交付高质量的代码？

        大多数开源项目都采用了三个指导原则：Awareness, Autonomy & Automation。这三个简单的原则使跨越几个文化背景迥异的时区的大型团队能够轻松发布软件。

Awareness-团队意识

        历史不是为了今天而记录，而是为了明天记录的。在OpenSource项目中，所有通信过程都是开放和可见的。电子邮件不会在成员之间私下发送，而是组内群发的。任何软件项目都应该如此。办公室的白板似乎是跟踪流程的好地方，但请记住，并非每个人都能看到白板。使用每个人都可以看到的通信渠道。

        当所有其他通道都难以推行时，请记住，提交历史记录是第一通信渠道。我每天从阅读提交历史开始，看看我们一起开发的软件发生了什么变化。一个好的源代码管理系统会将把代码行与相应的提交消息链接起来，使得团队中每一个人都能够准确地看到为什么添加了一行代码。

        使用提交历史记录来讲述您的软件是如何开发的，如果您讲述了一个好的故事，您将感谢自己。记住：6个月后，你遇到最愚蠢的开发人员是你；6个月前，你遇到最糟糕的开发者也是你。即使是为自己，记录提交历史也是必要的。对于一个花费了数小时、数天或数周时间实现的某个功能，花10分钟来解释清楚 “ 谁、在哪里、何时、如何、什么和为什么 “ 是不为过的。一条提交历史记录应该是提供了关于一个功能易于阅读的系统开发过程记录的。

        总结来说就是：

        1. 需求讨论的邮件 

        2. 代码提交的提交记录

Autonomy-自主意识

        代码是会说话的，文字是会流通的。

        所有的开发者都应该赢得他们的荣誉。任何人，甚至新聘的万物首席高级工程师，都不应该在第一天就被授予对源代码控制系统的写访问权限。团队中的每个人都必须通过学习系统、陷阱、坑、设计等来获得访问权限。所有开发人员都应该使用他们正在开发的系统来帮助影响设计。

        虽然在获得该系统之前，任何人都不应该被授予访问该系统的权限，但所有开发人员，甚至是一年级的合作学生，都应该在第一天对该系统进行更改，并看到他们努力工作的结果。当然，你在问如何在没有访问权限的情况下对系统进行更改？随着我们探索OpenSource项目的运行方式，答案将变得清晰。（code review的参与）

Automation-自动化构建

        持续开发，持续部署。

        对系统的每次更改、对存储库的每次提交、每行代码都应该产生一个可用的系统。工程师在任何时候都不需要回滚更改，或者只需修复最后一个测试用例即可部署工作构建。所有更改都应在提交之前进行全面测试。当然，这意味着所有开发人员必须能够在本地机器上运行完整的构建，包括所有测试用例。
        项目的构建步骤不应超过2个。1） 结账代码；2） 构建。如果你的系统需要更多的工作，那么你就做错了。如果您需要一个包含数据库表和web服务器的复杂环境，请考虑在构建时附带一个Docker文件，以实现自动化。
        自动化构建应该做的不仅仅是构建软件，它应该在开发团队的零工作量下验证更改。特别是，构建应该：

• 编译源代码
• 链接工件
• 运行自动化测试套件
• 自动检查代码约定和格式规则
• 运行静态分析和其他工具以确保代码结构正确

        所有开发人员都应该可以在本地计算机上访问此构建，并且相同的自动构建应该在持续集成服务器上运行。

代码验证        

        一个好的代码审查系统，如Gerrit，位于所有开发人员和主存储库之间。团队中的每个人都会将他们的更改推给Gerrit，在那里启动自动验证工作。这将检查代码是否编译、是否符合约定、是否通过回归测试等。如果有任何失败，开发人员可以修复其提交并再次推送。只有在通过自动验证后，团队中的另一位工程师才能查看。

        许多OpenSource项目允许任何人将代码提交到他们的代码审查系统。这意味着任何人都可以克隆存储库并提出更改。每个更改都可以在团队不做任何努力的情况下进行验证，并且只有在提交准备好进行审查时，开发人员才需要花费精力来查看它。有了良好的代码审查系统、自动化构建、自主团队和扎实的团队意识，您可以按时按预算交付高质量的代码，而无需将所有工程师迁移到同一个城市。

code review-代码审查

        当我和其他高级工程师谈论这件事时，我经常听到这样的话：我们有时会进行代码审查，以便高级工程师可以审查初级开发人员的工作。

        我觉得这个事情有的时候也是不对的，仅仅依赖高级工程师是很容易形成一言堂，代码审查面向团队中的每个人的，原因如下：

• 新团队成员应审查代码，以更好地理解系统
• 高级工程师应审查代码以分享智慧
• 聪明的无知者应该能够审查任何人的代码并给出建设性的反馈

        更改可能会反复多次，然后才最终被接受。代码评审系统为团队中的所有开发人员提供了一个机会来讨论提议的更改，甚至协作改进它。当更改最终获得批准时，具有提交权限的开发人员可以按下提交按钮，将更改合并到主存储库中。

最后

        这些建议中的许多可能看起来像是疯狂的谈话，但是仍然有可圈可点的地方：

• 在第一天没有访问权限的情况下对系统进行贡献
• 确保每个提交都是完美的
• 零工作量验证每个更改
• 一个可靠的自动验证代码审查系统，几乎没有直接通信。