我认为大家初看到这个题目时，一定会非常奇怪，一个程序猿可以控制多少行代码全然取决于该程序猿的能力强弱，这有什么规律可循么？事实上当这个想法突然冒出来时，我也都有些诧异。

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

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

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

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行。

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

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

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

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

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

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

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

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

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

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

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