axb的自我修养
23-06-18 21:56 微博认证:微博原创视频博主

回答技术问题系列。

关于代码质量,经过我这些年的实践,想把代码质量搞好大概有三个必要条件:

1. 有一个没有脱离一线开发的大领导(至少是技术总监这个级别),能够把代码质量和研发效率、研发效率和公司业务关联起来,为研发人员争取到必要的资源。
2. 有一个(群)技术过硬的技术组长,代码质量是能够深度参与过1-2个开源项目的水平,能够区分什么是好代码、什么是烂代码。
3. 有一群有自驱力的一线开发,至少读过2-3个开源项目的水平。

简单的说,公司要有钱,雇的人要有能力,给的钱要有驱动力。人到位的情况下,你说的问题都不是问题。

但是能符合这种理想情况的团队少之又少,大部分都是大领导脱离一线不给资源、组长只会合并周报唯唯诺诺、一线开发摸鱼混吃等死。

在这种情况下我能给出几个极为有限的建议,并且要提醒你,抓代码质量需要有人事奖惩权,并且会极大的消耗技术组长的精力。我自认为自己已经了解了足够多的方法论,但是因为精力不足,仍然经常会出现团队代码质量滑坡的问题。

以下建议按优先级排序:

1. 坚决淘汰掉代码有明显问题的人,在代码质量方面开掉一个烂程序员胜过雇10个优秀程序员。
2. 坚决的区分敏捷开发和上手就做开发,实际上敏捷开发对于团队的基础设施和人员素质要求更高。至少为团队配齐看板(问题管理工具)、持续集成(部署)流程、让团队里每个人都看过敏捷开发的书籍或者组织过敏捷开发课程之后,再开始敏捷开发实践。
3. 明确每一轮迭代的时间表,预留足够的review时间(至少有一次方案review、一次代码review)。如果时间紧张,可以直接对着旧代码讨论修改方案。
4. 组织技术评审(针对稍微大一些的需求),让开发人员向3-5个人说清楚他要做的事情和做的方法。代码是表达逻辑的一种形式,表达(技术评审)能够强迫程序员梳理清楚逻辑。
5. 初期可以让有能力的同学带着新人做一些1v1结对编程,两个人在同一个工位、共用一台电脑,至少持续3天以上。
6. 如果有资源,做一些与代码质量相关的奖惩。(我之前每年都会把各种渠道的奖金用在奖励删除代码行数最多的人,这几年没有奖金以后代码质量下滑愈发明显)

发布于 北京