1. 变化是必然的：拥抱“柔性”设计
“柔性设计”不是指设计能预测所有变化，而是指当变化来临时，修改所造成的连锁反应被降到最低。这直接回到了我们10月份讨论的正交性和DRY原则。
糟糕的设计（缺乏柔性）： 如果我当初直接写死一个Book类，现在就需要修改这个类，加上fileSize字段，并增加一个type字段来区分是纸质书还是电子书。这会导致所有用到Book类的地方（显示、存储）都要增加if-else判断，违反了开放-封闭原则。
柔性的设计（运用多态）： 幸好我前期有意识地使用了接口和继承。我很容易就做出了以下重构：
创建一个Publication接口（或者抽象类），定义getId(), getName(), getAuthor()等共同方法。
让原来的Book类实现这个接口，并改名为PaperBook。
新建一个Ebook类，同样实现Publication接口，并拥有自己的fileSize属性。
这样，我的BookService和BookRepository可以改为操作Publication接口。无论是纸质书还是电子书，都可以被统一管理。增加新的出版物类型（比如期刊）也变得非常容易。变化被限制在增加新模块（新的实现类），而不是修改现有模块。
2. 重构：而不是“凑合”
书中将代码的退化比作“熵增”，而重构就是我们对抗熵增的武器。重构不是等到代码烂透了再重写，而是在日常开发中持续进行的、保持代码健康的小调整。
虽然功能没变，但代码的可读性大大增强，每个小方法都可以被独立理解和测试。这就是重构的魅力。
3. 何时重写？艰难的决策
书中也坦诚地讨论了“何时应该重写”。当代码库已经千疮百孔，修补的成本高于重建的成本时，就需要考虑重写。这让我想起我大一用C写的一个小游戏，代码全部挤在main函数里，没有任何结构可言。现在去看，修复一个bug会引入两个新bug。对于那种情况，重写是比重构更经济的选择。但对于我现在的Java项目，由于前期注意了设计，代码结构还算清晰，持续的重构是更优策略。
