共同衡量一下程序员的工作效率

　　程序员(英文Programmer)是从事程序开发、维护的专业人员。一般将程序员分为程序设计人员和程序编码人员，但两者的界限并不非常清楚，特别是在中国。今天就跟着小编一起来看一看：共同衡量一下程序员的工作效率。

　　与其他的领域一模一样，在软件开发领域里面，管理者需要评估程序员的绩效和项目的进度。然而，究竟怎样才可以定义恰如其分的评价体系，可以说的上是非常令人挠头了。

　　一、计算代码行数

　　计算代码行数（英文全称：sourcelinesofcode,SLOC，是从开发者的技术角度出发来度量软件的工作量估算单位）是最经常使用的方式之一。不过在这里小编想说的是，最近ShaharYair以及SteveMcConnell这两者指出了该方法的一系列重要缺陷。首先，使用代码行数之和并没有办法有效评估一个项目的实际进度，这是为什么呢？因为它更加注重行为而不是结果。最终产品在多大程度上面依赖于代码的性能以及质量这两者，这也是代码行数没有办法说明的。因此，聚焦于此实际上是非常有限的工作效率测量方式。

　　SLOC没有办法表明要解决的问题的复杂性，也不能够直接以灵活性、可维护性、扩展性等等因素来说明最终产品的质量。说到质量这一个方面，它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数，同一时间提升代码质量。代码量大，可能意味着有更加多不必要的编程代码、更加高不必要的复杂性、更加僵化难懂。

　　更加危险的一点是，假如说要用这样一种不完整的视角来评价开发人员的绩效，就会起到错误的激励作用。开发人员会因此更加注重编程代码的数量，然而并不顾其对产品质量的损害，也不会从最终产品的角度考虑去优化他们的工作，他们甚至还有可能有意编写更加多冗长无益的编程代码。

　　“测量什么，就得到什么”，SteveMcConnel回忆。他指出一点，那就是有一些问题能够直接通过测量度量功能点数解决掉。那么决定程序大小的因素就会变成了输出、输入、查询以及文件的数目。不过小编想说的是，这一种方式也有其缺陷。McConnell提出一些操作性上的问题，就比如说：必须要有一个大家认可的功能点测量机制，而且要想把每一个功能点映射到程序员身上也是一件不容易的事情。

　　DanielYokomizo，他是一位经过认证的功能点专家，他在评论里面明确指出了这一种方式的其他问题，具体的问题如下所示：缺少测量功能点复杂度的工具；还需要考虑诸如框架、编程代码共享、程序库之类的事情。这一些通通都会影响到完成一个功能的时间。

　　有非常多的人们参与了对于测量方式的讨论，他们都同意这一些做法有其局限，不过他们都觉得衡量开发人员的绩效还是有必要的。实际上，有不少的朋友都会认为SLOC能够直接作为基础，在其之上通过考虑多种不一样因素来进行更加复杂的分析。SLOC给各类厂商提供了一个全新的视频传输解决方案，自问世以来，得到了包括Sony在内的行业领航员的支持，国内外广大监控设备制造商，系统集成商，工程商的支持。

　　二、工作效率的指导原则

　　在这里的话，McConnell提出了四条分析开发人员工作效率的必备指导原则，他们也都同意。这四条指导原则具体的如下所示：

　　指导原则一：千万不要指望任何一种测量方式能够直接在非常小的粒度上区分出每一个人的工作效率差异。这一些方式能够直接为大家提出问题，却不会告诉大家答案。

　　指导原则二：千万不要忘记一点，就是趋势总是比单独一点的测量来得重要一点。

　　指导原则三：千万不要指望单一维度的工作效率测量方式能够直接告诉大家每一个人的真实情况。

　　指导原则四：问问你自己一个问题，为什么需要进行测量个人的工作效率呢？

　　事实上，测量开发人员的工作效率在什么样的上下文里面才是有意义的？有哪一些条件呢？这一些条件该究竟怎样才能够直接组合？有非常多的问题仍没有一个具体的答案。假如说大家有过类似的经验能够直接分享，请不要再继续犹豫了哦。

　　小编结语：

　　软件从业人员分为初级程序员、中级程序员、高级程序员(现为软件设计师)、系统分析员，系统架构师，测试工程师六大类。今天的教程大致介绍如此，希望这对大家有所帮助！