对项目开发中的一点感悟

项目进行一段时间了，总结一下。
一、不要想着重用别人的链接。
做web开发的页面中可点击的按钮，链接很大，当要跳转到别人的页面的时候第一个想到的就是直接调用别人的链接。当去调用别人的链接的时候，别人很有可能需要
参数，这个时候要费心为别人准备参数。再一个方式是从别人那里获得一些我们想要的东西，想为它传递特殊的值，别人不一定就能够处理这个值。

二、不要共享别人的页面。
当我们在服务层处理过请求之后，返回view层的时候，发现这个页面别人写过了正合适，直接拿来就用。当时挺爽，过段时间去测试发现开始正确的功能出了错误，费
了半天时间检查，发现别人的页面已经改动了。有这个时间自己再做一个页面都出来了。如果真的想共享别人的页面,copy一下也是可以的。

三、如果不是耦合性很高没有必要去抽取公共模块。
当抽取公共模块的时候，先考虑下他们的业务是不是真的相同，即便是真的相同是不是能用工具类来解决，当一个模块完全依赖另一个模块的时候，就是增加了模块的
耦合性了，更不要说好多个模块依赖一个模块，如果公共模块改变一点点，就要到处去灭火。

四、不要在一个方法中写太复杂的业务逻辑。
如果一个业务很复杂的话，可以写几个方法，每个方法处理不通的业务，或者把这个业务分为有层次的任务，每个层次只处理有限的业务。当一个方法处理太多的业务的时候我们的就很难把所有的问题都考虑全面。

五、不要妄想用一个接口把某个方面的业务全部处理。
也完全没有必要那样想，让多个链接走同一个方法，没有增加灵活性，也没有增加扩展性。相比较抽出一个公用的工具方法，公用同一个接口太烂了。

六、尽量写注释。
在我们写那个方法的时候，我们当时已经考虑的相当全面了，感觉业务挺简单的。但是也许10天之后我们就不知道这个描述的确切是那个业务了，更不要说那些处理这个业务方法的技巧了。

七、尽量用通用的方法来处理问题。
在我们遇见一个问题时，我们总是想着去用高级的，巧妙的，独特的方法去处理。可是在我们过几天来看代码，或者由别人来看的时候，我们也许就忘了当时的思路，再来看当时的技巧，感觉就是一个灾难。尽量用通用的技巧来处理问题，通用方式相对来说运用环境要求比较低，当我们处理的问题发生改变时，通用的方法有可能完全不用改变。除非在性能上有很大的要求，才会特殊处理。

评论

33 楼 nishizhutoua 2010-01-01  

...汗死了,最近开始喜欢用一个

interface IBizHandle<T>{

    int operate(T o)

}

来抽象业务了...

在通过一个BizChain组合,小项目效果还不错

32 楼 gsearch 2009-12-31  

谢谢 LZ 学习了

31 楼 twobowl_eye 2009-12-31  

缺乏主题，对别人没意义

30 楼 prowl 2009-12-31  

楼主2年时间都浪费了

29 楼 realdah 2009-12-31  

Design by contract!
Develop by contract!

28 楼 强强爱妍妍 2009-12-31  

新程序员吧

27 楼 soci 2009-12-31  

1不同意，WEB开发 一个连接对应一个或N个功能怎么可能不共用，url+参数 其实和业务层的接口里的方法签名是一回事。组员是要遵守的。

26 楼 giginet 2009-12-31  

后面几条同意，前3条明显不敢苟同。可能lz没说清楚吧。

前几条原因明显是协作出现问题，并非程序开发和设计的问题。

25 楼 meiowei 2009-12-31  

sunhj000java 写道

黑色联想 写道

写的很不错
支持一个，前面的大牛们强烈不支持1，2条，是不是从代码的重用方面来讲的呀，呵呵！不懂！~

针对第二条，像struts能把自己模块的链接直接转发到其他模块的view层吗？我很困惑这么做不也是一种耦合吗

耦合就是一种联系，不可能做到无耦合。使用现有的框架会让我们误认为没有耦合（或者是底耦合），其实耦合都做到框架底层了

24 楼 meiowei 2009-12-31  

sunhj000java 写道

thinkinperson 写道

sunhj000java 写道

一、不要想着重用别人的链接。
做web开发的页面中可点击的按钮，链接很大，当要跳转到别人的页面的时候第一个想到的就是直接调用别人的链接。当去调用别人的链接的时候，别人很有可能需要
参数，这个时候要费心为别人准备参数。再一个方式是从别人那里获得一些我们想要的东西，想为它传递特殊的值，别人不一定就能够处理这个值。

如果每人都不学会重用别人的连接,那就会都变成了重复创轮

我觉得这不是创轮，你完全可以copy一份啊，不用创造啊，这样别人修改的时候就不会影响到自己的模块了。

如果项目是按代码量算钱，倒可以这么做。

23 楼 sunhj000java 2009-12-31  

jspine 写道

忍不住罗嗦两句：

3、业务逻辑如果能剥离，还是要封装的，项目越大，收获越大！

是封装业务呢，还是封装非业务呢

22 楼 jspine 2009-12-31  

忍不住罗嗦两句：
1、要注重团队力量。

2、注释应该都要写，不管业务简单与否，因为我们的方法是不会写成public 查询用户 （arg...）的。

3、业务逻辑如果能剥离，还是要封装的，项目越大，收获越大！

21 楼 sunhj000java 2009-12-31  

thinkinperson 写道

sunhj000java 写道

一、不要想着重用别人的链接。
做web开发的页面中可点击的按钮，链接很大，当要跳转到别人的页面的时候第一个想到的就是直接调用别人的链接。当去调用别人的链接的时候，别人很有可能需要
参数，这个时候要费心为别人准备参数。再一个方式是从别人那里获得一些我们想要的东西，想为它传递特殊的值，别人不一定就能够处理这个值。

如果每人都不学会重用别人的连接,那就会都变成了重复创轮

我觉得这不是创轮，你完全可以copy一份啊，不用创造啊，这样别人修改的时候就不会影响到自己的模块了。

20 楼 sunhj000java 2009-12-31  

黑色联想 写道

写的很不错
支持一个，前面的大牛们强烈不支持1，2条，是不是从代码的重用方面来讲的呀，呵呵！不懂！~

针对第二条，像struts能把自己模块的链接直接转发到其他模块的view层吗？我很困惑这么做不也是一种耦合吗

19 楼 黑色联想 2009-12-31  

写的很不错
支持一个，前面的大牛们强烈不支持1，2条，是不是从代码的重用方面来讲的呀，呵呵！不懂！~

18 楼 sunhj000java 2009-12-31  

jansel 写道

LZ所在的项目肯定是 每个组员都在单干 。


公共模块应该做什么应该是前期都要分析的，而不是在写代码的时候抽取才考虑的。

我的感觉是我们在边做项目边重构以前的。（重构我理解是再次去设计架构以前的程序段）

17 楼 sunhj000java 2009-12-31  

tianlang0101 写道

LZ开发经验1年以下。 。
   欢迎拍砖。

不好意思，做开发快两年了，第一次做7-8人，半年的大项目（别笑哦，对我来说这个确实是个大项目），水平比较菜。

16 楼 sunhj000java 2009-12-31  

webdb 写道

另外，对于楼主在第四点中提出“或者把这个业务分为有层次的任务，每个层次只处理有限的业务”，这个“有层次的任务”指的是什么？充血的领域模型吗？如果不是，那么业务逻辑实际上还是趋向于过程化的。

最后为楼主说一句：良好的设计，成员整体素质和成员间沟通的确很重要。但因为种种原因难以达到这些时，作为应对措施，楼主的建议还是比较中肯的。

层次这个词可能我说的不是很确切吧。

举个很俗的例子：
组装汽车，
汽车：发动机，车皮
发动机：燃烧机，活塞
车皮：车门，车窗

我说的意思，组装汽车的时候只是验证发动机是否有用啊，发动机是否合适，车皮是否和趣味啊等问题
组装发动机：复杂发动机的性能啊，推力啊等问题

每次只处理这个层面的问题，至于底层实现交给底层的方法来做

我不知道说清楚了没，就是在一个程序段只处理核心的部分

15 楼 sunhj000java 2009-12-31  

risemanjavaeye 写道

一、不要想着重用别人的链接。
     你想要什么？

二、不要共享别人的页面。
     你想要什么？

三、如果不是耦合性很高没有必要去抽取公共模块。

    完全不认同

四、不要在一个方法中写太复杂的业务逻辑。
    同意

五、不要妄想用一个接口把某个方面的业务全部处理。
    接口的定义不是想与不想的问题，是需要不需要的问题

六、尽量写注释。
    没办法才写注释，真正的好程序是不用写注释的，如果自己都觉的要写注释了，那你的程序是不是就有问题了。（反问自己）

七、尽量用通用的方法来处理问题。
   用简单，易懂的，如果说废话的话应该是用合适的

欢迎拍砖。

一、我没有说清楚，我说的是不要去共享别人需要参数的链接和内部跳转

二、当然共用引用的头文件，菜单页面，顶部页面是必须的，我打个比喻像进入一个系统的时候进行的初始化工作最好还是不要去用相关模块的页面，我觉得自己copy一份会更好些。

三、你只是说了不认同你为什么不认同呢，其实公共模块的抽取我也觉得应该是在前期把共用性比较明显的抽出来，还有就是在项目后期针对工程中确实有共性的东西做成公共的。在项目进行的工程中，我们项目中做了很多共用的东西，给人危险的感觉。也许现在是业务比较相同，但是随着项目的推进，也许就会有差异产生。

五、我这里说的接口是类中的可以公开的方法。

六、我强烈主张写注释的，即便是自己写的代码，半月之后也不能很快明白的。

七、通用不一定是简单的，而是最常见的，最容易被大家接受的。

14 楼 sunhj000java 2009-12-31  

iouhuan 写道

1、个人开发倾向。
2、没有前期准备。
3、没有和其他项目组的朋友很好的合作和沟通。

我们这个项目确实没有什么设计的，大家都是分了模块自己设计。