@
AndyAO #18
回去查证了一下，发现记忆有些偏差，这里补充相关资料
**关于修改和重写的临界点问题**
有关软件错误和软件成本的研究都证实了这一基本事实。本书中反复提到了 NASA-Goddard 所属的 SEL 。SEL 曾详细比较了修改旧代码和完全重写所需的成本问题（ McGarry 等，1984 ； Thomas1997 ）。他们的结果清晰明确，给人深刻的印象。如果现有软件系统的 20%~25%以上需要修改，那么从头构建新产品更便宜、更容易。这个百分比低的惊人。[1]
**关于遗留代码与单元测试**
在业内人士的口中，“遗留代码” 一词常常是"无法理解的、难以修改的代码”的代名词。然而，在多年来与形形色色的开发团队共事，并帮助他们解决重大的编码问题的过程中，我总结出了一个不同的定义。对我来说，遗留代码就是那些没有编写相应测试的代码。明白这一点是很痛苦的。人们会问，代码的好坏与是否编写了测试有什么关系呢？答案很明显，而这也正是我将要在本书中阐述的：没有编写测试的代码是糟糕的代码。不管我们有多细心地去编写它们，不管它们有多漂亮、面向对象或封装良好，只要没有编写测试，我们实际上就不知道修改后的代码是变得更好了还是更糟了.反之，有了测试，我们就能够迅速、可验证地修改代码的行为 ...
开发团队的水平在不断提高，他们编写的代码也变得越来越清晰，然而旧代码要想变得更清晰就要花更长的时间。许多情况下旧代码甚至永远都不可能变得完全清晰。正因如此，我将“遗留代码”定义为“没有编写测试的代码”，而且它本身就提出了问题的一条解决方案。...[2]
[1]〔美〕 RobertL.Glass. 软件工程的事实与谬误[M]. 中国电力出版社, 2006.
[2] 修改代码的艺术 : Working effectively with legacy code[M]. 人民邮电出版社, 2007.