人
- 思想:
提前思考如何避免低质量代码,并不断总结保持初心,觉得写低质量代码是耻辱。
持续不断的寻找代码质量与时间成本的平衡点,保持敬畏心,保持对高质量代码的不断追求的进取心。 - 素质:
保持对低质量代码敏感度,有洁癖,不妥协与进度和时间的压力
代码是会腐烂的,持续学习,勇敢的重构陈旧腐烂的代码,不要等爆炸后再来补救。 - 技能:
熟练代码设计能力,80%设计 20%编码
熟练重构低质量代码提高可读性以及可维护性,增加代码复用率
善于发现代码质量隐患
团队
- 团队高度统一的对代码质量足够重视。
不能只是停留在嘴上说要保证代码质量,但是还是在无视各种代码质量活动,我私下做过一个调查,80%的人都认为CodeReview之所以难以推行是因为“没时间”,但在我看来,真正阻碍我们的是“对低质量代码治理的决心”,咱们的团队把80%的时间都花在被动苦干治理(改BUG,代码腐烂之后重构)低质量代码上了,而对于可以预防低质量代码的提前思考的手段(Code Review 单测 代码详细设计)很轻视。这说明咱们并不是没时间,只是咱们从小所受的教育使我们“勤于苦干,懒于思考”。 - 代码隔离,保护
保证代码质量的基础手段,都在一个锅里吃饭很容易交叉感染,保持对代码的隔离也是团队保持对代码敬畏的一个最基本手段。
结对编程:碰到不确定和复杂问题时一定要结对编程,既可以提高编程效率,也可以填补单人认知不足导致的不必要的代码缺陷引入。 - TDD
测试驱动开发,单测先行,也是需要从团队基因和思想层面改进的东西,事后补单测的行为只能发挥单测20%的价值。单测不光是为了覆盖率和报告,单测是开发阶段质量保证手段,也是支撑重构的保证。没有单测保证,CodeReview后的重构完全是在走钢丝,很容易就摔死了。
Code Review:无处不在,不应该排任务,也不应该去量化,这件事情是每个工程师的基本责任,也是团队文化,随时看见烂代码和坏味道都应该勇敢的指出并大胆重构小心测试。前提是需要完整的单元测试来保证质量。
工具:
工具是目前最容易发力的地方,见效快,但也很有限,真正能够保证代码质量的还是在“人”和“团队”这两个方面。
- GitLab merge request 做代码隔离
- Start UML提前做好实现方案设计,并通过团队和架构师的评审
- XUnit 做全业务场景覆盖的单元测试,支撑日后的不断重构优化