项目进行一段时间了,总结一下。
一、不要想着重用别人的链接。
做web开发的页面中可点击的按钮,链接很大,当要跳转到别人的页面的时候第一个想到的就是直接调用别人的链接。当去调用别人的链接的时候,别人很有可能需要
参数,这个时候要费心为别人准备参数。再一个方式是从别人那里获得一些我们想要的东西,想为它传递特殊的值,别人不一定就能够处理这个值。
二、不要共享别人的页面。
当我们在服务层处理过请求之后,返回view层的时候,发现这个页面别人写过了正合适,直接拿来就用。当时挺爽,过段时间去测试发现开始正确的功能出了错误,费
了半天时间检查,发现别人的页面已经改动了。有这个时间自己再做一个页面都出来了。如果真的想共享别人的页面,copy一下也是可以的。
三、如果不是耦合性很高没有必要去抽取公共模块。
当抽取公共模块的时候,先考虑下他们的业务是不是真的相同,即便是真的相同是不是能用工具类来解决,当一个模块完全依赖另一个模块的时候,就是增加了模块的
耦合性了,更不要说好多个模块依赖一个模块,如果公共模块改变一点点,就要到处去灭火。
四、不要在一个方法中写太复杂的业务逻辑。
如果一个业务很复杂的话,可以写几个方法,每个方法处理不通的业务,或者把这个业务分为有层次的任务,每个层次只处理有限的业务。当一个方法处理太多的业务的时候我们的就很难把所有的问题都考虑全面。
五、不要妄想用一个接口把某个方面的业务全部处理。
也完全没有必要那样想,让多个链接走同一个方法,没有增加灵活性,也没有增加扩展性。相比较抽出一个公用的工具方法,公用同一个接口太烂了。
六、尽量写注释。
在我们写那个方法的时候,我们当时已经考虑的相当全面了,感觉业务挺简单的。但是也许10天之后我们就不知道这个描述的确切是那个业务了,更不要说那些处理这个业务方法的技巧了。
七、尽量用通用的方法来处理问题。
在我们遇见一个问题时,我们总是想着去用高级的,巧妙的,独特的方法去处理。可是在我们过几天来看代码,或者由别人来看的时候,我们也许就忘了当时的思路,再来看当时的技巧,感觉就是一个灾难。尽量用通用的技巧来处理问题,通用方式相对来说运用环境要求比较低,当我们处理的问题发生改变时,通用的方法有可能完全不用改变。除非在性能上有很大的要求,才会特殊处理。
一、不要想着重用别人的链接。
做web开发的页面中可点击的按钮,链接很大,当要跳转到别人的页面的时候第一个想到的就是直接调用别人的链接。当去调用别人的链接的时候,别人很有可能需要
参数,这个时候要费心为别人准备参数。再一个方式是从别人那里获得一些我们想要的东西,想为它传递特殊的值,别人不一定就能够处理这个值。
二、不要共享别人的页面。
当我们在服务层处理过请求之后,返回view层的时候,发现这个页面别人写过了正合适,直接拿来就用。当时挺爽,过段时间去测试发现开始正确的功能出了错误,费
了半天时间检查,发现别人的页面已经改动了。有这个时间自己再做一个页面都出来了。如果真的想共享别人的页面,copy一下也是可以的。
三、如果不是耦合性很高没有必要去抽取公共模块。
当抽取公共模块的时候,先考虑下他们的业务是不是真的相同,即便是真的相同是不是能用工具类来解决,当一个模块完全依赖另一个模块的时候,就是增加了模块的
耦合性了,更不要说好多个模块依赖一个模块,如果公共模块改变一点点,就要到处去灭火。
四、不要在一个方法中写太复杂的业务逻辑。
如果一个业务很复杂的话,可以写几个方法,每个方法处理不通的业务,或者把这个业务分为有层次的任务,每个层次只处理有限的业务。当一个方法处理太多的业务的时候我们的就很难把所有的问题都考虑全面。
五、不要妄想用一个接口把某个方面的业务全部处理。
也完全没有必要那样想,让多个链接走同一个方法,没有增加灵活性,也没有增加扩展性。相比较抽出一个公用的工具方法,公用同一个接口太烂了。
六、尽量写注释。
在我们写那个方法的时候,我们当时已经考虑的相当全面了,感觉业务挺简单的。但是也许10天之后我们就不知道这个描述的确切是那个业务了,更不要说那些处理这个业务方法的技巧了。
七、尽量用通用的方法来处理问题。
在我们遇见一个问题时,我们总是想着去用高级的,巧妙的,独特的方法去处理。可是在我们过几天来看代码,或者由别人来看的时候,我们也许就忘了当时的思路,再来看当时的技巧,感觉就是一个灾难。尽量用通用的技巧来处理问题,通用方式相对来说运用环境要求比较低,当我们处理的问题发生改变时,通用的方法有可能完全不用改变。除非在性能上有很大的要求,才会特殊处理。