番茄的博客

代码块越小，代码的功能越容易管理，代码的处理和移动也越简单。所以看到长长的代码块就要考虑是否可以把它”大卸八块”。第一步，找出”逻辑泥潭”。抽出逻辑块封装成一个方法，抽成方法的时候要注意变量的范围，被抽出方法外的被修改的变量应该要作为该方法的返回值返回。比较之前的想法，欠缺以下的思考： 1.在A类中重构抽出的方法mA1后，没有再往下重构，应该继续思考：抽出的方法里的变量与该类的关联大吗？是否更加契

重构原则： 1.事不过三，三则重构。当对同个业务逻辑或代码块做了类似的操作，而越来越反感的时候。第三次就应该重构了。 2.添加功能时重构：在老代码上添加新特性不方便 注：修补错误时重构可以加深代码理解，并且能更清晰的发现bug。何时不该重构： 1.项目接近Deadline，避免重构。期限过后再重构。 2.旧系统模块bug百出，基本运行也有困难，这就需要重写了。编码应该要”预先设计”，以后可