锁定老帖子 主题:对项目开发中的一点感悟
该帖已经被评为新手帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-12-29
一、不要想着重用别人的链接。 做web开发的页面中可点击的按钮,链接很大,当要跳转到别人的页面的时候第一个想到的就是直接调用别人的链接。当去调用别人的链接的时候,别人很有可能需要 参数,这个时候要费心为别人准备参数。再一个方式是从别人那里获得一些我们想要的东西,想为它传递特殊的值,别人不一定就能够处理这个值。 二、不要共享别人的页面。 当我们在服务层处理过请求之后,返回view层的时候,发现这个页面别人写过了正合适,直接拿来就用。当时挺爽,过段时间去测试发现开始正确的功能出了错误,费 了半天时间检查,发现别人的页面已经改动了。有这个时间自己再做一个页面都出来了。如果真的想共享别人的页面,copy一下也是可以的。 三、如果不是耦合性很高没有必要去抽取公共模块。 当抽取公共模块的时候,先考虑下他们的业务是不是真的相同,即便是真的相同是不是能用工具类来解决,当一个模块完全依赖另一个模块的时候,就是增加了模块的 耦合性了,更不要说好多个模块依赖一个模块,如果公共模块改变一点点,就要到处去灭火。 四、不要在一个方法中写太复杂的业务逻辑。 如果一个业务很复杂的话,可以写几个方法,每个方法处理不通的业务,或者把这个业务分为有层次的任务,每个层次只处理有限的业务。当一个方法处理太多的业务的时候我们的就很难把所有的问题都考虑全面。 五、不要妄想用一个接口把某个方面的业务全部处理。 也完全没有必要那样想,让多个链接走同一个方法,没有增加灵活性,也没有增加扩展性。相比较抽出一个公用的工具方法,公用同一个接口太烂了。 六、尽量写注释。 在我们写那个方法的时候,我们当时已经考虑的相当全面了,感觉业务挺简单的。但是也许10天之后我们就不知道这个描述的确切是那个业务了,更不要说那些处理这个业务方法的技巧了。 七、尽量用通用的方法来处理问题。 在我们遇见一个问题时,我们总是想着去用高级的,巧妙的,独特的方法去处理。可是在我们过几天来看代码,或者由别人来看的时候,我们也许就忘了当时的思路,再来看当时的技巧,感觉就是一个灾难。尽量用通用的技巧来处理问题,通用方式相对来说运用环境要求比较低,当我们处理的问题发生改变时,通用的方法有可能完全不用改变。除非在性能上有很大的要求,才会特殊处理。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-12-30
你说的值得我学习
谢谢! |
|
返回顶楼 | |
发表时间:2009-12-30
1,2,3都不能苟同
|
|
返回顶楼 | |
发表时间:2009-12-30
76052186 写道 1,2,3都不能苟同 如果1.2这两条遇到问题,那么就可以说项目根本没有一个整体的规划设计,大家都是自行其事,谁也不知道谁写了什么。 7应该改成尽量用简单方法处理。 |
|
返回顶楼 | |
发表时间:2009-12-30
1,2,3都不认同,
只能说明你接口和页面没有做好, 做好的会共享是不存在任何问题的 |
|
返回顶楼 | |
发表时间:2009-12-30
1 2 3的问题明显是缺乏管理,缺乏规划导致的,这就是错误假设得出错误结论
|
|
返回顶楼 | |
发表时间:2009-12-30
kj23 写道 1 2 3的问题明显是缺乏管理,缺乏规划导致的,这就是错误假设得出错误结论 对,其实项目初期构建时很重要,整合基础的模块和基础的功能很重要,还要抽取一些基础的方法和页面之类。 |
|
返回顶楼 | |
发表时间:2009-12-30
1、个人开发倾向。
2、没有前期准备。 3、没有和其他项目组的朋友很好的合作和沟通。 |
|
返回顶楼 | |
发表时间:2009-12-30
一、不要想着重用别人的链接。
你想要什么? 二、不要共享别人的页面。 你想要什么? 三、如果不是耦合性很高没有必要去抽取公共模块。 完全不认同 四、不要在一个方法中写太复杂的业务逻辑。 同意 五、不要妄想用一个接口把某个方面的业务全部处理。 接口的定义不是想与不想的问题,是需要不需要的问题 六、尽量写注释。 没办法才写注释,真正的好程序是不用写注释的,如果自己都觉的要写注释了,那你的程序是不是就有问题了。(反问自己) 七、尽量用通用的方法来处理问题。 用简单,易懂的,如果说废话的话应该是用合适的 欢迎拍砖。 |
|
返回顶楼 | |
发表时间:2009-12-30
我只看看 我不说话
|
|
返回顶楼 | |