关于散弹式修改
修改一个地方，引起了很多地方都要修改。
举例1：
我在代录页面添加了一列，然后清空列的功能就收到了影响。添加的一列值不能被清空掉。
1： xml里面要多返回一列
2： grid初始化里面要新加入一列
3： grid赋值和取值的地方进行了修改
4： 清空的地方进行了修改
分析：如果要修改一个地方，并且这个地方可能会引起其他的行为修改，那么这些行为应该定义在一个地方，修改起来比较方便。比如，将这些变化的地方做成一个对象类，每次只修改这个对象类。
每一列的相关属性和方法，应该定义在一个类中，这里就是Field类。每次只要修改Field类就好了。
举例2
每月付记的条目我进行了修改，代录第一页的标签和文本切换和清空按钮收到了影响。
分析：获取每月复记的条目的逻辑是公用逻辑，但是写在了多个地方，长度也是写死的，并且也写在了多个地方。 程序的公用入口应该只有一个。
比如常量，也应该定义在一个地方。
幼稚的数据类
数据类的产生原因：
受hibernate等框架的影响，java框架中对get和set的应用很多
受到隐藏作用域思想的影响
有的类中某个函数要完成处理，需要的参数有很多，就做了这种数据类
数据类的缺点
未理解面向对象的设计方法
增加了类的数量
举例1
公用导出中，根据action导出文件的模块。
我首先根据前台js传递来的导出参数，映射成后台的属性，于是我新建了一个类，并生成了get set方法。这个类后来只用来进行了存储数据的功能。
根据这些参数形成文件的逻辑，应该都放到这个类中来。
将数据类有关的行为转义到数据类中对我来说，无疑是一个观念上的转变。
关于为什么要重构，我的想法
在平时的开发中，很少有能进行重构的场合。开发人员对重构的认识有限，没有认识到重构带来的好处。时间紧迫，写代码加测试模式的超级敏捷开发流程是大流
我们不得不在很多情况下维护某些代码，这些代码不得不被修改。这些代码我们不容易看懂，看懂了发现修改一个地方会引起很多地方要进行修改，需要变化的地方可能是分散在软件的各个角落，每错过一个地方，都可能会引起严重的问题，导致返工。
然后我们就想，为什么当时设计程序时候没有更好的设计呢？为什么没有把变化的东西封装到一个类中呢？ 因为各种原因，开发时候的确做不到这点，那维护的过程中我们是有精力去做这件事情的，重构了这些代码，能更便于我们日后维护。我们也知道以后将怎么提高我们软件的可读性和可维护性。
有些类只有方法的思考
有一个类，类中有一些方法，类没有什么字段，方法很长，方法中有很多参数，可以将这个方法做成一个对象。
这样一来，有一种观念的改变，你不是总在定义方法，你定义了对象。
函数是可以转化为对象的，避免函数参数过长 这也是个思想上的改变
关于算法的思考
我开发记账易软件时候，做一个用户选择记账方式的页面，我有一个逻辑，后来出现了很多问题，我发现我把问题想的很复杂，但是觉得这东西应该没有这么复杂，后来换掉算法后，发现清晰了很多，BUG也少了很多。
像EXCEL的合并算法，拐角现算法都有优化的控件
如果一个类的功能很少，那就应该把这个类的功能转义到其他函数中，这样就能少维护一些类。
单向关联与双向关联
定义常量 避免常量的值分散在类的各个角落。如果你引用的值可以通过其他的入口获得，请修改成统一入口，避免修改多个地方。
关于异常
非受控异常 程序员犯的错误 不可以被捕捉处理，程序强制终止，调用的时候应该检查的但是没有检查。
受控异常 调用的时候，调用者没有检查，检查的责任在我们负责的部分，我们应该抛出一个异常，这个异常是可以被调用者捕捉的，并且调用者可以选择发生异常的时候应该怎么做。
当接口发生改变的收，接口的结构最好不要发生改变，因为调用的地方可能会很多。比如加上了抛出异常处理。
受控不受控这个东西，对我是个新知识。