与其他领域一样，在软件开发领域中，管理者需要评估程序员的绩效和项目的进度。然而，如何定义恰如其分的评价体系，很令人挠头。
　　计算代码行数（source lines of code, SLOC）是最常用的方式之一。不过，最近Shahar Yair和Steve McConnell指出了该方法的一系列重要缺陷。首先，使用代码行数之和无法有效评估一个项目的实际进度，因为它更注重行为而不是结果。最终产品在多大程度上依赖于代码的性能和质量，这也是代码行数无法说明的。因此，聚焦于此实际上是非常有限的工作效率测量方式。
　　SLOC无法表明要解决的问题的复杂性，也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。说到质量，它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数，同时提升代码质量。代码量大，可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。
　　更危险的是，要用这样一种不完整的视角来评价开发人员的绩效，会起到错误的激励作用。开发人员会因此更注重代码的数量，而不顾其对产品质量的损害，也不会从最终产品的角度考虑去优化他们的工作，他们甚至可能有意编写更多冗长无益的代码。“测量什么，就得到什么”，Steve McConnel回忆。
　　他指出，有些问题可以通过测量度量功能点数解决掉。那么决定程序大小的因素就变成了输入、输出、查询和文件的数目。不过这种方式也有其缺陷。McConnell提出一些操作性上的问题，比如必须要有一个大家认可的功能点测量机制，而且要想把每个功能点映射到程序员身上也不容易。Daniel Yokomizo是一位经过认证的功能点专家，他在评论中明确指出了这种方式的其他问题：缺少测量功能点复杂度的工具；还需要考虑诸如代码共享、框架、程序库之类的事情。这些都会影响到完成一个功能的时间。本文来源:考试大网
　　有很多人参与了对于测量方式的讨论，他们都同意这些做法有其局限，不过他们都觉得衡量开发人员的绩效还是有必要的。实际上，不少人认为SLOC可以作为基础，在其之上通过考虑多种不同因素来进行更复杂的分析。McConnell提出了四条分析开发人员工作效率的必备指导原则，他们也都同意。这四条原则如下：
　　1、不要指望单一维度的工作效率测量方式能告诉你每个人的真实情况。
　　2、不要指望任何测量方式可以在很小的粒度上区分出每个人的工作效率差异。这些方式可以为你提出问题，却不会告诉你答案。
　　3、牢记：趋势总是比单独一点的测量来得重要。
　　4、问问你自己：为什么要测量个人的工作效率？
　　测量开发人员的工作效率在什么样的上下文中才是有意义的？有哪些条件？这些条件该如何组合？许多问题仍没有答案。如果你有过类似经验可以分享，请不要犹豫。

　　编辑特别推荐:

　　十个糟糕的程序员的行为