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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Talk is cheap, just DO IT!

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