如何改别人的代码?

昨天读了王垠的《什么是现实理想主义》,里面讲到了王垠对待别人的”垃圾代码”的理念:”我尽量不动它们”,我非常赞同。

我觉得对待”垃圾代码”的态度是随着工作年限的增长变化的,刚工作那会凭着年轻气盛一腔热血,总觉得自己可以把代码写的更好一些。然而,随着接触的项目越来越古老,一个比一个杂乱,那股冲动劲也是自然消磨没了。

项目年岁久远,业务庞杂,接手的人压根就没有精力去系统性的掌握项目结构,因此通常只会找一个最快最简单的方法把新需求添加上去,俗称”打补丁”,经手的人多了,代码也就面目全非了。再者,除非高薪招聘,否则是没有人心甘情愿去研究这样一个满目疮痍的项目。

当项目实在无法继续运转的时候(资历老的研发离职),管理者被迫高薪聘请能人来”填坑”,发起所谓的”重构”。这个”重构”带着一点讽刺,因为管理者本意可能只是找一个人心甘情愿的付出大量的精力来掌握这个项目的垃圾代码而已。至于是不是要把代码重新写一遍,就具体情况具体分析了。

维护这种项目的感觉就像下面的电线杆一样让人崩溃:

然而这是你的工作,抱怨再多也只能硬着头皮顶上。

如果想在上图中找出通往你家的电线,那么最简单的办法就是回到你家,顺着家里的电线往回找。另外,你也压根不会考虑把电线杆上所有的电线都梳理整齐再研究哪一根是你家的。

维护”垃圾代码”的理念应该是差不多的,找一个你感觉舒适的、简单的地方作为切入,慢慢拨开云雾,以点带面。当碰到一个头大的陌生项目时,我会感到畏惧,焦虑,但这时候最需要冷静,万事开头难。一定要把任务拆解,整理成一个执行步骤,每一步都可以帮助你建立更多的信心,就像”把大象放进冰箱需要几部?”一样:

  • 打开冰箱
  • 把大象放进去
  • 关上冰箱

感觉简单多了,至少我可以先研究如何”打开冰箱”。拿项目来说,至少可以先搞明白客户端某个功能到底是访问的哪一个服务或者接口,加上断点日志,努力找到它,完成了第一步就可以把所有精力投入到第二步,”把大象放进去”是这个问题最难的地方,就像你要在”垃圾代码”中理清业务逻辑并做出修改一样,你自然而然的会将这一步骤认定为最困难的部分,因此可以将其继续拆解成更细粒度的步骤。

如果完成第一步的信心不够充足,直接进入第二步又异常困难,不如先把第三步完成,这个过程叫做”庖丁解牛”:

始臣之解牛之时,所见无非牛者。
三年之后,未尝见全牛也。
方今之时,臣以神遇而不以目视,官知止而神欲行。

网上翻译:

第一个阶段,庖丁刚开始宰牛的时候,对于牛体的结构还不了解,看见的只是整头的牛。
第二个阶段,三年之后,他见到的是牛的内部肌理筋骨,再也看不见整头的牛了。
第三个阶段,现在宰牛的时候,只是用精神去接触牛的身体就可以了,而不必用眼睛去看。

这是一个过程,因此一定要摆正心态,逐步的完成,建立里程碑。

当你最终进入核心业务代码的时候,一定继续发挥拆解的本领,先粗粒度的拆分流程,先做什么,后做什么。之后,再看看哪些地方是可以暂时搁置的细节,哪些是提携整体的纲领,目的就是分清主次和脉络,如果纲领和核心流程看不懂影响了你继续分析代码,那么就单独立项专案专办,找懂行的人问问都是不错的方法,总之别让自己郁闷太久。

当你梳理完业务逻辑,感觉信心倍增,接下来就是要操刀开发需求了。在这一个环节,我和王垠的思路一致,就是保持对已有代码的尊重,大刀阔斧只会劳其筋骨,新增加的代码应该尽可能融入现有的代码,也就是少写代码少犯错误,再者不要轻易的删除已有代码,尽量做加法可以避免带来不愉快的结果,当然这并不是建议”打补丁”,这个理念本身是指:确保每一个改动都直击要害,多一点也不做,少一点也不做,做的恰到好处。如果你觉得新增加的代码可以和已有代码做整合,精简代码量,那么一定确保在整合过程中对每一行已有代码充满敬畏,否则后果自负。

如何改别人的代码?》上有1条评论

发表评论

电子邮件地址不会被公开。