程序猿工作的衡量有太多争议，也有太多方法，在我看来，可以有几个共同的实践：

（1）新增需求带来的代码行数

新增需求的代码行数代表一个人的工作量，在项目初期，这个指标比重可以很高。但长期肯定不能作为唯一的指标，举个栗子来说，如果一个业务存在一段时间，后来新入职的员工接手时，新增需求很少，故障单数却很多，这时就不能说这个员工的贡献是负的。

（2）故障单数&故障带来的代码行数

这个最直接反应代码的质量，但程序员都知道，一段代码甚至一个模块写完之后，不是说立刻就能被充分测试，可能有很多问题在许久之后才会爆发。我认为要解决这个问题，需要单元测试和模块文档的辅助。

（3）重构&优化带来的代码行数

这个最直接反应程序员的“工匠精神”。重构&优化的目的有：降低代码复杂度，提高性能，提高可读性，提高软件的友好度，且一定不能引入故障。

（4）代码复杂度&单元测试

这个最直接反应代码的质量。我认为这是个人级别以上能控制代码的最低但最有效姿态了。

（5）有效文档的书写

这个保证了业务的可持续稳定。我认为这个很重要。

1）项目前的编写。

2）项目后的模块和业务总结。

3）各版本的业务变化总结。

（6）团队合作&团队氛围

团队可以通过降低特定函数复杂度、小团队的技术培训、定期的秘密互评、聚餐、游戏等活动，营造技术氛围，同时也能提高大家的工作积极性。