程序猿的吐槽二

重构时机

     在对项目的业务和代码不是很熟悉的情况下，在添加功能或者修改代码的时候，尽量遵守和之前代码一样的风格和逻辑，即使以前的代码风格和逻辑很不好，此时不管你有多么大的重构冲动，还是应该忍耐一下。但是你可以做一个重构标记，作为一个任务待定。切忌装13而贸然标新立异的改动，记住即使风格混乱，只要混乱的非常一致，那也不错，因为风格没有对错，只有是否一致。如果你需要修改的代码你觉得很不爽，但是人家全部的代码都是这种风格，那么你就需要好好考虑一下。你的改进也许使得代码变得真正的混乱和不一致了。

     正如一排走方阵的队伍，如果大家都迈脚迈错了（或者大家都顺拐了），那么对于整个队伍来说还是整齐的。当然观众可以通过这种“错误”的逻辑规则来理解这种方式。但是突然队伍里面来了一个人，他觉得大家都走错了，或者这种走方阵的方式觉得太变态，太out，太没有技术，自己用这种方式都觉得丢人。这时候他自己修改了之前的这种出脚的方式（比如之间都是先出左脚，而他修改为先出右键以显得更为先进和牛逼或者“正确”），这样就出现了有迈左脚有迈右脚的情况。这种不一样的情况出现之后，观众看到的就是混乱和无法理解，或者规则就会变得更加负责和说明文档变得更加厚实。

     那么对代码的熟悉如何量化？1，不熟悉此段的业务逻辑，2，不了解此段代码的全局调用关系。

     如果此段代码相对独立，调用关系单一，或者你掌握了全部的调用关系，那么即使业务逻辑你不是很熟悉，那么也可以利用重构理论在不改变现有代码逻辑和实现的情况下进行代码结构和风格的重构。