<大话重构>读后感

在看了<大话重构>的前几章后，我觉得我应该记下一些读书笔记并反思下自己在日常工作中的经验，两者相结合，以后重新看回这些文章，可以更清楚的认识自己，清晰自己对于技术之路一路的演变过程，一个美好而又充满困惑的过程。

 重构的两顶帽子，在现实情况中就确实只有这两种，改与不改

1. 不改，设计出一个独立分支，即扩展原有的系统，不修改其原来，不用担心现有系统被改出问题.

2. 改，修改原有的系统，建立出扩展点便于支持新功能的加入，重构原有的设计以适应新的需求

在日常的项目中，经常会遇到这种情况

1. 一个表格新增一列只做显示，只需直接增量修改

2.一个表格新增一列，合并两列，合并后的两列添加了输入框，一些交互控件。这样的需求一拿来，你有两种选择，一是隐藏现有的两列，新加一个合并列，另一个是，合并现有的两列，添加交互控件。

3. 现有三张表格，需要在现有的三张表格上添加三个列。

   这时候问题来了，我三张表格逐个添加， 或是建一个父类表格，三张表继承， 或是把三个列圈成一个块，三张表格引入。 这时候的三种决定不是靠抛硬币决定的，要看新增的三个列对于现有的表格有何意义，说白了，就是你对新增需求的理解，看这三个列是属于基础类别还是属于增量类别。

2,3种情况都是需要考虑要不要重构， 如果要重构，项目主管通常都会问你修改后会有什么影响，特别是对现有功能的影响，如果修改需要多少时间，这是否会影响到当前的进度。然后如果改动大，就需要做评估，评审。像<大话重构>的作者，每次重构都是10分钟到1小时，都是很短时间的重构。 如果每次都告诉项目主管都是这么短时间且没有影响，我想他们都会很乐意接受吧。 实际上，对于半路接手的系统，想做一个局部重构，就必须读懂现有的系统，了解他的前世今生，才能保证不踩坑，通常做到这样，都需要比较多的时间，特别是去读懂旧系统相关的需求，还要判断新需求在原设计是否有适应。

     是得真的等重构成为习惯的时候，才能如此的洒脱，一见到不合理，立即小步快跑重构一番，如此迭代。