「壹期壹问」VOL6. 如何优雅地修改前同事逻辑复杂的代码?

一期一问900x500

「壹期壹问」VOL.6 收录的问题

老同事的复杂逻辑代码,现在要改需求,如何优雅地根据需求修改?——来自用户 斯温

来自 LeanCloud iOS 工程师唐天勇的回答

如果不限定修改代码的人,请容我抖机灵地回答:「把老同事拉回来,让他来改代码」。

嗯貌似有点不太靠谱,那我们就来严肃地掰扯下这个话题吧。

在软件项目的生命周期中经常会出现开发人员的新老交替,这时项目对于新成员来说就是一堆遗留的代码,他要面临的挑战也会随之而来:

  1. 不了解项目设计和代码实现
  2. 代码混乱
  3. 缺乏测试代码

多希望新成员们都能顺利通过上面的第一项考验,可现实情况是许多人都不幸地折在了那里。

我有个朋友几年前加入了一家做社交应用的公司。入职当天,老板给了他一个挑战自我的机会──希望他在一周内熟悉业务系统的代码。接着老板向朋友补充说,维护那套系统的人已经离职。我不清楚朋友是否在老板期望的时间内熟悉了代码,但后来他告诉我,那段时间是他职业生涯中最黑暗的时期。

只有对项目设计和代码实现胸有成竹,才能在其基础上进行改动。不过,在此我们不讨论如何熟悉项目,而是重点关注题目中的问题「如何修改混乱的代码」,并且假设题主已经熟悉了手中的项目。

编程的本质是控制复杂性。 毫无疑问,混乱的代码增加了复杂性。如果对混乱的代码置之不理,直接在上面修改或者增加新功能,复杂性往往会与日俱增。因此,当发现项目代码开始变得混乱时,就应当保持警觉并采取措施,把混乱扼杀在萌芽阶段。混乱的代码是技术债务,即使不碰它也会产生利息。因为随着时间的推移,你会对这些混乱感觉越来越陌生。为了不让债务越来越多,你就应该及时去消除技术债务。消除混乱的方法通常有两种选择:重构(Refactoring)和重写(Rewrite)。

重构和重写的共同目的是让混乱变得有序。 但它们有一些区别,下面我从几个方面来对比一下这些区别。这些区别不一定对所有系统都准确,但对大部分软件项目都是适用的。

  • 重构是渐进式的行为,每次只改变局部;而重写是侵入式的行为,一切都从头开始;
  • 由于重构每次只改变局部,可以更好控制混乱;而重写一开始就改变整体,更难控制;
  • 由于重构更好控制混乱,周期更短;而重写往往周期更长。

那么问题来了,当面临混乱的代码时,我们应该选择重构还是重写?

除非有充足的理由,否则最好不要重写,因为你几乎无法肯定会比现在做得更好。另一个重要原因是,重写往往会花更长的时间。对软件公司来说,时间尤其宝贵,不过这里并不是一味地否定重写,现实世界中也有许多重写的成功案例。

最后一个问题是缺乏测试。不清楚题主的项目是否包含单元测试,测试是否覆盖了这些混乱的代码。如果有充分的测试,重写或重构将会安全很多。因为它至少可以保证改动前后,代码的外部行为是一致的。

如果说重构是改革,那重写就是革命。是想来一场循序渐进的改革,还是轰轰烈烈的革命呢?题主可以根据项目的特点,结合开发周期等因素来综合考虑。

Talk is cheap, just DO IT!


如何参与「壹期壹问」:大家可以通过 问题提交通道 来向 LeanCloud 提问。

「壹期壹问」VOL6. 如何优雅地修改前同事逻辑复杂的代码?》上有1条评论

  1. EverLoop

    现代应用开发的特点就是要快,要快. 所以只能重构,重写的时间和代价是无法承受的. 不信? 好吧,一个 300 万行代码的项目,麻烦 3 天之内重写完了. 3天之后,开始 2.0->3.0 的开发工作.

    回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注