近期看了一本书《97 Things Every Programmer Should Know》. 其中一条“Don’t Be Afraid to Break Things”。我对这句话的理解是：在察觉需求和设计不合理的第一时间，要有勇气和耐心去解决；
在实际工作中，我们遇到很多次这种情况。随着对核心业务理解的加深，以前一些不必要或者不合理的设计就会暴露出来。这时，我们需要立刻采取行动去解决，可能会耽误一些进度，但我想留下来凑合的结果会更糟糕，而且越到后面影响越大，修改的代价也越高。下面我想分享文中的Key Points：
1. changing one thing always manages to break another unrelated feature
典型的设计坏味道：脆弱性，对系统某模块的改动会导致毫无关联的其他模块出问题。当我们发现这种情况，意味着我们需要重构。
2. A skilled surgeon knows that cuts have to be made in order to operate, but she also knows that the cuts are temporary and will heal
我们知道系统存在大问题，但由于要着急上线，也担心大改动会导致问题失控，花费很多时间。所以，往往我们会选择治标不治本的方法。曾经听一个健康讲座，医生说：现在人特别忙，身体不适也没有时间检查，但是你总有时间住院的。所以，与后面住院治疗花钱费时相比，将问题在早期解决省时省力。
3. your team’s experience dealing with the sick system makes you all experts in knowing how it should work
个人认为，现在是一个Problem Driven Growth时期，大家都很聪明，谁能最早遇到“高精尖”的问题，谁成长的就快。如同，大数据处理技术，中国就有领先的潜力，中国遇到大数据并发的情况相对较多。所以，遇到这种重构的机会，要珍惜，当做“熔炉体验”，进而转化为“巅峰体验”。
4. Slowly transition the old structure into the new one, testing along the way. Trying to accomplish a large refactor in “one big shebang”
让子弹飞里面有一句话“步子迈太大，容易扯着蛋”，话糙理不糙。当我们开始重构，一定要循序渐进，即使出现问题，因为改动幅度小，也容易定位。如果急于求成，一次改太多，一旦出现问题失控，就崩溃了。
粗浅分析，抛砖引玉~~~
