« 主页

如何提升代码质量

版权声明:眯眼探云原创,可随意转载,请保留该版权声明及链接:https://tyun.fun/post/05.improve-code-quality/

这篇文章的主要目的是分享如何提交高质量的代码,以及如何通过 review 进行代码的质量控制。其中很多知识和经验并不是我个人的发明创造,我主要是把我这些年学习到的知识以及技巧,在经过实践之后,进行一定的总结。由于个人经验及能力的限制,以下讲的内容主要是和应用 app 开发相关,不过我相信同样的经验也完全可以应用到类似的开发当中。

内容的组织上我会先讲一下我对代码质量的观点,然后从写代码的角度,以及审核代码的角度分别来进行说明如何提高代码的质量。

需要的知识背景

  1. 有一定的实际开发经验
  2. 对 git 较熟悉,有一定的使用经验
  3. 了解代码审核的基本流程及目标

代码质量杂谈

我的相关工作经验主要有两个部分:一是安卓 app 的维护,二是安卓/iOS app 的持续迭代开发。从最初的代码被 review,到相互 review 代码,到后来帮助他人进行代码 review,并带领团队进行 app 研发,我算是经历了一个标准且完整的成长过程。而在这个过程中我也不断的从他人、书本、网络中学习到了不少的东西。从而逐渐形成了我现在对代码质量的一些看法。

首先来说一下,我心中的高质量的代码是什么样的:

  1. 良好的架构设计
  2. 良好的局部设计
  3. 尽可能低的复杂度
  4. 良好的可读性
  5. 良好的注释(通常在是否需要注释上有很多的争议,我的观点是:使用频度比较高的代码,本身代码可读性较差的部分,都值得加上良好的注释)

高质量的代码可以为我们带来什么样的好处:

  1. 高质量的代码通常也意味着更好的软件质量
  2. 在添加新功能以及扩展现有功能的时候更容易
  3. 代码的维护成本更低,而这是非常非常重要的
  4. 在团队更迭的时候,高质量的代码更容易传承下来:因为所有的程序员都不愿意去维护垃圾代码,能力差一点的程序员甚至无法维护垃圾代码

但是,高质量的代码并不是免费的,通常伴随着更高的成本:不止是花高价雇用资深的研发工程师,也需要花费更多的时间和人力成本。而这些时间和精力的花费带来的质量回报也并不是线性的:当质量达到一定程度以后,想要继续提高的话,成本可能是成倍增长的。

对于程序员本身来说,只要有时间,就应该尽力的去追求高质量的代码。这么做不止是因为良好的职业素养,还因为一个程序员通常是很忙的,专门的学习机会和时间并不多,而每一次对高质量代码的追求,都是一次很好的提升自己的机会。事关自己的事业发展,不容忽视。

对于一个公司(或团队)来说,就需要认真的考虑提高代码质量的开销是否能带来足够的回报,因为研发资源是非常宝贵、有限的。但具体要怎么衡量,需要大量的实践经验来进行判断,而且并不一定能判断准确,但还是有一些经验可以应用于大部分的场合:

  1. 原型软件通常不需要多高的代码质量
  2. 生命周期短的软件通常也不需要多高的代码质量
  3. 于持续迭代开发的软件,最起码要保证基本的结构良好设计,以及基础模块的代码高质量,多花点时间一定是值得的
  4. 服务器端的代码通常质量要求会更高一些
  5. 在持续的迭代中中,代码是很容易腐烂的,而且通常需要较大的代价才能将腐烂的代码拉回正轨。所以最好的做法是持续的改进代码质量
  6. 代码的质量直接受制于团队中最资深的员工的能力,而且代码质量到底怎样,并没有第三方评估(我是不是该开个公司专门干这个)

提交更高质量的代码

怎么样才能写出更高质量的代码呢?大量的学习和实践是必不可少的。我写代码也经历过好些个阶段,在不同的阶段,也会有不同的想法,其中有几点我觉得特别值得拿出来批判一下,这几点思想在被改进之后,都给我带来了长足的进步,当然,代码的质量也随之提高:

问题一解决,写代码的工作就完成了

从道理上来说,这样似乎也没错。但是现在的软件开发,几乎都是不断迭代前进的,光是解决了问题是远远不够的,必须要考虑以后的维护。也就是说,解决完问题以后,还需要花些时间来让代码变的更容易维护。

总是在良好的设计与完成功能之间反复纠结

情况大概是这个样子:写一个功能写到一半,突然是不是另外一种设计更好,于是又去尝试新的设计,试到一半,又似乎想到了更好的设计,在浪费掉许多时间后,又觉得应该先解决功能。初衷是好的:既完成功能,又能有良好的设计。但实际上把这两件事混到一起去做的时候,除了给自己带来更多的痛苦以外,并不能有效的提高代码质量,还特别浪费时间。还好我看《重构》这本书看的比较早,从中学习到了把实现功能和该善代码设计这两件事分开来做,才效的解决了我的困惑。

总想写一些代码,以后到处都能复用

代码能够复用似乎总是件好事,但在实际中却不是这样的。我经常都费了很多的时间和精力,最后发现自己写的代码并没有被复用,还白白的增加了程序的复杂度并提升了维护的难度。现实的情况是,先有具象,才有抽象。也就是说,不要想着一开始就写出高度抽象的代码,一是难以维护,二是没什么屌用。真正实用的方式是,在不断的迭代过程中,不断的改善代码,把重复的部分抽离出来。

除了基本能力的提升,那么还有没有其他办法可以快速的提高代码的质量呢?当然有!大家都知道制造业有所谓的工艺,也就是说,按照特定的方法,特定的步骤来制作产品,就可以达到相对稳定的代码质量。写程序当然也有这样的工艺。现在都用版本管理工具进行代码管理,而这就是工艺的关键。原理其实也非常的简单:

  1. 每个 commit 尽量的小,并且专注于解决一个问题
  2. 每个 commit 尽量保持高的质量,以此来保证整个软件代码的质量

那么保持软件代码高质量的工作就变成了:保持每一个 commit 的高质量。其中 review 是非常重要的一个环节,但这里主要是讲在 review 之前,写代码的过程也非常的重要的。我在完成一个 commit 的时候,会遵循一定的步骤来保证我的开发效率以及开发质量:

  1. 首先是打通关键的环节,验证自己的想法。写程序的一个特点就是:经常会碰到自己没有处理过的问题。这个时候,我的做法是首先尝试打通最关键的环节,因为通常这些关键环节的不可控风险是最大的。这样的好处是可以尽早的发现可能的风险并进行及早的处理或者规避。
  2. 快速实现这次 commit 的主要目标。这时候不用考虑额外的东西:比如临界条件,比如代码质量。(当然,一个有经验的程序员,在这个阶段其实自然而然就能选用一些良好的设计,并顺手就处理掉一些临界条件。但在经验不那么丰富的时候,还是分成多步走最合适。)
  3. 处理各种临界条件,这时候要特别小心,需要非常仔细的进行思考。处理的好的话,这个阶段可以避免相当多的程序BUG。一定要明白:出来混,迟早是要还的,临界条件处理不好,BUG一定会回来找你的。
  4. 这时候就应该考虑改善一下代码的vil:更好的设计,更统一的代码规范,更好的可读性
  5. 在提交代码以前,总是 review 一下自己的代码,我通常喜欢使用 gitx,支持命令行工具,而且看起来比较美观。

关于自动化测试

非常遗憾,在这一上我虽然有一些的经验,但我认为并不足以拿出来说道。而且国内的大环境下,绝大部分公司都并不愿意投入相应的时间、人力成本。在未来的工作中,我会非常感兴趣去寻找一些低成本的自动化测试方案。

如何 review 他人的代码

Review 代码的时候主要目标是找出潜在问题,提升代码质量。通常来说,由资深的程序员来进行 review,不仅保证代码质量,还进行了知识的传授,保持了团队的梯度建设,是非常好的。但是在实际情况中,只要有一定经验并且愿意成长的员工,都应该尝试参与代码 review,不仅可以一定程度上解放资深程序员的生产力,对自己也是非常好的锻炼。

在 review 的时候,有如下的要点:

  1. 最基本的,检查代码规范
  2. 找出潜在的问题,未处理的临界条件
  3. 检查一些隐蔽的逻辑错误
  4. 考虑代码的设计是否有明显的改进空间

实际的操作步骤其实也并不难:

  1. 通过各种 diff 工具来查看改动的代码是否合理。本地的工具我比较喜欢用 gitx,一是有命令行集成,二是看起来比较美观。gerrit 提供的在线 diff 工具也非常的好用。
  2. 一些较复杂的 change,需要将代码拿到本地,在IDE中进行 review,IDE 经常可以帮助我们发现一些问题
  3. 有些功能比较重要,且较容易出错的话,那么在 review 的时候最好编译运行进行功能验证

Review 代码本身是非常重经验的一项工作,以后再更详细的观察一下,希望能总结出更多的东西来。

欢迎拍砖!