[size=medium]经典重构的书籍已经叙述了很多需要重构的事情,但是很多时候书籍规书籍,实践规实践,到底搞清楚没有,还是实际项目中来得实在,真实。
真实项目重构:
重构一:
项目中把很多前期看起来差不多的逻辑,比如处理流程相同,数据具有相似性,刚开始写action,把这些全部都写在一个action里面,随着业务逻辑的变化,代码开始膨胀,当除认为相似的东西慢慢开始有分别,然后每次看到这个臃肿的类,你都痛不欲生
这个当然需要重构,属于前期考虑不足的问题
重构二:
js处理重构
到处都是重复的代码,重复有两种,代码逻辑相同,处理流程一样,但需要更改流程就悲剧了,当初让它们分开是由于每个页面js操作表现层不太一样,所以就分布到每个页面里面。
使用模板发放模式进行js重构,js重构我还是第一次
重构三:
一些没有预料的业务逻辑,比如搜索获取数据的处理,耦合到action中,然后慢慢虽然项目的进度开始逐渐变大,到后面已经到了不可控,前期没有封装这类逻辑,然后在代码里面分得到处都是,看着都不舒服,都有一种不可控感。果断根据逻辑,进行各种拆分,封装成一个个特殊的Util类,工厂方式+构建器模式(参数很多,但是不是每个参数都是必须的)
重构四:
整个项目前期估计没考虑好对异常的处理,这个带来了遇到不同异常,或者一些非法操作,没有给出很好的定义,导致无法进行很好的考虑,整个就比较大了,需要慢慢逐渐形成一个异常处理体系[/size]
真实项目重构:
重构一:
项目中把很多前期看起来差不多的逻辑,比如处理流程相同,数据具有相似性,刚开始写action,把这些全部都写在一个action里面,随着业务逻辑的变化,代码开始膨胀,当除认为相似的东西慢慢开始有分别,然后每次看到这个臃肿的类,你都痛不欲生
这个当然需要重构,属于前期考虑不足的问题
重构二:
js处理重构
到处都是重复的代码,重复有两种,代码逻辑相同,处理流程一样,但需要更改流程就悲剧了,当初让它们分开是由于每个页面js操作表现层不太一样,所以就分布到每个页面里面。
使用模板发放模式进行js重构,js重构我还是第一次
重构三:
一些没有预料的业务逻辑,比如搜索获取数据的处理,耦合到action中,然后慢慢虽然项目的进度开始逐渐变大,到后面已经到了不可控,前期没有封装这类逻辑,然后在代码里面分得到处都是,看着都不舒服,都有一种不可控感。果断根据逻辑,进行各种拆分,封装成一个个特殊的Util类,工厂方式+构建器模式(参数很多,但是不是每个参数都是必须的)
重构四:
整个项目前期估计没考虑好对异常的处理,这个带来了遇到不同异常,或者一些非法操作,没有给出很好的定义,导致无法进行很好的考虑,整个就比较大了,需要慢慢逐渐形成一个异常处理体系[/size]