对项目开发中的一点感悟

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

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

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

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

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

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

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

评论

13 楼 jansel 2009-12-31  

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


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

12 楼 webdb 2009-12-30  

risemanjavaeye 写道

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

    完全不认同


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

欢迎拍砖。

第三点我觉得应该具体问题具体分析，不能一棒子打死；第六点我同意楼主的观点，另外我觉得写注释的主要目的不是为了自己，而是为了方便项目内部交流甚至方便客户，另外也为了将来维护的方便。

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

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

11 楼 tianlang0101 2009-12-30  

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

10 楼 aoliwen521 2009-12-30  

我也只看不说话。因为水平不到位，不敢乱发言。

9 楼 binlaniua 2009-12-30  

我只看看 我不说话

8 楼 risemanjavaeye 2009-12-30  

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

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

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

    完全不认同

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

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

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

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

欢迎拍砖。

7 楼 iouhuan 2009-12-30  

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

6 楼 wslfh2008 2009-12-30  

kj23 写道

1 2 3的问题明显是缺乏管理，缺乏规划导致的，这就是错误假设得出错误结论

对，其实项目初期构建时很重要，整合基础的模块和基础的功能很重要，还要抽取一些基础的方法和页面之类。

5 楼 kj23 2009-12-30  

1 2 3的问题明显是缺乏管理，缺乏规划导致的，这就是错误假设得出错误结论

4 楼 xiaoyuqi00 2009-12-30  

1,2,3都不认同，

只能说明你接口和页面没有做好，

做好的会共享是不存在任何问题的

3 楼 魔力猫咪 2009-12-30  

76052186 写道

1,2,3都不能苟同

如果1.2这两条遇到问题，那么就可以说项目根本没有一个整体的规划设计，大家都是自行其事，谁也不知道谁写了什么。
7应该改成尽量用简单方法处理。

2 楼 76052186 2009-12-30  

1,2,3都不能苟同

1 楼 Vimesly 2009-12-30  

你说的值得我学习
谢谢！