作者：Jimmy Song
来源：https://bitcointechtalk.com/a-gentle-introduction-to-bitcoin-core-development-fdc95eaee6b8
如果你是一个开发者而且拥有比特币，给 Bitcoin Core 作贡献可能是你助力投资的最好办法之一。在本文中，我会给 Bitcoin Core 软件的贡献流程作一个轻松的分步介绍。
你想成为 Bitcoin Core 开发者吗？
在我们讨论为 Bitcoin Core 作贡献的实际细节之前，有几件事得先明确。
首先（也是最重要的），Bitcoin Core 是一个精英治理体系。作为一个初学者，你想提出一个对比特币工作量证明的变更并让它合并到 Bitcoin Core 代码库中是不太可能的。就像其它精英体制一样，你要从默默无名开始，自己努力前进。
好消息是，在这里也没有人在乎你的背景。无论你是一个 14 岁的印度少年，还是一个世界 500 强公司的 45 岁 CTO，唯一重要的是你的工作质量。
相应的坏消息，就是你必须自觉把你的自大丢在一边。没人在乎你有多少年的工作背景、你有多么棒的想法来修复比特币的缺点。你的代码、评审意见、文档和测试的质量，是大家唯一重视的事。
其次，你应该相应调整自己的预期。重要的 Bitcoin Core 开发者，比如 Pieter Wuille、Cory Fields 和 Gregory Maxwell，都是在 多年 的呕心沥血和笑泪相加之后才得到尊重的。提出一个矫正了拼写错误的 PR 不会让你获得 Pieter Wuille 那样的尊重。优秀的工作会让你获得理解和尊重，但也只有在你持续产出一段时间以后。
第三，这条路不好走。能够成为某个公司的顶级开发者，并不必然意味着你能成为一个好的 Bitcoin Core 开发者。这里面有许多原因，但总的来说，你的工作必须符合非常高的测试、文档和代码评审标准，这一切甚至在非常有能力的技术公司中也不常见。
这一切的意思就是说，如果你拥有谦虚的品质、自我驱动力和追求卓越的愿望，那么为 Bitcoin Core 作贡献将让你成为一个更好的开发者、代码评审员、文档撰写人和测试员。
前提条件
你需要一些知识和技能才能开始。
Bitcoin Core 主要是用 C++ 和 Python 两种语言编写的。如果你想参与开发，你可能两种语言都得至少懂一点。
源代码控制是通过 Git 来管理的。最起码，你要懂得如何从远程仓储 fetch、创建新的主题分支以及 rebase。如果你要测试其他人的代码，你还得懂得如何为你本地的开发环境添加多个代码库，这样你才能 fetch 和测试代码。
Bitcoin Core 所有的代码变更都是通过基于 Github PR 请求的 PR 来合并的，所以你需要一个 Github 账户。
最后，你还需要知道如何在你的平台上安装和移除代码包。这个操作非常细致，但很有用，比如在你想按需要添加和移除 ZMQ 的时候。
起步
起步要做的第一件事是阅读文档。这份 README 和贡献手册都是很好的起点。
然后，请转到 doc 目录并阅读那里的 README 文档。doc 目录中所有的文档都可以在 README 中找到，所以你无论是迷失了还是感到困惑了都可以跳转回来。
注意，你不需要理解我推荐的所有文档里面的所有东西。在 IRC、StackExchange 和 Slack 上你会遇到许多友好的人，可以帮你解答你不理解的东西。
从源代码构建
现在你已经知道开发的基本工作模式了，可以从源代码构建了。首先，克隆 Bitcoin Core 的 Git 仓库：
git clone [email protected]:bitcoin/bitcoin
下一步是设置你的开发环境。这一步主要取决于你使用的平台，但编译时你经常需要做的事，所以值得细说一番。
此外，你还需要运行所有的完整性测试，所以在执行下列指令时请确保打开了 GUI 和 ZMQ。
设置好你的环境之后，如果某部分没有正常运行，请先在谷歌使用错误信息搜索，然后再提交文档 PR。如前所述，IRC、StackExchange 和 Slack 是很好的资源，但请不要做伸手党（问过于简单的问题），这样会浪费所有人的时间。
测试
现在你编译好了所有东西了，下一步是测试软件。幸好，Bitcoin Core 安排了多种多样的单元和完整性测试，可以检查你编译出来的软件是正常的。
首先，在本地运行单元测试（手册在此）。单元测试是跟其它所有东西一起编译的，所以你只需要运行最终的二进制就好。确保所有测试都通过了。如果某些测试没通过，可能你漏掉了一些指令。
所有的单元测试都通过了，你就可以在本地运行完整性测试了（手册在此）。你可能想要运行扩展测试（extended tests）。修剪测试（pruning test）的某些任务会很费时间，所以你以后运行完整性测试时可能会排除掉其中一些。
同样，你要确定所有测试都通过了。在最终的测试结果出现之前，你会在窗口里看到很多点。如果有测试没通过，就说明你可能漏了某些指令。不过有时候，一些基于 RAM 和 CPU 的完整性测试会有点反复无常。
贡献的分类
现在，你的系统已经搭建好了，你可以开始作贡献了！
你可能会认为，贡献就是添加一堆代码、发送一个 PR 然后等待圣杯降临。事实上，许多工作都是围绕着评审和测试人们提交的代码展开的。评审和测试可以帮助你理解一个 PR 得到合并的所有步骤。
- 某人创建了一个变更，并通过一个 Pull Request（PR）提交了代码。
- 一个或多个人评审代码。
- 一个或多个人测试代码。
- 足够多的人评审及测试代码之后，代码库的一个管理员会合并这段变更 —— 只有少数几个人有权限做这件事。
大部分人都误以为给一个开源项目贡献的唯一方式就是贡献代码，实际上，测试和评审对项目的成功更加重要。缺乏评审和测试通常是出现安全漏洞的原因，就像我们在最近的以太坊 Parity 客户端 Bug 中看到的那样。
最后，评审代码及测试不仅对项目有好处，对你也有好处！评审和测试会迫使你学习代码，给你更加深刻的理解，甚至比写代码还要多。
起步
为了熟悉贡献流程，你 不应该 从一开始就添加大量 PR。相反，作为一个新手，你最好从评审和测试其他人的代码开始。评审和测试往往也是瓶颈，所以你可以在贡献的同时为自己获得一些声誉。
值得一提的是，你知道为什么 Greg Maxwell 在开发者中拥有这么好的名声吗？因为他是一个非常棒的评审员和测试员。在指出代码可能会打破一些东西时，他拥有世界一流的耐心；他评审和测试的代码远比他自己编写的要多。我保证，在你自己评审和测试了一些代码之后，你会更佩服他。
此外，代码通常是一次写成，却要被阅读很多次。因此代码的评审是一个重要得多的步骤，因为它会暴露一段代码 “好不好读”。这里的经验法则是，你每发起一次 PR，都需要阅读三个 PR。在一开始，你的阅读比例甚至要比 3 更高。
如何评审代码
一般来说，你得先理解一段代码要做什么，然后才能为它给出高质量的评审意见。就像编程领域的老生常谈：写代码易，读代码难。所以你要花一些时间来深入理解代码。
为了理解一个 PR 的内容，你需要找出被使用的函数和方法，并在代码环境中仔细测试。如果你感到困惑，而写代码的人刚好在 IRC 中，你可以直接提问。大部分时候，PR 作者都非常欢迎评审员，因此会很乐意帮助你。
就像你评一篇文章或者一本书一样，你有许多需要关注的维度：
- 这段代码是否做了它该做的事？
- 这段代码是否经过了充分的测试？
- 所有的注释都是有用、准确的吗？
- 代码是否清晰、易于在未来修改？
一般来说，如果你发现代码的工作方式不同于你的想法，最好假设你其实搞不懂它在做什么，而不是开始说教。谦虚和机智可以让你走得更远。请记住，你这是在评论别人的 “孩子”。至少，你在一开始不妨问一些问题，绅士一点。通常来说这些程序员既不了解你，也不了解你的意图，所以要耐心一点。而且要分清楚到底是代码风格上的瑕疵，还是会导致程序崩溃的大问题。最好表现得像个尝试理解优化点在哪儿的学生，而不是一个门卫。
在你确定一段代码的目标之后，你就可以评论这个特性值不值得实现了。不过，在你建立起声誉之前，请不要表达可能被解读为负面意见的评论。
评审完代码之后，请使用合适的同行评议风格，在 RP 页面留下你的评论。如果你想表达否定意见，请重新开始，假设你并没有理解代码，跟作者交谈并提问，知道你可以保证这是一个糟糕的 PR。即使如此，也应该跟更有经验的讨论，以交叉验证。
如何测试
为了合理地测试，你必须从 PR 下载代码、再一次编译并运行测试。如果你可以想出一种手动测试新特性的方法，那当然好，但不是必需的。
大多数时候，PR 都包括了一项乃至更多测试。如果 PR 作者并没有提供测试覆盖率（test coverage），请多多理解 —— 重构一般不会因为明显的原因而失败。如果你认为某处应该有测试，你可以留下评论：“此处应该有测试”。最好你可以自己写一个测试，并让作者知道可以放在 RP 的什么地方！这是在你的评审对象中建立好印象的最好方法。
你的工作是测试，你要确保 PR 可以通过测试，而且测试的内容足以覆盖新引入的功能。在评审中，一种比较好的评论语气是：“要是测试能够覆盖这些那些场景，并测试这个和那个，那就更好了。”
在测试之后，确保自己在 PR 中留下评论表示你测试过了。
更好的 PR
最终，你将成长到自信可轻松创建属于你的 PR。一个 PR 可以是任何内容，从添加文档到对共识关键的功能。无论变更的内容是什么，创造好的 PR 的秘诀都在于使之易于阅读、易于评审。
为此，请不要在你的 PR 中一次提交 3000 行代码，这会折磨你的评审员。将这些变更切分成小于 300 行的、易于评审的提交形式（甚至应该少于 100 行），然后恰当地分组。举个例子，你应该将格式更改放到一次提交中，而把编码更改放到另一次提交，把代码块的大变动放在另一次提交中。
当评审员指出了某些东西或者提出了修改建议时，尝试理解背后的理由。如果你不理解，请提问，直到你理解了他们想让你干什么。如果你同意，作合适的修改并让你的评审员知道；但如果你不同意，请确保你跟他们开展了成熟、机智的对话，看看你能如何获得他们的认可。
适合起步的 PR
这是一些你现在可以贡献的 PR 点子（请记住，提一个就要读三个！）
- 制作文档，尤其是关于安装软件的，要清晰
- 为还未测试的东西编写单元和完整性测试
- 为尚未文档化的代码编写注释，以帮助其他人理解
结论
Bitcoin Core 所用的软件开发习惯跟其它领域的惯例有所不同。大部分加入 Bitcoin Core 开发的人都认为这个流程过于严格。但我向你保证，每一笔都是有原因的。
请记住，要礼貌、温和及明智。谦逊的态度和学习的愿望，不仅会帮助你成为一个更好的开发者，还会让你成为比特币社区的一股正面力量。
感谢 Aaron T casewll。
（完）