宠文网

奔跑吧,程序员

宠文网 > 科普学习 > 奔跑吧,程序员

7.4小结

书籍名:《奔跑吧,程序员》    作者:叶夫根尼.布里克曼
    《奔跑吧,程序员》章节:7.4小结,宠文网网友提供全文无弹窗免费在线阅读。!



从某种程度上看,编程就像力量训练。力量训练的初学者会发现他们所做的几乎一切训练都将产生某些结果。你走进一个健身房,做几个二头弯举,你的手臂就会开始变粗;每天跑上几公里,你的腰围就会变细。这种效果只会持续到某一个时刻。之后的一段时间,也许是一年,你就会遇到瓶颈,所有的过程似乎都停止了。你不断举重,但是并没有变得更强壮;你不断奔跑,也没有变得更瘦。此时继续前进的唯一方式就是开始使用更高级的训练计划,你要懂得调整哑铃的重量,需要吃更多的蛋白质,需要更多的睡眠,你要懂得某些练习比其他的练习更有效果。突破瓶颈的唯一方式就是从根本上改变你的训练。

其实编程也是一样的。

我的朋友Clift  Norris找到了一个基本的常数,我称之为Norris常数,表示未经训练的程序员在他(或者她)遇到瓶颈之前所能编写的平均代码量。Clift估计这个数是1500行。如果代码超过这个数,就会十分混乱,作者也无法轻松地调试或修改。

——John  D.  Cook,The  Endeavour

就像在举重一样,你几乎可以在编程领域做任何事情——复制与粘贴、使用全局变量、不编写测试和文档——也能够工作。不用多长时间,最终,你就会遇到天花板。如果想要突破它,也一样需要更高级的方法,即要遵循本书所描述的整洁的编码原则和实践。遇到天花板的时间也不会太长:仅仅生成一个全新的Ruby  on  Rails应用的框架就有大约900行代码,已经超过了Norris常数的一半。

事实上,这样的瓶颈不仅只有这一处。Norris之数代表了编写一两千行代码就会遇到的问题。为了克服这些问题,我们必须开始考虑上一章所提到的一些编写整洁代码的原则,比如更好地命名、代码布局、松耦合和高内聚。等到了大概2万行代码的时候,我们又会遇到另一个瓶颈。

我在毕业后的第一份工作中,就重复地遇到了2万行代码的瓶颈,我的同事也遇到同样的情况(跟我一样年轻)。在DreamWorks,我们有950个程序供动画师使用,代码计数器表明大一点的程序大概在2万到2.5万行代码左右。如果超过这一数字,就很难轻易地添加新的特性。

——Lawrence  Kesteloot,Team  Ten

为了克服这一瓶颈,我们就必须在编码实践上多想想办法,可能要多花些时间进行代码评审、自动化测试、重构、将代码分解成更小的函数和模块、控制代码的副作用。这么做将使我们走得更远,直至达到几十万或几百万行代码才会遇到新的瓶颈。

似乎在三四百万行代码的时候,就会遇到瓶颈。在达到300万行代码之后,不管多少人(数以百计)花多少年(数以十年计)参与进去,增长率似乎都会明显变慢。

许多产品的公司专有代码量大致都是以百万行计的,尽管其中也包含了大量的死代码。NVIDIA的核心驱动代码正好是300万行,尽管附属功能的代码要多出100万~1000万行。游戏厂商的代码似乎会少一点,在150万~200万的范围内,可能也是因为它们应用程序的数量更少一些。

——Daniel  Wexler,Wexworks创始人

对于拥有几十万或几百万行代码的代码库来说,需要的是完全不同的实践:独立的代码存储库、严格控制和向后兼容的API、大量的单元测试、全面完整的文档,等等。

所以,我们又要回到创业公司是与人密不可分这个事实上。我们对代码库的维护能力和我们所使用的技术并没有那么大的关系,更多是与人类大脑和心理的天生局限性有关。如果我们主要是自己编写2000行以下的临时程序,比如一开始创业时多半要做的抛弃型的原型,那么不用考虑太多可扩展的编码实践就可以开干了。但是如果要编写规模更大、有更多人参与、需要处理更多负载的东西,从根本上就是完全不同的做法。我们必须从一开始就关注所有可以帮助人们阅读和编写代码的事情,比如命名、代码布局、内聚、耦合、重构、测试、代码评审和文档。如果能这样做,就会前进得更快,速度制胜。

我们在Peak  Strategy的时候遇到过一个情况:我们让一位客户第二天来公司,他本应该是在第二天早9:00或9:30到的。他在一家期货及衍生品交易公司工作,他的公司具有非常高的交易速度,和我们以前处理的交易类型有很大不同。我们需要为他做些演示,因为我们的软件并不能完成这样的任务。我不记得确切的情况,但是不知怎的我们被逼到了墙角。

在那天下午早些时候,也就是在他本应该出现的时间之前,我们正兵分三路进行结对编程,实现第二天的demo所缺失的系统模块。那时我们都对纯粹的方法论充满渴望,所以我们约定将使用纯粹的测试驱动开发、结对编程和细致的重构,等等。我们从中午就一直工作到第二天早上7点。我们的工作效率实在是了不起,而且据我所知一点问题都没有。我想说的是,在那样的环境中出现错误是非常可怕的,让一个金融工程师在工具执行的计算中找出一个bug是极其可怕的。但是我们取得了难以置信的进展,却没有引入任何的bug,也在第二天有了一个完美无瑕的演示。

当你开始尝试在软件公司中引入过程方法的时候,总会听到这样的声音:“我只能在不赶时间的时候去使用好的方法。如果时间很赶,我就管不了那么多了”。我总喜欢把这个故事拿出来举例子,想告诉大家一个真正好的方法无论在什么尺度上都应该能够加快你的速度。一个好方法可以缩短你一小时、一天或一年的时间。

——Dean  Thompson,NOWAIT公司CTO