项目剖析

这道题目并不大，但是已然表现出向烂代码自然演进的潜质：使用if-else堆叠功能、各种不走心的命名、缺乏结构等等（若不是为了练习的缘故，很可能单元测试也不会有哩）。读者可以想见，如果在转换需求上再增加一种单位，将需要改动多少地方。

看到代码，如果你也像那许多对烂代码毫无容忍的工程师、整洁斗士一样早已坐立难安，打算挽起袖子，一鼓作气把代码整理成理想的样子，那非常好。但我不得不提醒你，你可能操之过急了。

你要关注的，不仅是重构的结果，更关键的是重视重构的过程。

我们见过许多一鼓作气的例子，往往不是要冒着大的风险，就是破坏了应用的功能，难以撤回，造成负面的效果。要避免这样的结果，除了必胜的信心，还得有日拱一卒的精神，熟能生巧的重构技巧。有同学可能会问，你说重视重构的过程，指的是什么呢？

我是指，在重构过程的每一分钟，系统既有功能都仍然能正确运行。

如果你的重构过程能保证这一点，那么你就有很大的信心克服前述的问题，不破坏系统功能、安全前进；如果不能保证，那么你的“重构”过程实际上有可能是原始的刀砍斧劈，随时冒着改动系统功能的风险。

要做到这一点，就需要你有可靠的测试集，需要你频繁地运行它们，需要你的重构手法小步到一行代码的粒度。这就是我们强调的重构的基本功，以及对过程的重视，也是这个练习中我们真正强调的东西。