改进BU代码质量的一个建议

ejv03823tjp

原帖地址：https://www.reddit.com/r/btc/comments/60wyr9/a_proposal_to_improve_bitcoin_unlimiteds_code/?st=J0LNZVUL&sh=62e84662

翻译中文如下：

改进BU代码质量的一个建议

继承了Core代码的比特币是一团糟。当我看到最新的主张在第5706行失败时，我想到的第一件事是：“哦天呐，一个文件不应该有6000行那么长。”这是一种由纪律不足的程序员引发的难以理解的混乱迹象。

代码中单单是ProcessMessage的函数已经超过1300行，而且还有大量的数百行代码的函数。这种状态下的代码读起来令人不愉快，也很难去发现其中的错误。

我们需要的是一个适当的代码审查程序，但在当前状态下代码甚至都不适合于代码审查，因为你不能为了找出他是否有问题，看其中的一部分代码然后了解你想要了解的所有东西。

唯一有机会发现问题的人是那些已经亲密的熟知代码的人——也就是编写代码的人，而新人由于代码的复杂性则看不懂那些代码。

同时，在目前的状态下这些代码也无法进行测试，你不能仅仅测试1000行的功能。有很多发生的事情可以建立一个情况——称作函数，来检查结果然后汇报一切都好。

目前测试比特币的方法（使用Python脚本来运行和控制可执行文件）是不专业的，也是完全不够的。这就像是在全部造好一辆汽车后再驾驶着它来测试它。是的，你必须测试它，但是你应该在安装每个组件之前测试它以确保它符合规格。

对于比特币而言，这意味着不仅要用C++编写函数，也要用C++编写对这些函数的测试语句。测试每个函数，而不仅仅是可执行文件。

这也意味着将这成百上千行函数分成许多小函数，每个函数只负责一两件事情。这些小函数可以被测试，更重要的是，他们很容易被读取。如果一个函数不适合出现在屏幕上，那么你就不能看到它。你只能看到它的一部分，并且试图记住其余的部分。

如果你能很快看到到整个函数并且理解她的每个细节，那么即使一个错误都逃不过你的眼睛。

有些人非常聪明，他们头脑里能记住很多代码，甚至一些不适合在屏幕上显示的。他们可以搞定一百多行的函数并且察觉到它的瑕疵。他们可以写出几百行没有任何错误的代码。

那些人是“奇才”，他们可以写出令人难以置信的复杂混乱的代码，那些代码正常人都无法进行审查。他们不可能被解雇因为没人能理解他们的代码。随着时间的推移，那些代码变得越来越复杂，最后甚至超出了那些“奇才”自己的理解能力。最后整个项目变成了不可维护的一团糟。

我们不希望那种情况发生，我们需要普通程序员都可以阅读的代码，我们不想用复杂的代码吓唬人。我们需要能够一直重构成更小、更简单、易于测试函数的代码。

我们不想成为一个小小的奇才专属俱乐部。

所以我的观点是：停止试图通过对Core的代码添加更多改变来管理BU。

Core正是在编写奇怪的代码。巨大的文件包含着巨大的功能这对于一个新手来说，很难做到完全理解。危险的是，那些工作中有着智慧的想法迹象的人，却碍于软件工程资源的匮乏，使得他们在不断增加复杂性地道路上越走越远。

我建议BU停止这一切。结束这些函数直到每一个都适宜出现在屏幕上并且理想的来说只有几行；结束这些文件直到每个文件都很容易完全理解；使代码变得易于阅读；使变量名变得易于理解。Robert Martin写的一本书Clean Code很不错，它为像这样的工作提供了很好的动机和技能。Core的代码不整洁，它需要被清扫干净。

只有用那种方法才能使得那些不是奇才的人都可以审查那些代码。

这样做的代价就是，Core团队代码的新的改变不能轻易被复制下来。如果Core做出一些新的改变而BU不想执行它，那么就必须要重新在再执行。这样看起来有了更多的工作量，但我认为从长远来看这样是更好的。

有些人对现在BU代码的质量表示怀疑，解答这些疑惑的方法就是用明确表达的以及彻底改进质量的代码来提高项目的质量。

对于干净、简单、易于读懂的代码以及有着便于理解的变量名和最好只做一件事的简短的函数，我将很自愿的去审查代码，我也希望其他人可以加入我。

这需要随着时间的推移逐渐远离Core的代码库，并且给那些普通但是勤奋的编码人员足够的空间，他们不需要也不应该成为奇才。

coin-master回复：

Classic 开发者没有开始这个过程吗？也许这两个客户之间会有某种协同作用。

Annapurna317 回复：

我觉得他们是在尝试缩短程序代码的长度。

don_savage 回复：

从某种意思上来讲，这和把它解体类似，对不对？

Annapurna317 回复：

使它面向对象。

don_savage 回复：

是的，和我想的一样。减少有关程序的很可能意味着过渡到一个面向对象的设计，这将意味着更多，比如更短的文件和方法。

Annapurna317 回复：

封装代码，更容易进行读或者理解。逻辑结构等……

don_savage 回复：

确实如此。

ydtm 回复：

我们的长期目标应该是使用正式的程序验证Bitcoin的实现

从长远来看，如果我们想让比特币成为一个数万亿美元的经济体，那么最终将必须开始使用程序合成和验证的正式方法，如下面网站所说的：

https://github.com/johnyf/tool_lists/blob/master/verification_synthesis.md

当然，这种东西是很难被写在一个命令或程序语言（如C++）中，因为程序语言是比陈述或功能性语言更复杂的语义程序。

从长远来看，从底层设计的语言支持正式化程序的合成和验证，从这个角度来思考Bitcoin的实现也是非常有趣的。

例如，理想的情况是，我们的长期目标应该是使用定理证明语言（如COQ）来表达定义比特币，然后在多功能但高效的OCaml中提取执行情况（具有性能相当接近C / C++，但语义比C / C++更容易验证）-然后可能使用MirageOS部署整件事（unikernel）。（当然，如果需要的话，一些性能关键的部分仍然需要在C++中实现和验证，使用OCaml国外功能接口（优秀、一元）进行连接）

或者（如果希望避免使用OCaml这样较少程序员熟悉的语言），也可以在C++也建立另一个执行，这个执行比Core/Blockstream的模块更多，然后使用上面列出的链接中的一些C++程序验证工具。（我怀疑基于线性时态逻辑（LTL）则可能是最有前途的。）

这种努力可能是基于实现libbitcoin，btcd / btcsuite，bcoin…这已经比Core的复杂庞大的套管程序更加模块化的多。

SegWit-as-a-soft-fork 的黑客“任何人只要花钱就可以”是Core/Blockstream的扭曲不必要优先级以引入全新的威胁向量类的一个例子

特别需要注意的是，我们应该关注SegWit，它本应该是一个主要的清理代码（重构），但最终由于Core/Blockstream不正当的坚持把SegWit当作软叉，使得SegWit变得套管化，这导致代码中各种不必要的回旋，特别是臭名昭著的“任何人只要花钱就可以”黑客不幸被用来实现SegWit（同样不幸的还有被用来实现Pay-to-Script-Hash（P2SH））。

黑客“任何人只要花钱就可以”是很危险的，它给比特币的代码库引进了一种全新的威胁向量类-因为如果交易是“任何人只要花钱就可以”时，那么与之前相比，当一个51%的攻击只能花费掉你自己的双倍硬币，或我的额外硬币时，这51%的攻击就可以视为在偷别人的钱。

Core/Blockstream想利用对他们来说完全不必要的“任何人都可以花钱”黑客（如果SegWit做得好，那么“任何人都可以花钱”黑客就完全是非必要的），向比特币代码库中引入的危险的新威胁向量类，只不过是一个显示Core/Blockstream扭曲优先级（他们报告给中央银行，而不是我们的用户）对比特币多么有害的最新“红旗”而已。

实际上，Core/Blockstream是为中央银行家们工作的，而不是为了我们，这也解释了为什么他们的代码并不能解决我们优先权（收费低，可靠的交易）。

Core/Blockstream强调的所有都是关于视觉、优先级和技能的，Core/Blockstream已经表明他们是隧道视野（忽略可用性等重大问题），扭曲优先权（他们想强迫人们断链，而削弱在链能力是他们邪恶路线图的一部分）和平庸的编码技能（8年的代码“维护”，是代码演变成套管程序）。

同时，对于R Bitcoin的信息缺乏失败者，往往会自动把Core/Blockstream开发者称为“奇才”。

然而，在程序员的圈子里，Core/Blockstream开发者其实相当平庸，可以从几个层次上说明：

Ÿ 他们关于写什么（规范）的想法和优先次序远未达到最佳。规范显然应该与实际用户需要相匹配。我们知道，他们已经在这一领域惨败-因为他们实际的“用户”是赞助Blockstream的中央银行家，而不是一般的比特币群体。

Ÿ 他们的编写方法（它们的执行情况）同样不是集中在诸如使代码模块化，易于理解，易于测试上面。另外，他们坚持只通过软叉升级，而不是硬叉。这两个动作都减少了比特币的代码质量和代码安全，但是提高了Blockstream开发者的工作保障。

ericpashman 回复：

最完整的比特币是在一个复杂的类型系统的语言-Haskoin中实现的，用户从Haskell的底层开始写程序。在所有的语言中，Haskell能提供比普通正确性更强大的担保，Haskell是迄今为止最大的程序员社区，它的库和工具具有最佳可用性（这些功能都很普遍，并且与比特币及密码是相关的），看来实现Satoshi代码库的高可靠性电子商务客户独立，Haskoin语言是显而易见的选择。

IOHK也做了不少Ethereum开发工作，包括研究正式验证工具，所以在比特币以外的系统Haskell中，已经有一些相关的工作在进行了。

Granautismo 回复：

货币的未来是意大利面吗。我真的希望很快得到重构代码。我很想帮忙，但我不懂C++。