程序员需要知道的97件事情 --- 写在重构代码之前

[size=medium] 本人英语抄过4级，奇烂无比，翻译这个实属蛋疼，错误是肯定有的，而且是翻不出来就是随便猜，欢迎指正，谢谢啦。但愿我能够翻完我看的懂的....
原链接：oreilly的程序员需要知道的97件事http://programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book

在项目的某些阶段，程序员们都可能需要去重构现有的代码。请您在重构之前，思考以下的一些问题，也许能够帮您节省一大堆时间和痛苦。
1． 重构的最佳开始途径是在开始阶段观察现有的代码和对应的单元测试代码（就是要先读一遍代码）。这将会让更好你理解现有代码的健壮和孱弱之处。你就能够让你在避免错误的情况下保留健壮的代码。（这个其实我不大理解，可能我项目中代码中的测试案例太少，导致测试代码无法当做参考）我们大多数都和你自信能够做的比现有系统好，直到我们写出那些并不高明的代码….或者更糟，比现有系统拥有更多的错误，因为我们没法从原来的错误中吸取经验。
2． 远离重写一遍的诱惑。我们大多数浮躁的程序员，总以为以前的代码太烂，恨不得自己重写一遍。在重构的时期，最佳实践就是尽量重用以前的代码。无论原先代码多么的难看，它都是被测试过的，被检查过的，是正确的.抛弃原先的代码，特别是生产的代码，意味这你抛弃了数月或者数年的测试，这些根深蒂固的代码可能有那些你所不知道的确切工作区域和ＢＵＧ修复，如果你没有给予足够的重视，你的新写代码可能会犯原来老代码早已经修改过的ＢＵＧ，这样做是完全浪费时间，效率，以及数年来积累的经验。
3． 大量的小范围重构比一大块的重构效果好。一个个小块的重构让你更加容易控制重构对于系统带来的影响，也更加容易从用户的反馈上来了解重构带来的效果，例如测试。如果做一个改变，而带来一大堆需要测试的点，这样是谁也不希望看到的。不恰当的重构会带来挫折感和压力。合理重构带来一部分方便测试的任务，可以很方便管理。
每次重构之后，必须去确认能够通过所有已经存在的测试用例。如果已有的测试用例无法完全覆盖你的代码，去新增测试用例。不要忽视原有代码的测试，因为你永远无法确认你的重构是否影响了他们。
4. 不要无缘无故的去修改前人的代码。认为自己一定比前人更加聪明，这也是一个人让人发笑的理由。

5. 新技术不是重构的理由，现有代码使用的技术落后于如今的技术酷，或者新潮，这是我看到的最不靠谱的理由。我们相信新的框架或者语言能够有更好的生产力，除非有一个权威的分析指出，新的框架或者语言能够给我的现有系统在功能上，可维护上，生存率上带来全面的提高，我才能够由此去做重构。

6. 永远要记住，是人都会犯错误。重构过程中并不能保证新的代码更加完美，或者和以前一样好。前车之鉴，我见过很多的失败的重构尝试，
[/size]