加上系统本身也是在不断地完善壮大，更新的过程也是变更的过程。

从这个角度来看，只要你写出来的东西，还有人在用。你自己对它还有优化的意愿。那么，代码注定是需要不停改变的。

所以，改变是代码的宿命。设计的意义就是为了让代码容易被改变。

作者提到说到底那么更加细节的设计原则，都只是为了实现ETC原则而已。

想想也确实是如此。从最基础的面向对象来说，封装可以更方便地更改属性的访问权限，更方便更改方法内部的具体实现；继承可以更方便的“更改”父类的行为；多态可以更方便更改不同的实现……

作者甚至提到，命名规则也同样有助于实现ETC原则。命名规范有助于更容易读懂代码，我们需要先读懂代码才能修改代码。哈哈哈，无法反驳。

作者同时提到，ETC不是一种规则，而是一种价值观。它是我们在多个选项中做出选择的依据。

在写下某段代码之前不妨想想，这段代码是让改变变得更简单了还是更困难啦？

当然，把作为价值观的前提是，我们需要知道怎么判断哪种写法更有利于改变。

如果我们暂时也不知道该怎么判断的时候。作者给了两个方法。

1. 试着让你写的东西可以被替换。这样，即便写的东西不行，到时候全被换掉也是可以的。

根据我本人的愚见，其实我并不是很能理解这一条，我感觉让写的东西可以被替换，和让写的东西更容易更改，没什么区别吧。

2. 在注释中写上当时都有哪些选择，为什么选了这一个。到时候这个地方需要修改的时候，可以作为一种依据。

这一点和昨天提到的写文档的时候要写上原因是一个道理吧，可见注释是真的非常重要。

要让ETC变成一种日常思考的习惯。只有通过刻意练习，才能把它内化。不然看完就忘了，对往后的编码并没有多大的裨益。

作者提到了一种方法，给我们的编辑器增加一个配置，在每次保存的时候，都弹出一个提示，“刚刚写的东西，容易修改吗？满足ETC吗？”。

版权申明：本站文章均来自网络，如有侵权，请联系01056159998 邮箱：itboby@foxmail.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有