一直在纠结要不要就这个话题写点什么，之前梳理过一些思路，但感觉这个题目似乎没什么大意义。不过将东西憋在肚子里的滋味总是不好受的，最终我还是选择写出来一些，即便它真的没有什么意义^_^。

事情缘于近期领导让我负责的一个内部任务：制定组织内的代码行统计标准并实现标准化的工具。就是这个任务促使了我对代码行统计重新做了一番考量。

对代码行统计的理解

代码行统计这个活动不是软件开发过程中的关键路径活动，它对代码质量、开发进度以及软件价格几乎产生不了什么影响，应该算是个可有可无的东西。

就代码行统计这个活动本身而言，我个人的观点是没有代码行统计不表明不能开发出好软件；有了代码行统计，就一定能开发出高质量软件吗？

不过有一种观点认为：世界的本质是数据。通过数据我们可以发现事物运行的规律。代码行统计则是软件工程中对“数据”要求的产物。过程的好坏需要有数据支 撑，因此代码行统计这个活动成为了人们实现“用数据说话”的一柄利器。在“数据为王”的今天，我们无论如何都不能忽视数据的作用。人们通过数据来反映软件 开发过程中的一些规律性的东西本身也没有什么不妥。另外代码是软件开发过程的最重要成果物，因此围绕着代码的性态，我们用工具做诸多分析，期望从得到的数 据中找寻出一些可以指导和改善我们后续工作的蛛丝马迹。代码行统计提供的多是基础数据，在与其他过程基础数据结合分析后，我们能得到更多的信息。

合理地使用场合

个人觉得下面几个场合对代码行统计的需求是合理的：

* 统计代码总规模
   某个项目、某个模块或又某个版本的代码总规模。

* 代码“成分”统计
   统计空行、注释、代码的行数及占比、重复代码行数及占比等。

* 版本间代码变更差异统计
   两个有关联版本的数据对比统计，获取版本间的有效变更数据情况并作为基础数据提供给后续分析。

一些过程质量指标，诸如千行代码缺陷率等均是以上面这些代码行统计输出的基础数据为基础的。

“误用”

有合理的使用，就有“不合理”的使用 – “误用”。之所以加上引号，是因为至今人们对此见仁见智，尚无定论。以下列举两典型的“误用”。

* 通过代码行统计评估进度

有些组织在项目开始初期，就对成果的规模做了估计，比如10w行代码。然后在过程中使用代码统计工具对项目当前已实现的规模进行统计，并用统计出的数据与 初值的比值作为项目进度的评估参考。个人认为这是种典型的误用。盖茨说过：“用代码行数来衡量编程的进度，就如同用航空器零件的重量来衡量航空飞机的制造 进度一样”。且不提初期的估值有多么的不准确，就代码的行数本身而言，也受到各种因素的影响，比如设计方案、实现者的功力以及编码习惯等。同一个功能，A 实现需要100行代码；换成B就需要10行。

* 通过代码行统计评估程序员绩效

在一些外包公司或外包项目里，尤其是日本人的外包项目里，通过编写代码行的多少来评估程序员绩效的作法是很有市场的。我不能完全否定这种方法的正确性，因 为在日本外包项目中变态的日本人对代码的审核极其严格，并且有着苛刻的编码标准和风格，因此一些胡乱堆砌代码或使用奇技淫巧的代码都会被驳回，因此所有项 目开发者的效率似乎被约束到了一个平均线上。在这个前提下，产出的代码越多，似乎的确表明了这个开发者超出了平均效率，或至少牺牲了不少个人时间来完成项 目中的任务，精神可嘉，绩效被评高似乎也是合情合理的。但除此之外，用代码行多寡来评估程序员绩效显然是不受待见的。

考虑这个“误用”时，我也想模仿盖茨的话做个形象且深刻比喻，最初我写下的是这句话：“用代码行数多少来评估程序员的绩效，就好比用曲子的长短来评估音乐 家的水平，或又好比用画幅的大小来衡量画家的水准，或又好比用电影的时长 来掂量导演的功力！”。但仔细揣摩后发现这句话看起来挺像那么回事，但实际上却是不恰当的。什么是水准、水平或功力，这是衡量人的水平高低的；而绩效则是 一段时间范畴内工作成果的评估； 一个是长期的肯定，一个是阶段性的成绩。我显然是将水平和绩效(阶段性成绩)混为一谈了。高水平的开发者不一定每个周期都会取得高绩效，低水平的开发者也 不是无法取得高绩效的。因此这句话似乎应该改成：“用代码行数多少来评估程序员的绩效，就好比用这首曲子的长短来评估音乐家在这个阶段的水平，或又好比用 画幅的大小来衡量画家的这个阶段水准，或又 好比用电影的时长来掂量导演在这部电影上的功力！”。是不是读起来很别扭啊，反正我是这么觉得的。程序员的成果物是代码，代码好坏优劣对程序员绩效有着直 接影响（虽非充分必要条件），我们不妨替换一下本体来换种说法：“用代码行数多少来评估代码实现的好坏，就好比用曲子的长短来评估曲子的优劣，或又好比用 画幅的大小来衡量画作的高低，或又好比用电影的时长来掂量影片的良莠”！

对用代码行数多少来评估程序员绩效这种事情，我是很反感的，但在国内许多公司里，这种现象却又屡见不鲜。但这种行为背后的动机何在呢？传统工厂中，衡量一 个worker的绩效是相对容易量化，也比较客观的，比如制鞋厂可以用制成鞋子的数量来确定 worker绩效；在汽车组装车间，组装汽车的数量可以作为作为工人们的绩效；在炼钢厂，班组炼出的钢铁的吨数可作为班组成员绩效等等。将代码行数作为程 序员绩效的参考指标也许是一个无奈的方法。之所以想用代码行数，是因为程序员工作中能量化的东西不多，代码行数首当其冲。组织为了尽量减少绩效评定时主观 的成分，增加客观的评价，代码行统计从此被误用了。

代码行统计的高效使用

* 标准统一，工具一致

代码行统计工具有很多，因此执行这个活动时会出现不同人使用的代码行统计工具不一致的情况；并且不同工具对一些指标的定义也许有不同，这会导致收集到的数据存在含义不一致，精确度差的问题。因此高效使用代码行统计工具的一个前提就是（统计）标准统一，工具一致。

* 零干扰

一些传统的代码行统计方法是配置负责人收到统计任务时，将任务分发给各个模块的负责人，由各个模块负责人各自统计，然后反馈给配置负责人汇总。这种方式显 然不那么高效，而且容易引起一些对统计任务的反感情绪。高效的代码行统计最好能做到对开发人员“零干扰”。配置负责人可以通过“自动化”的静默方式收集代 码行数据。当然这需要对一些现成的开源工具做一些包装或二次开发才能做到，个人觉得这种投入是值得的，同时也能避免标准不一，工具不一致的情况。

本文翻译自Dr. Dobb’s杂志主编Andrew Binstock的"Advice to a new programmer"一文。

总是有太多的建议摆在新手程序员面前，以致他们难于选择从何处开始。然而，所有这些建议都是建构在下面这五条实践的基础之上的。

每隔几个月，我就会收到一些勤奋有加的新手程序员的求助，他们希望知道如何才能成为一名真正优秀的程序员。在一些程序员论坛上，我也能看到为数不 少的类似问题，这是一个令人鼓舞的趋势。一些最周全的答案往往与我对这个问题的看法相似，这表明在基础的最佳实践上确实存在着某种一致。因此我下 面的建议并非原创，不过也许我的这些补充会提供给你更进一步的理解。

我印象中的新手程序员基本了解编程的原理，写过程序，但大多规模较小且复杂度不一，致力于某个领域的工作或自己或他人个人项目。

编程工作只有一种真正的基础活动，那就是写代码。要想擅于编程，你就必须编写大量的代码。 大量的工作可能成为一种促进你成长的工具，也可能是一些有限技能的重复练习。为了避免成为后者，你应该做到：

阅读大量代码。尤其是阅读大量由卓越程序员编写的代码。记住：不仅读那些坐在大厅里的优秀程序员的代码，更要读那些卓越程序员的。 在开源软件大行其道的今天，做到这些十分容易。当我学习Java时，我读了Tomcat的代码，读了Cruise Control CI服务器的代码。自从那时起，我已经读了大量优秀的代码。

阅读代码时很容易从main函数开始，但这样一来，你很可能会在初始化以及命令行解析代码上花费大量时间。我更喜欢根据源文件名寻找一些令我感兴 趣的功能实现，然后深入阅读这些源文件。理解整个项目或整体设计的来龙去脉并不是关键，做这些会让你感觉筋疲力尽的。阅读代码。查看注释，弄清楚 作者在做什么以及是如何着手做的。

彻底了解你的工具。我认为损耗编程时间最多的不是调试或重写代码，而是因开发人员对其所使用工具的不熟悉而导致的无数碎片时间的损 耗。我所指的工具包括：集成开发环境（IDE）、编程语言、构建系统以及版本控制系统。其中，集成开发环境和编程语言是到目前为止最为重要的。经 过几个星期的练习，你应该知道集成开发环境中的几乎每个按键组合，这样你只有在为了节省按键时间时才使用鼠标。如果你知道按键组合，你就知道了这 些命令。但如果你只使用鼠标，你只会知道菜单，菜单上面有你倾向于点击的相同的一个或两个条目。因此了解集成开发环境是一种不折不扣的纪律。

了解大型编程语言，诸如Java或C++，需要的不仅仅是纪律。它们自身规模庞大，它们的库亦规模庞大。阅读代码是我认为的了解编程语言最好的方式，阅读 那些使用了你所未知特性的代码并寻找机会使用它们。书籍（而不是博客）是另外一个极好的资料来源。了解你目前正在使用的特性的外围，很快你就会发现外围扩 大了。了解版本控制系统和构建系统将让你成为一个理想的团队成员 — 不会因为对重要操作的无知而浪费时间。

动手编码前先规划好你的代码。我认为这是建议列表中最难做的一项，但同时它也可能给你换来最多的益处。我所指的并不是正式的设计 – 在这个阶段正式设计一般不是必要的。不过你确实应该用一种其他方式精心策划一下代码，而不仅仅是将思路放在脑子里。最简单的方法就是编写一个小文档（我经 常使用的是思维导图）：代码的需求是什么？你打算如何实现它？还有哪些目前未知的事情需要去了解？我需要或需要创建什么对象？将这些都写出来。只有在这样 之后开始编码，你才会发现代码变得更加容易编写了，更容易形成文档了，也更容易修改了。将你的笔记保存下来 – 它们将是很好的参考资料。

大量编写代码并进行代码评审。如果你那里不做代码评审，那你就自己来做。找出那些最好的程序员，并且你可以通过某种方式听 到和理解他们给你的有用的建议。别做令人讨厌的人，但也不能因为你害羞，忙碌或自负而回避这个过程。代码评审应该成为你编程人生的一部分。要有创造性。试 试在某个下午与比你更牛的程序员一起做结对编程。重要的是你需要反馈，而这些反馈是你自己无法给予自己的。

编码与写测试并驾齐驱。这也许是这里唯一有争议的一条。它并非是对TDD的认可(译注：测试驱动开发)。但这里要认可的是你的代码 在大多数要面对的场合里都是可以工作的。开始单元测试，并用边缘值测试新代码。例如，当传入一个负数或者是整型数最大值时，你的函数是否还能正常工作？如 果不能，你的函数是否抛出了一个信息详实的异常或只是崩溃退出？如果不是异常，你是否使用了断言(assert)来缩小输入的范围？如果这么做了，那就测 试这个断言。利用之前做的规划编写一些模拟(mock)测试，接下来用这些模拟对象去开始测试你的新代码。这将有助于阐明你当前代码中的设计问题以及即将 实现的对象。保存你的测试代码，在每次签入代码前都运行它们，这些测试将成为后续那些破坏你当前代码的新代码的早期预警系统。

还有许多建议和至理名言可以添加到这个列表中。但这本身就是问题的一部分：过多的建议将导致新手难于知道到底从何处开始。因此，我故意将我的建议缩减到仅 剩五点。如果你能勤奋地运用这五点建议实践，你会很快发现两件事情：你将可以逐步应付更大更重要的任务了，并且当你回首翻看你几个月之前编写的代码时，你 会觉得尴尬。

毫无疑问这两种感受都是你进步的标志。祝你好运！