假设你已经读过烂代码系列的前两篇:了解了什么是烂代码,什么是好代码,但是还是不可避免的接触到了烂代码(就像之前说的,几乎没有程序员可以完全避免写出烂代码!)接下来的问题便是:如何应对这些身边的烂代码。

  1. 改善可维护性

  改善代码质量是项大工程,要开始这项工程,从可维护性入手往往是一个好的开始,但也仅仅只是开始而已。

  1.1. 重构的悖论

  很多人把重构当做一种一次性运动,代码实在是烂的没法改了,或者没什么新的需求了,就召集一帮人专门拿出来一段时间做重构。这在传统企业开发中多少能生效,但是对于互联网开发来说却很难适应,原因有两个:

  互联网开发讲究快速迭代,如果要做大型重构,往往需要暂停需求开发,这个基本上很难实现。

  对于没有什么新需求的项目,往往意味着项目本身已经过了发展期,即使做了重构也带来不了什么收益。

  这就形成了一个悖论:一方面那些变更频繁的系统更需要重构;另一方面重构又会耽误开发进度,影响变更效率。

  面对这种矛盾,一种方式是放弃重构,让代码质量自然下降,直到工程的生命周期结束,选择放弃或者重来。在某些场景下这种方式确实是有效的,但是我并不喜欢:比起让工程师不得不把每天的精力都浪费在毫无意义的事情上,为什么不做些更有意义的事呢?

  1.2. 重构step by step

  1.2.1. 开始之前

  开始改善代码的第一步是把IDE的重构快捷键设到一个顺手的键位上,这一步非常重要:决定重构成败的往往不是你的新设计有多么,而是重构本身会占用多少时间。

  比如对于IDEA来说,我会把重构菜单设为快捷键:

1524034ymoro2ouczv6qqr.png
  这样在我想去重构的时候就可以随手打开菜单,而不是用鼠标慢慢去点,快捷键每次只能为重构节省几秒钟时间,但是却能明显减少工程师重构时的心理负担,后面会提到,小规模的重构应该跟敲代码一样属于日常开发的一部分。

  我把重构分为三类:模块内部的重构、模块级别的重构、工程级别的重构。分为这三类并不是因为我是什么分类强迫症,后面会看到对重构的分类对于重构的意义。

  1.2.2. 随时进行模块内部的重构

  模块内部重构的目的是把模块内部的逻辑梳理清楚,并且把一个巨大无比的函数拆分成可维护的小块代码。大部分IDE都提供了对这类重构的支持,类似于:
 

  • 重命名变量
  • 重命名函数
  • 提取内部函数
  • 提取内部常量
  • 提取变量


  这类重构的特点是修改基本集中在一个地方,对代码逻辑的修改很少并且基本可控,IDE的重构工具比较健壮,因而基本没有什么风险。

  以下例子演示了如何通过IDE把一个冗长的函数做重构:

152411a8my8yh6hpheqypw.jpg
  当然,关于持续集成还可以做的更多,篇幅所限,就不多说了。

  3.1.4. 质量文化

  不同的团队文化会对技术产生微妙的影响,关于代码质量没有什么共同的文化,每个公司都有自己的一套观点,并且似乎都能说得通。

  对于我自己来说,关于代码质量是这样的观点:

 

 

  • 烂代码无法避免
  • 烂代码无法接受
  • 烂代码可以改进
  • 好的代码能让工作更开心一些

  如何让大多数人认同关于代码质量的观点实际上是有一些难度的,大部分技术人员对代码质量的观点是既不赞成、也不反对的中立态度,而代码质量就像是熵值一样,放着不管总是会像更加混乱的方向演进,并且写烂代码的成本实在是太低了,以至于一个实习生花上一个礼拜就可以毁了你花了半年精心设计的工程。

  所以在提高代码质量时,务必想办法拉上团队里的其他人一起。虽然“引导团队提高代码质量”这件事情一开始会很辛苦,但是一旦有了一些支持者,并且有了可以参考的模板之后,剩下的工作就简单多了。

  这里推荐《布道之道:引领团队拥抱技术创新》这本书,里面大部分的观点对于代码质量也是可以借鉴的。仅靠喊口号很难让其他人写出高质量的代码,让团队中的其他会到高质量代码的收益,比喊口号更有说服力。

  4. 最后再说两句

  优化代码质量是一件很有意思,也很有挑战性的事情,而挑战不光来自于代码原本有多烂,要改进的也并不只是代码本身,还有工具、习惯、练习、开发流程、甚至团队文化这些方方面面的事情。

  写这一系列文章前前后后花了半年多时间,一直处在写一点删一点的状态:我自身关于代码质量的想法和实践也在经历着不断变化。我更希望能写出一些能够实践落地的东西,而不是喊喊口号,忽悠忽悠“敏捷开发”、“测试驱动”之类的几个名词就结束了。

  但是在写文章的过程中就会慢慢发现,很多问题的改进方法确实不是一两篇文章可以说明白的,问题之间往往又相互关联,全都展开说甚至超出了一本书的信息量,所以这篇文章也只能删去了很多内容。

  我参与过很多代码质量很好的项目,也参与过一些质量很烂的项目,改进了很多项目,也放弃了一些项目,从最初的单打独斗自己改代码,到后来带领团队优化工作流程,经历了很多。无论如何,关于烂代码,我决定引用一下《布道之道》这本书里的一句话:

  “‘更好’,其实不是一个目的地,而是一个方向…在当前的位置和将来的目标之间,可能有很多相当不错的地方。你只需关注离开现在的位置,而不要关心去向何方。”

  相关阅读关于烂代码的那些事

       关于烂代码的那些事(中)

via:Axb的自我修养

声明:游资网登载此文出于传递信息之目的,绝不意味着游资网赞同其观点或证实其描述。
锐亚教育

锐亚教育,游戏开发论坛|游戏制作人|游戏策划|游戏开发|独立游戏|游戏产业|游戏研发|游戏运营| unity|unity3d|unity3d官网|unity3d 教程|金融帝国3|8k8k8k|mcafee8.5i|游戏蛮牛|蛮牛 unity|蛮牛