一个程序员能够控制多少行代码



我觉得大家初看到这个题目时，一定会很奇怪，一个程序员能够控制多少行代码完全取决于该程序员的能力强弱，这有什么规律可循么？其实当这个想法突然冒出来时，我也都有些诧异。

首先介绍一下我遇到的情况，我当时正在编写一个小程序，是模拟cache工作原理的。这个程序中有一个函数集的实现文件（function.cpp），大概由20个左右的函数组成，由main.cpp中的main函数直接去调用它们。这个文件我是从头开始一点一点码起来的，开始时都很顺利，编写代码的速度也很平稳。但是当我的代码达到600行时，我突然发现我的编码效率出现了严重的下滑，我开始不断回顾我已经编写的代码的作用才能继续下面的内容。

不过后来我发现如果我能够将这个function.cpp文件分成两个文件function1.cpp/function2.cpp，其中function1.cpp实现一些基础函数功能，funtion2.cpp中的函数调用funciton2.cpp中的基础函数来实现一些更为复杂的功能。这时我突然发现我的编码效率又回到了正常状态，不用总是回顾之前的内容，也能够继续下去。这时我想到，在我过去的一些编码实践中经常会遇到类似的情况，只是我一直没有把它当一回事。我感觉一个程序员在它的程序的每个层次所能掌控的代码行数是近于固定的，一旦编写的代码超过这个数值，我们的代码编写效率就会急速下降。不得不将目前的代码进行划分层次，以继续完成剩下的功能。

可能你觉得上面我说的东西丝毫没有逻辑性，不知我到底要表达些什么。不过我觉得这件事情确实不太容易说清楚。为了继续说明这个问题，我先假定几个概念。一个是“控制”，一个是“代码行数”。首先说明一下这里的“代码行数”的具体所指，比如你在主函数中写出：

printf(“Hello World!\n”);

这当然算一行代码，这没有什么疑问，在我们心中这行代码和：i=i+1一样的简单，虽然前者其实调用了一个库函数，而后者则没有。但是如果库函数中没有这个printf()函数，而要我们自己实现它的功能，因此编写了一个myprintf()函数，并且假设实现该功能需要10行代码，那么我们一共写了10+1=11行代码，可是一旦我们完成了这个函数功能，我们就不需要对其持续关注。因为它和我们的主函数不在一个层次上。所以我们现在虽然写了11行代码，却并不需要真正掌控11行代码就可以继续下去。但是我们有感觉，如果我们对于这个我们myprintf()函数不是很熟悉的话，每次看到这行：myprintf(“Hello World!\n”);时又要停下来想想它的作用，当我们经常使用它时，再看到这行代码，我们不会有任何思维上的停顿。所以我们假定这行代码中，我们实际需要掌控的代码行数为L1+α*L2，L1代表我们的主函数层次的代码行数。α代表我们的熟悉程度，L2代表我们实现myprintf()这个函数的所需代码(也就是说第二层次我们需要掌控代码行数)。在本文中为了简化，我们假定α=0.5，所以我们在主函数层次上真正需要掌控的代码数为1+10*0.5=6行。

现在我们谈谈什么叫做“控制”，我暂时把它定义为：如果我们所编写的代码行数在我们能控制的最大代码行数范围内，我们在编码过程中应该是舒适的。什么叫做舒适呢？就是我们能够按照我们日常的编码速度和编码质量进行编码。这里所说的编码速度和编码质量因程序员的个人能力差异而不同，但是对于一个固定的程序员来讲基本是稳定的。如果你对这种定义持有怀疑态度的话，我在用另一种形象的表述“控制”，如果你闭上眼，能够很快的回忆起你的工程中某个层次的所有代码的作用，那么你就可以说你掌控了该层次的所有代码。

好了，谈了这么多，我们探讨这个问题的目的是什么呢？

假设一个程序员通过以往的实践，发现自己所能掌控的工程中某一层次的代码数目为500行，当然开始某个新的工程时，发现他在主函数层次上已经写了将近500行代码。这是他应该警觉到：我已经快要到达我所能掌控的代码行数的极限了，如果继续在该层次上编写，势必会造成效率的严重下滑。这可能影响到总的工程进度。同时他发现这个主函数中的200行代码其实完全可以用下一个层次的一个函数来解决。于是他在下一个层次编写了一个200行的函数（比如function1），并把原来主函数中的200行代码删除。这是他实际需要掌控的代码数量为：300+0.5*200=400。这时它可以继续以一个舒适的编码状态在主函数编码。但是没过多久，他发现他在主函数层次上需要掌控的代码行数又要到达500行的极限了，这是它有发现原来主函数中的300行代码可以用一个下层次的函数解决，于是他在下一层次编写了一个300行的函数（比如function2）。这是他实际需要掌控的编码数目为：200+0.5*（200+300）=450。所以他可以继续在主函数层次编程。但这个过程不断继续，他总会到达这样一个时刻，主函数层次的代码已经足够精简，无法通过利用下一层次的函数来减少主函数层次的代码行数，但是他需要掌控的代码行数又已经达到了500行，整个工程需要的功能却还么有完全实现。这时该怎么办？

很容易想到，它可以将第二层次的函数进行精简，也就是说用第三层次的代码去实现第二层次函数的功能。这样可以进一步减少他所需要掌控的代码行数，使其一直保持在500行以内。其实这种理念和结构化程序设计理念有一些相同之处。只不过我们所说的结构化程序设计一般发生在工程的设计阶段。但是真正在实践编码过程中。我们的代码量经常会超出预期。这时我们需要不断动态的根据代码数量划分层次。

但是不是说我们可以这样一直划分层次来维持我们需要控制的代码数量低于我们最大能力呢？你也许会发现，当层次越划越细，越划越深时，我们的编码效率又开始下降了。这是什么原因呢？我们再回到之前提到的简单式子，我们在主层次需要掌控的代码数量为：

L1+α2*L2+α2*α3*L3…

当层次越划越深时，我们会发现我们对于某个层次的代码的熟悉度下降了，也就是说α1，α2，α3…增大了，所以上式的数值也就增大了。但这时我们的工程任务还没有完成，有些功能还没有实现，那我们该怎么办？

其实这也是实际中一个经常遇到的问题，你会发现在某个时间段你的编码效率陡然下降，你不能再通过划分层次来加快编码效率了。这时你有几条路可以选择。

其中一条路是，你要忍耐这种编码效率下降的事实，继续在已有的层次上编写代码。这样有一个好处，就是你可能会通过训练提过你所能控制的某一层次的最大代码行数。也就是说一旦你可以从500行提高到1000行，那么你以后编程时可以在更少的层次中实现比原来更多的功能。

另外一条路是你可以查找你已经编写的代码，寻找其中可以优化的地方，以用更少的代码实现原来的功能，这样做的好处是你可以发现有许多算法可以用很少的代码实现。久而久之你可以编写出比以往更加简化的程序。但缺点是你在某一层次上所能控制的最大代码行数仍是500行。

你会发现，无论那条路都必须要求你提高自己的能力，假如说划分层次来完成工程是一种取巧的办法，那么当这种取巧的办法达到它所能达到的极限是，你就不能再取巧了。你需要提升你的硬实力，而这种硬实力是需要你不断的摸索得到的……