觉得最近很多文章都有些不求甚解的问题，来写点论述。
1. 重构不是什么了不起的事情
2. 变更程式码，重写旧的程式码成自己爽的样子，不一定是重构。
3. 重构是一种相对安全的工具型开发方法论，
但仍然有不少风险跟诱惑。
4. 如果你不应该或没权力改的程式码，
不要以为自称是重构就能取得变更的权力。
5. 测试(单元或整合)，是一种快速验证，
程式是否符合自己预期的工具，但并不是不会犯错的保证。
因为，自己的预期可能就是错的，也可能测试相依过深，
一时半刻没有足够好的接口，测不到真正的主要情境。
6. 不论重写或重构，所有的程式码变更都有一个本质，
要把时间花在刀口上，对重要的程式码优先处理，
不重要的程式码延后处理，程式码都有优先权问题。
所谓的程式码没坏就不要修他，
本质上是“如果他的现况不影响别的事情，暂时不用管他”。
但如果他已经卡到别的功能的扩充或维护，
造成 DEBUG 困难，常出问题等，修改他就有了价值。
那个状态就又是另一回事。
======
另外，有些话我觉得讲的不够白，做点翻译：
1. 东西没坏就不要改他：
你最近改坏的东西太多了/
你最近正常改好的东西太少了/
这段扣不关你的事情你没有权限可以碰。
2. 开发应该要先做测试：
你最近改坏的东西太多了/
你最近正常改好的东西太少了
3. 要重构之前应该要先做测试：
你现在的 CODE 搞不好都已经在乱写了，
再大规模改 CODE 会不会死的更难看。
4. 这 CODE 写的很烂：
我想把 CODE 改成我看起来爽的样子
=====
坦白说，你写程式品质高的话，要怎么炫技都可以，
凡人登山要确保，很多高手可以无确保登山，
但这些人每隔几年也就会有一两个摔死上新闻。
嗯，反正说到底改程式码的权限是个政治问题。
打着重构或效能调整的名义变更是没关系，
但有没有做好，是一翻两瞪眼的事情。
个人 Credit 丧失事小，
把使用这个工具的人给搞成白痴事大，
还麻烦大家，量力而为。
自己烂，不会开发，不要牵拖工具方法论。
要重构先还是要测试先，会问这种问题的，
还不如先练习看看什么是重构，什么是测试。