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

(1)新增需求带来的代码行数

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

(2)故障单数&故障带来的代码行数

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

(3)重构&优化带来的代码行数

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

(4)代码复杂度&单元测试

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

(5)有效文档的书写

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

         1)项目前的编写。

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

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

(6)团队合作&团队氛围

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

发布评论

分享到:

IT虾米网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

项目微管理14 - 预热详解
你是第一个吃螃蟹的人
发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。