转载

知乎回答:入职后发现项目组代码异常混乱，是去是留？

此文是俺在知乎上对这个问题的回复：

知乎链接：入职后发现项目组代码异常混乱，是去是留？

楼上的@蔡磊兄分析得很清楚。对重写代码可能带来的各种风险，俺很认同他的观点，也就不再多嘴了。然而，蔡磊兄整体的论调呈相对消极的姿态，从不同角度得出这一个结论—— 重写代码是不可取的 。这里俺更愿意换个角度，谈谈积极的一面，也发出一点不同的声音。

再谈重写

在展开讨论之前，先抛出结论：对于商业价值已在明显缩水中的项目，大动干戈意义确实不大；而对于一个急速成长或稳定运行中的项目而言，有计划有步骤地整理和翻新，是非常必要而且很有讲究的。各种在初期不会显山露水的局限和瓶颈，会随着项目规模的成长不断凸显，此时，若不能水涨船高，通过积极手段逐步改良其内部实现，随着贪一时之快的补丁越积越多，系统将日趋僵化，后果自不必说。

对于重写本身，我们也大可不必畏之如虎。虽说正如 Joel 所说，“废弃现存可运作的代码跑去完全重写”几乎总是个错误的决定，但“中小型系统或组件的受控重写”却是很常见的改良系统的手段。比如这个：

Rewriting a large production system in Go

在这篇文章里，Matt Welsh 同学介绍了自己是如何使用 Go 来完全重写一个 Google 的生产环境下的系统的。推荐感兴趣的同学前往一读。此外我读过一篇讲 facebook 是如何决定和实施一个服务的重写的，还有一篇是 GitHub 如何保证重写的新系统和老系统之间无缝平滑过渡的，这两篇都蛮有趣，可现在一时之间找不到链接了，不过没关系，后面我会介绍一些我仍记得的思路。至于微软是如何(反复)重写 Windows 组件的大家可以到 The Old New Thing 上去看，老的例子有 GDI, Direct3D, Visual C++, MSE，新的例子则有 Edge (IE)。

关于从 IE 到 Edge 还有一个有趣的曲折——其实自动IE8之后微软就动了重写的心思了，在 IE9 中，微软尝试了所谓的“完全重写 (Rewrote From Scratch)”（可以参考这个链接： Inside IE9: How Microsoft rewrote its browser from scratch ）这个版本里把原来的 Javascript 解释器替换为一个新写的能生成本地的 native code 的执行引擎，把图形系统内的大多数渲染工作挪到了 GPU 上，还有一个全新的布局引擎 (With IE9, we rewrote our layout engine from scratch) 但是 (这里才是重点)，就连这种程度的重写也还是不够的，微软后来才意识到，人们的关注点变了，互联网的焦点已经在向移动端转移，于是才有了现在更彻底的重写——Windows Edge(原来的 code name 叫 Project Spartan)

好了，在了解到在有重大商业影响的项目中，重写也不是什么偶然的事情之后，我们就会明白，已有的 Legacy Code 并非刻在石头上的神谕，尝试着去逐步改进自己维护的代码，重点不在于“能不能”，而在于“ 应不应该这么做 ” ，“ 如果需要，应该做到什么程度？ ”，还有“ 实践中，如何以受控的方式去实施 ”，这样才能在避免失控的悲剧的同时，周期性地抛下越来越沉重的负担，让系统得以轻快而长久地健康运行。