杂草丛生 VS 整洁有序

 

这个话题得从现在的项目经理的一个言论引出来。

按照PM的说法，“我是简单原则的支持者”，云云， 那么，让我们来看一下这些简单的原则是什么吧！
1- 尽量减少接口和类的数量；
2- 尽量不用接口；
3- package不要太深，也不要太多；
4- 远程之类全部使用EJB(2.x)；

等等

 

其实这个扯得多了，呵呵，这个话题是跟第三点有关，要开发一个功能，框架代码完成后，剩下的就是根据具体功能给出实现类了，这个应该算是常识，将所有这些实现类单独放在一个package下，既便于管理，语义上也比较好理解，但是那，这样的提议（真不算啥提议）让人家给踢回来了，呵呵，我真的不知道说啥好，
我说随着实现功能的增多，把所有的实现类放在当前一个package下面会flood当前package, 可是人家说了，就10几个类，能flood到啥程度啊，呵呵

 

某一天，突然想到一个比喻， 设想有一个花园，在我的花园里，花朵开放在修葺整齐的花坛中，草儿则轻轻爽爽的长在花坛外的草地上；而在PM的花园里，花和草则是间杂生长，至于那回事啥景象，我就不去想了，因为那跟我的理念完全是两个世界。

 

前几天还看到Javaeye上一个帖子，说不要把简单的事情搞得复杂，把所有的东西都一骨碌得print到console上就较简单了？多写几个循环就较复杂了？还将多么容易维护之类云云，nnd，你写软件真的就几个print到console就OK了？ 你或许可以将其裱称为有创意的思考，不过，你常年的修炼难道就是为了这个？说句不好听的话，这种伎俩，新手都比你玩得好， 我还从“袜子“那里听到过更又创意的那

 

你的mind就是一个花园，当你历尽千辛把它打理的井井有条，整洁有序的时候，让它荒芜也很简单，不去管它就是了。
不是写不出来那些所谓的println,而是经过了励练，那种东西已经早被抛弃了。到底是退步还是进步， 你自己或许比我更清楚！

设想一下，做codeReview的时候，你看到这样的代码会怎么做吧 ...

评论

27 楼 fujohnwang 2009-04-23  

night_stalker 写道

如果你的 boss 是 Linus 大神，他会怒骂：

一个类都不要！全删掉！

我没觉得他是神！
另外，这跟谁是我的boss也没关系。

26 楼 night_stalker 2009-04-23  

如果你的 boss 是 Linus 大神，他会怒骂：

一个类都不要！全删掉！

25 楼 fujohnwang 2009-04-23  

kakueiken 写道

就10几个类.每个类多少代码啊??
以后修改多不多啊.不多的话.
用啥框架啊.真的直接上去反而更简单明了.
杂草与鲜花.
要是全是鲜花,你不觉得会审美疲劳吗?
花园小,多点色彩吧.

中国有句老话，叫做“人无远虑，必有近忧“，你可以倒过来，看一下是否也make sense...

另，推荐一篇文章吧：
http://www.methodsandtools.com/archive/archive.php?id=85

24 楼 kakueiken 2009-04-21  

就10几个类.每个类多少代码啊??
以后修改多不多啊.不多的话.
用啥框架啊.真的直接上去反而更简单明了.
杂草与鲜花.
要是全是鲜花,你不觉得会审美疲劳吗?
花园小,多点色彩吧.

23 楼 fujohnwang 2009-04-21  

icefire 写道

justshare 写道

这个话题得从现在的项目经理的一个言论引出来。

按照PM的说法，“我是简单原则的支持者”，云云， 那么，让我们来看一下这些简单的原则是什么吧！
1- 尽量减少接口和类的数量；
2- 尽量不用接口；
3- package不要太深，也不要太多；
4- 远程之类全部使用EJB(2.x)；

等等

其实这个扯得多了，呵呵，这个话题是跟第三点有关，要开发一个功能，框架代码完成后，剩下的就是根据具体功能给出实现类了，这个应该算是常识，将所有这些实现类单独放在一个package下，既便于管理，语义上也比较好理解，但是那，[color=red]这样的提议（真不算啥提议）让人家给踢回来了，呵呵，我真的不知道说啥好[/color]

这一段，我看了几遍，还是没弄明白到底是你说的还是PM说的，可能我的理解能力有问题罢。
另，我个人觉得最好还是要分得详细点，这样语义比较清晰，万一以后会扩展呢？当然，如果你头儿坚持要那样做，那作为手下，照办就是了。

万一以后扩展，那就重构好了。。。只是万一，所以还不一定有机会给你实践重构。。

我不需要他给我实践重构的机会，呵呵，我只是说我会保持自己的花园整洁有序就好，我不可能强迫别人接受我的观点

22 楼 fujohnwang 2009-04-21  

justshare 写道

这个话题得从现在的项目经理的一个言论引出来。

按照PM的说法，“我是简单原则的支持者”，云云， 那么，让我们来看一下这些简单的原则是什么吧！
1- 尽量减少接口和类的数量；
2- 尽量不用接口；
3- package不要太深，也不要太多；
4- 远程之类全部使用EJB(2.x)；

等等

其实这个扯得多了，呵呵，这个话题是跟第三点有关，要开发一个功能，框架代码完成后，剩下的就是根据具体功能给出实现类了，这个应该算是常识，将所有这些实现类单独放在一个package下，既便于管理，语义上也比较好理解，但是那，[color=red]这样的提议（真不算啥提议）让人家给踢回来了，呵呵，我真的不知道说啥好[/color]

这一段，我看了几遍，还是没弄明白到底是你说的还是PM说的，可能我的理解能力有问题罢。
另，我个人觉得最好还是要分得详细点，这样语义比较清晰，万一以后会扩展呢？当然，如果你头儿坚持要那样做，那作为手下，照办就是了。

以上四点都是摩洛哥人说的，不是我说的

21 楼 icefire 2009-04-21  

justshare 写道

这个话题得从现在的项目经理的一个言论引出来。

按照PM的说法，“我是简单原则的支持者”，云云， 那么，让我们来看一下这些简单的原则是什么吧！
1- 尽量减少接口和类的数量；
2- 尽量不用接口；
3- package不要太深，也不要太多；
4- 远程之类全部使用EJB(2.x)；

等等

其实这个扯得多了，呵呵，这个话题是跟第三点有关，要开发一个功能，框架代码完成后，剩下的就是根据具体功能给出实现类了，这个应该算是常识，将所有这些实现类单独放在一个package下，既便于管理，语义上也比较好理解，但是那，[color=red]这样的提议（真不算啥提议）让人家给踢回来了，呵呵，我真的不知道说啥好[/color]

这一段，我看了几遍，还是没弄明白到底是你说的还是PM说的，可能我的理解能力有问题罢。
另，我个人觉得最好还是要分得详细点，这样语义比较清晰，万一以后会扩展呢？当然，如果你头儿坚持要那样做，那作为手下，照办就是了。

万一以后扩展，那就重构好了。。。只是万一，所以还不一定有机会给你实践重构。。

20 楼 justshare 2009-04-21  

这个话题得从现在的项目经理的一个言论引出来。

按照PM的说法，“我是简单原则的支持者”，云云， 那么，让我们来看一下这些简单的原则是什么吧！
1- 尽量减少接口和类的数量；
2- 尽量不用接口；
3- package不要太深，也不要太多；
4- 远程之类全部使用EJB(2.x)；

等等

其实这个扯得多了，呵呵，这个话题是跟第三点有关，要开发一个功能，框架代码完成后，剩下的就是根据具体功能给出实现类了，这个应该算是常识，将所有这些实现类单独放在一个package下，既便于管理，语义上也比较好理解，但是那，[color=red]这样的提议（真不算啥提议）让人家给踢回来了，呵呵，我真的不知道说啥好[/color]

这一段，我看了几遍，还是没弄明白到底是你说的还是PM说的，可能我的理解能力有问题罢。
另，我个人觉得最好还是要分得详细点，这样语义比较清晰，万一以后会扩展呢？当然，如果你头儿坚持要那样做，那作为手下，照办就是了。

19 楼 fujohnwang 2009-04-21  

skydream 写道

1- 尽量减少接口和类的数量；
2- 尽量不用接口；
3- package不要太深，也不要太多；
4- 远程之类全部使用EJB(2.x)；

这样做的后果，当程序逐渐增大时，尤其对于大型系统，比如开发人员>10甚至>100，维护代价直线上升，直到忍无可忍直接废弃。

俗气一点的说：这样的破事，我见识的多了，这样的代码我看着就觉得恶心

那看来你我属于同道中人，哈哈

顺便几年一下今天Javaeye被黑...
( 主要是我第一次看到 ;-) )

18 楼 skydream 2009-04-21  

1- 尽量减少接口和类的数量；
2- 尽量不用接口；
3- package不要太深，也不要太多；
4- 远程之类全部使用EJB(2.x)；

这样做的后果，当程序逐渐增大时，尤其对于大型系统，比如开发人员>10甚至>100，维护代价直线上升，直到忍无可忍直接废弃。

俗气一点的说：这样的破事，我见识的多了，这样的代码我看着就觉得恶心

17 楼 fujohnwang 2009-04-20  

logicgate 写道

在绝大多数软件公司，你都会面临到杂草丛生的局面。

对于这中情况，有个术语，叫做Big Ball of Mud

16 楼 logicgate 2009-04-20  

在绝大多数软件公司，你都会面临到杂草丛生的局面。除非你公司只有一两个人，你的系统只有几万行代码，不然想要一个整洁有序是很难的。作为组员，保证自己60%的时间不是在增加杂草。作为TL，保证系统60%不是杂草，这就够了。软件就像人生，不能追求过度完美。

15 楼 wangdi 2009-04-20  

fujohnwang 写道

wangdi 写道

fujohnwang 写道

wangdi 写道

呵呵，有时候该不该这样做，不是因为这样做对不对，而是你有没有话语权或者决定权。。。
慢慢就习惯了。。。

that's it!

another point is, if you want your garden to be clean, then u need take care of it with more caution and never give it up.

是的啊，，偶目前也处于你一样的状态，在合适的时候提一个合适重构建议是最重要的。。。

呵呵，现在都是出了问题找我，而不是在之前就堵死...

能忍就忍，不能忍就闪人………… 

14 楼 wangdi 2009-04-20  

hocus 写道

重构-改善xx 书里的建议是：
重构不要让pm知道

这个，，基本等同于找死。。。。

13 楼 fujohnwang 2009-04-20  

laiseeme 写道

知足吧  还没让你修改1万行代码的类呢

我哥们已经因为类似的体验而闪人了，呵呵，可能还是他当时看到的东西更加惨不忍睹

12 楼 fujohnwang 2009-04-20  

wangdi 写道

fujohnwang 写道

wangdi 写道

呵呵，有时候该不该这样做，不是因为这样做对不对，而是你有没有话语权或者决定权。。。
慢慢就习惯了。。。

that's it!

another point is, if you want your garden to be clean, then u need take care of it with more caution and never give it up.

是的啊，，偶目前也处于你一样的状态，在合适的时候提一个合适重构建议是最重要的。。。

呵呵，现在都是出了问题找我，而不是在之前就堵死...

11 楼 wangdi 2009-04-20  

fujohnwang 写道

wangdi 写道

呵呵，有时候该不该这样做，不是因为这样做对不对，而是你有没有话语权或者决定权。。。
慢慢就习惯了。。。

that's it!

another point is, if you want your garden to be clean, then u need take care of it with more caution and never give it up.

是的啊，，偶目前也处于你一样的状态，在合适的时候提一个合适重构建议是最重要的。。。

10 楼 laiseeme 2009-04-20  

悄悄滴进村,打枪滴不要

9 楼 hocus 2009-04-20  

重构-改善xx 书里的建议是：
重构不要让pm知道

8 楼 laiseeme 2009-04-20  

知足吧  还没让你修改1万行代码的类呢