小团队的代码质量管理和团队管理

2023-02-26  本文已影响0人  关外老妖

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

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

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

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

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

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

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

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

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

(5)有效文档的书写

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

1)项目前的编写。

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

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

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

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

上一篇下一篇

猜你喜欢

热点阅读