衡量程序员的工作效率
读书人IT频道reader8.com/exam/jisuanji/ 与其他领域一样，在软件开发领域中，管理者需要评估程序员的绩效和项目的进度。然而，如何定义恰如其分的评价体系，很令人挠头。 计算代码行数（source lines of code, SLOC）是最
读书人IT频道reader8.com/exam/jisuanji/ 与其他领域一样，在软件开发领域中，管理者需要评估程序员的绩效和项目的进度。然而，如何定义恰如其分的评价体系，很令人挠头。
计算代码行数（source lines of code, SLOC）是最常用的方式之一。不过，最近Shahar Yair和Steve McConnell指出了该方法的一系列重要缺陷。首先，使用代码行数之和无法有效评估一个项目的实际进度，因为它更注重行为而不是结果。最终产品在多大程度上依赖于代码的性能和质量，这也是代码行数无法说明的。因此，聚焦于此实际上是非常有限的工作效率测量方式。
SLOC无法表明要解决的问题的复杂性，也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。说到质量，它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数，同时提升代码质量。代码量大，可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。
更危险的是，要用这样一种不完整的视角来评价开发人员的绩效，会起到错误的激励作用。开发人员会因此更注重代码的数量，而不顾其对产品质量的损害，也不会从最终产品的角度考虑去优化他们的工作，他们甚至可能有意编写更多冗长无益的代码。“测量什么，就得到什么”，Steve McConnel回忆。
他指出，有些问题可以通过测量度量功能点数解决掉。那么决定程序大小的因素就变成了输入、输出、查询和文件的数目。不过这种方式也有其缺陷。McConnell提出一些操作性上的问题，比如必须要有一个大家认可的功能点测量机制，而且要想把每个功能点映射到程序员身上也不容易。Daniel Yokomizo是一位经过认证的功能点专家，他在评论中明确指出了这种方式的其他问题：缺少测量功能点复杂度的工具；还需要考虑诸如代码共享、框架、程序库之类的事情。这些都会影响到完成一个功能的时间。 读书人IT频道reader8.com/exam/jisuanji/
