糟糕的代码设计真的让人很心烦..

刚进公司不到一个月, 现在正在进行一个项目开发,项目里使用 Hibernate2 + Struts1.2,正常情况下这是一个相当好的组

 

合,但是现在由于DAO层代码几乎全由MyExclipse 生成,不知是否由于MyExclipse 版本过低,生成的代码中大量使用了继

 

承,而且最主要的,项目管理人几乎没有进行重写的想法,他们的意思是:这些我们都用了很久,都很熟悉了;但是项目项目进度的

 

发展,这些问题也越来越突出,由于采用MyEclipse 自动生成的代码,在调用DAO对象前要先执行初始化,如:

try {
	_BaseRootDAO.initialize();
	dao = XXXDAO.getInstance();
} catch (HibernateException e) {
	e.printStackTrace();
}

 

然后才能调用,我想对它做个封装,可是对它这个初始化实在束手无测,现在我只能简单的把这些业务单独做个类来封闭,让它

 

不与WEB层混淆在一起,但是这样并不能彻底解决问题,我封闭的这些类中重复的代码实在太多,我也试过对这些代码进行重

 

构,可是由于现在项目也经进行到一半了,项目开发由多个人一同进行,我如果更改了原始代码结构,必然会引起别人代码不能

 

正常运行,可是每次自己读到这些代码,特别是自己还要参与到其中,真的很心烦.....

 

我应该如何做呢,难道企业里开发都这样吗? 大家能否给点建议..

评论

95 楼 zzfeng 2008-08-25  

非常同意gigix的方法抽取思想。

无论代码质量多么高，一个方法中有过多的功能块，都会显得很混乱，
严重影响阅读性，而且也很容易搞乱编写者的思维顺序，随之而来的可能会出现
很多不易察觉的错误。
方法就应该是功能单一性的。

了解一个方法是干吗的总比了解一个从X行到Y行的代码块是干嘛的更容易、更舒服吧？

方法抽取影响执行效率？我只能说你思维很细密，但是这点影响九牛一毛都不到吧。

当发现一个方法在做过多的事情的时候，就应该考虑方法抽取；

94 楼 gigix 2008-08-23  

seen 写道

哈哈 别搞笑了 你敢拍着胸脯说 你去那家设备提供商的时候 跟别人pair的内容是radio或者core network的内容？
无非是些边缘的人力管理或者财务报表吧？
再说了 西门子也敢叫顶级？呵呵 全球搞贿赂被抓 然后就拆分被贱卖的事主

有些信息其实很多人知道，只是我出于显而易见的原因不便明说而已。你去2008年敏捷中国大会的网站上看一看，这个客户是谁应该不难猜。这种自作聪明的笑话，没什么好笑的。
至于我做了些什么，我还是那句话，既然你没兴趣知道，我也没兴趣非得告诉你不可。反正你又不需要我帮助，我又不用帮助你。你要说我们做的都是在你看来没什么技术含量的东西，那就是好了，你可以继续自鸣得意。少知道一些信息是你的损失，又不是我的损失。

93 楼 seen 2008-08-23  

gigix 写道

seen 写道

gigix 写道

对于电信级高性能领域的最佳实践，如果楼上的全都是做电信级高性能程序的，那我就不参与讨论了，没这方面经验。

gigix 写道

我在一家全球领先的电信设备提供商做咨询的时候...

这就是区别
我同样是说我有一些经验，在一些商用软件项目中得到了验证
有些人说，虽然跟我们不是同一个领域的，但是我们还是要学习借鉴一下，毕竟软件都是有相通的，有一些特殊性不影响我们在80%相通的地方做改进
有些人说，你根本不知道我们这个领域的事情，你那些经验都是扯淡，拿来肯定用不了
对后一种人，我就承认，我确实不知道。承认这种显而易见的事实我又不损失什么。既然你这么在乎领域经验那我也不尝试帮助你，反正你也不需要我帮助，我也不损失什么。
不过还是会偷偷的想，既然别人都不如你知道你这个领域该怎么做，那你干嘛还抱怨有问题呢？你干嘛还跟我交流呢？就是想证明你比我强比我懂得多是吗？那没问题，我承认你懂得多好了，把你捧上天我也不会有什么损失。
不针对你，只是说我看到的情况而已。

哈哈 别搞笑了 你敢拍着胸脯说 你去那家设备提供商的时候 跟别人pair的内容是radio或者core network的内容？
无非是些边缘的人力管理或者财务报表吧？
再说了 西门子也敢叫顶级？呵呵 全球搞贿赂被抓 然后就拆分被贱卖的事主

92 楼 tedeyang 2008-08-23  

《重构》这本书看看吧，
这个帖子就没必要存在了

91 楼 gigix 2008-08-23  

seen 写道

gigix 写道

对于电信级高性能领域的最佳实践，如果楼上的全都是做电信级高性能程序的，那我就不参与讨论了，没这方面经验。

gigix 写道

我在一家全球领先的电信设备提供商做咨询的时候...

这就是区别
我同样是说我有一些经验，在一些商用软件项目中得到了验证
有些人说，虽然跟我们不是同一个领域的，但是我们还是要学习借鉴一下，毕竟软件都是有相通的，有一些特殊性不影响我们在80%相通的地方做改进
有些人说，你根本不知道我们这个领域的事情，你那些经验都是扯淡，拿来肯定用不了
对后一种人，我就承认，我确实不知道。承认这种显而易见的事实我又不损失什么。既然你这么在乎领域经验那我也不尝试帮助你，反正你也不需要我帮助，我也不损失什么。
不过还是会偷偷的想，既然别人都不如你知道你这个领域该怎么做，那你干嘛还抱怨有问题呢？你干嘛还跟我交流呢？就是想证明你比我强比我懂得多是吗？那没问题，我承认你懂得多好了，把你捧上天我也不会有什么损失。
不针对你，只是说我看到的情况而已。

90 楼 seen 2008-08-22  

gigix 写道

对于电信级高性能领域的最佳实践，如果楼上的全都是做电信级高性能程序的，那我就不参与讨论了，没这方面经验。

gigix 写道

我在一家全球领先的电信设备提供商做咨询的时候...

89 楼 gigix 2008-08-22  

seen 写道

我相信你的理念和做法，在你的领域内，会带来工作效率的提升。
但是我想提醒你的是，即使都是写代码，也有不同的领域，你的准则不是处处通行的。

永远正确的废话。
那么好吧，既然你喜欢，我很乐意给我的观点加上限制条件。
我所了解的最佳实践主要适用于商用软件开发。对于电信级高性能领域的最佳实践，本人欠奉。
如果楼上的全都是做电信级高性能程序的，那我就不参与讨论了，没这方面经验。

88 楼 gigix 2008-08-22  

seen 写道

对这个解释，我的理解是，consultant的assumption是把对方当无脑儿。

六个西格玛，丰田制造，所有被证明有效的流程，第一步都是严格规范质量标准，每个生产环节控制缺陷，全流程质量保障。一切的持续改进都建立在严格保障的基础上。基本的质量保障都做不到就奢谈什么编程的哲学，那是浮沙上建高台。你说我把别人当无脑儿也好怎么也好，至少我做对他们有用的事，而不是说一些对他们没有帮助的漂亮话。

87 楼 seen 2008-08-22  

gigix 写道

gurudk 写道

1） 你所说的只是达到高代码质量的一种手段，仅仅是方式之一而已。比如从上海到北京的路有很多，你指出了一条路，但是可能还有更好的，更合适的路。
2） 就像你说的那样，对新人，这种办法可能可行。对稍微有些经验的，恐怕就不奏效了。他们脑子活了一点，不是满足“只能这样”的一种方式，所以应该灌输的是哲学，殊途同归，达到目标就可以了。
3） 做任何事都有目标，你们咨询的目标是帮助提高代码质量，而我认为可理解性是代码质量的最主要的特征，从这个角度，我们是不冲突的，一致的，你走了一条路（不是唯一的一条路），别人走了另外一条路而已。我们做的是要让程序员知道，我们的目标是什么，我们为什么要做这些，哪些方式满足要求。
4） 小方法的最坏情况是不满足逻辑上的完整性，过于分散。长代码分段加注释的最坏情况是，代码段过长，一眼看上去无法理解。事实上，我相信这两种都是我们所反对的，所谓过犹不及。

这个也没什么好讨论的，你自己去给几个这样的团队做一做教练你就知道，讲哲学，行不通，教练一走了这些实践就要走样。
所谓全程质量保证，说白了就是画好框框，这件事情就这样做那件事情就那样做，大家不要讨论不要琢磨，就是这样做。只有这样你才能保证质量不走样。讲哲学，提高团队素质，让大家都想通，都上层次，那当然是好事，如果能做到的话。
这种事情你作为一个team leader和作为一个consultant你思考的角度不能一样。一个别人的团队有这种问题，你不知道这个团队里有什么人，你不知道他们是什么状况。你能做的就是告诉他一条可行的路，只要你走就一定走到什么地方。讲哲学，最后你会得到一个最坏的结果。

对这个解释，我的理解是，consultant的assumption是把对方当无脑儿。

86 楼 seen 2008-08-22  

gigix 写道

seen 写道

在某些场景下 过多的方法调用会导致性能下降

绝大多数情况下性能问题发生在IO边际
数据库和网络延迟
因为编程语言的内存运算导致的性能问题，不到千分之一

seen 写道

注释的作用在某些时候是不可替代的
譬如在修改某个bug的时候，程序员发现必须让某个线程等待1毫秒，但是调用usleep在这里又因为性能和精确度或其它的问题不能使用，于是该程序员写了个循环。
如果这里不写句注释，以后的读者看到了会猜测这是为了延时，但是如果有句注释就可以省却一番猜测和验证。
另外一个选择是写个方法叫delay_one_ms，然后调用此方法。但这对我来说这无异于脱裤子放屁，同时，这也会带来额外的性能损失。

我不知道为什么不应该这样做
还是这句话，你有工夫写一句冗余信息的注释，为什么不把这个事情变成一个方法？
当然这个方法名显然应该叫delay(ms)或者sleep(ms)，因为如果这个方法只能等待1毫秒不能等待2毫秒的话那是很蠢的想法
而且一次方法调用的时间开销是微秒级的
你要做的事情是等待1毫秒，你却在讨论一个微秒级的性能损失，我觉得这才叫没话找话
而且线程之间的同步不能靠等待，得靠消息
这东西本身就不可靠，不是说你能精确等待1毫秒他就会变得可靠的

seen 写道

我想说的是，美感是不可或缺的，但是过犹不及这个道理的优先级更高。
稍稍把眼光放远一点，就会发现很多跟你的认识相悖的事实存在。

事实是我从来没有看到过因为把代码写得更漂亮而遭受损失的程序员，满大街都是被烂代码郁闷到的程序员
过犹不及？huh？我怎么就没见过任何一家中国的软件公司有把代码写得“过于漂亮”的呢？
我孤陋，你给我举个例子吧。
我在一家全球领先的电信设备提供商做咨询的时候，这种话听得耳朵里都起茧子
一边被烂代码郁闷得要死，一边说“过犹不及”，“你们这样的要求不切实际”。那怎么办呢，你都知道该怎么做了，你都知道怎么做才切合实际了，那为什么你还有那么一大堆烂代码砸在手上？
结果我每天跟他们的程序员pair，一个月，然后他们发现原来他们也能做到，他们做到了也有好处。
还是我早就说的，这些事情既然我这么说，我肯定是认真想过做过的。说着“过犹不及”这类永远不会错的废话的人们，你在项目里这样做过吗？你坚持过每个方法不超过5行（或者放松点，10行）吗？你坚持过任何两行以上的代码不重复吗？你坚持过任何超过一行或者两个条件的代码必须有测试吗？如果你没有一段时间坚持过这些最严格的要求，你怎么会知道到底哪里才算是“过”？

楼上某人说你钻牛角尖，可我觉得有时候也许我比你更钻牛角尖。
微秒级的损失和误差对你来说是边界情况，或者是可以忽略的情况，可在我的日常工作中，这是必须考虑在内的。10us和30us是完全不同的。
数据库？那东西太慢了，即使是内存数据库都不够快。我得把存储和搜索搬到内核里去。
IO是重点考察对象，因为即使是我做的玩具，在普通台式机上，都支持1G bps的流量，其中包括L3的重组。当然，这也是在内核里达到的。
你眼中的美，你做的坚持，是代码_看_上去是否美，一个方法是否超过5行。
我坚持的则是更大的并发，更小的性能损失。
我相信你的理念和做法，在你的领域内，会带来工作效率的提升。
但是我想提醒你的是，即使都是写代码，也有不同的领域，你的准则不是处处通行的。
举个例子，你可以统计一下，哪怕是30年前的最最简单的unix，有多少比例的方法是少于5行的？

85 楼 gigix 2008-08-22  

gurudk 写道

1） 你所说的只是达到高代码质量的一种手段，仅仅是方式之一而已。比如从上海到北京的路有很多，你指出了一条路，但是可能还有更好的，更合适的路。
2） 就像你说的那样，对新人，这种办法可能可行。对稍微有些经验的，恐怕就不奏效了。他们脑子活了一点，不是满足“只能这样”的一种方式，所以应该灌输的是哲学，殊途同归，达到目标就可以了。
3） 做任何事都有目标，你们咨询的目标是帮助提高代码质量，而我认为可理解性是代码质量的最主要的特征，从这个角度，我们是不冲突的，一致的，你走了一条路（不是唯一的一条路），别人走了另外一条路而已。我们做的是要让程序员知道，我们的目标是什么，我们为什么要做这些，哪些方式满足要求。
4） 小方法的最坏情况是不满足逻辑上的完整性，过于分散。长代码分段加注释的最坏情况是，代码段过长，一眼看上去无法理解。事实上，我相信这两种都是我们所反对的，所谓过犹不及。

这个也没什么好讨论的，你自己去给几个这样的团队做一做教练你就知道，讲哲学，行不通，教练一走了这些实践就要走样。
所谓全程质量保证，说白了就是画好框框，这件事情就这样做那件事情就那样做，大家不要讨论不要琢磨，就是这样做。只有这样你才能保证质量不走样。讲哲学，提高团队素质，让大家都想通，都上层次，那当然是好事，如果能做到的话。
这种事情你作为一个team leader和作为一个consultant你思考的角度不能一样。一个别人的团队有这种问题，你不知道这个团队里有什么人，你不知道他们是什么状况。你能做的就是告诉他一条可行的路，只要你走就一定走到什么地方。讲哲学，最后你会得到一个最坏的结果。

84 楼 gurudk 2008-08-22  

引用

你坚持过每个方法不超过5行（或者放松点，10行）吗？你坚持过任何两行以上的代码不重复吗？你坚持过任何超过一行或者两个条件的代码必须有测试吗？如果你没有一段时间坚持过这些最严格的要求，你怎么会知道到底哪里才算是“过”？

to giggx:你说你坚持这些的目标是为了什么？高标准是挺好，但是成本也高。我只是觉得你有点偏执，是不是你觉得这样咨询才能给人以权威，才能严要求，即使做不到全部，也能较大的提高代码质量。

我的目标和哲学是坚持可理解性，在此原则上，可以不管那些生硬的原则，事实上，这也是最容易让程序员接受的。
代码只要可理解，优化，重构，维护都非常的方便，让你拥有自由。总之，不必过于教条，尽管如此教条也是通向代码可理解性的一种方式。 你的极致小方法哲学只代表了你的世界观而已。

纯属讨论，言语冒犯之处，尽请谅解。

83 楼 gurudk 2008-08-22  

gigix 写道

gurudk 写道

2） 如果抽取出来，不能复用，我觉得没有任何意义，还得费挺大劲想方法名，随便对一个方法命名是可耻的。
3） 一屏幕我都能看到，分段注释又可以帮助理解思路，注释是自然语言，简短的自然语言比一个再好的方法名都好。
4） 如果有复用，我还是赞成重构成方法。
5） 我感觉你可能考虑问题太有层次了，我的哲学是中庸而实用，可理解性好就行。

把注释直接变成方法名
短方法不是为了复用，而是为了清晰思路。复用是一个顺便得到的好处。
一个描述太多细节的方法是没有美感的。我前面就说了，人在同一时间能思考的元素不超过7个。让阅读者第一时间了解这个方法在做什么，这样的方法才是有美感的。
而且反正你也花一分钟来写注释了，那为什么不把代码本身变得能够一眼看懂？
注释是冗余的信息。将来修改代码的同时还要修改注释。信息冗余是没有美感的。
我承认这些很大程度上是审美。不过熵是强大的，有时候没有一点对美感的偏执你会很难和熵做斗争。
这就是为什么那么多项目最终腐化到不能维护的原因。

我相信我们这两种做法，可理解性是在同一个级别的，而你是执着于小方法，而我觉得合理的注释加上不大的方法。你力求做到完美的一致性，而我是实用主义，满足可理解性。事实上，那种较长的，内部分代码段注释的方法也不是很多的。坚持的哲学不一样。

82 楼 gigix 2008-08-22  

seen 写道

在某些场景下 过多的方法调用会导致性能下降

绝大多数情况下性能问题发生在IO边际
数据库和网络延迟
因为编程语言的内存运算导致的性能问题，不到千分之一

seen 写道

注释的作用在某些时候是不可替代的
譬如在修改某个bug的时候，程序员发现必须让某个线程等待1毫秒，但是调用usleep在这里又因为性能和精确度或其它的问题不能使用，于是该程序员写了个循环。
如果这里不写句注释，以后的读者看到了会猜测这是为了延时，但是如果有句注释就可以省却一番猜测和验证。
另外一个选择是写个方法叫delay_one_ms，然后调用此方法。但这对我来说这无异于脱裤子放屁，同时，这也会带来额外的性能损失。

我不知道为什么不应该这样做
还是这句话，你有工夫写一句冗余信息的注释，为什么不把这个事情变成一个方法？
当然这个方法名显然应该叫delay(ms)或者sleep(ms)，因为如果这个方法只能等待1毫秒不能等待2毫秒的话那是很蠢的想法
而且一次方法调用的时间开销是微秒级的
你要做的事情是等待1毫秒，你却在讨论一个微秒级的性能损失，我觉得这才叫没话找话
而且线程之间的同步不能靠等待，得靠消息
这东西本身就不可靠，不是说你能精确等待1毫秒他就会变得可靠的

seen 写道

我想说的是，美感是不可或缺的，但是过犹不及这个道理的优先级更高。
稍稍把眼光放远一点，就会发现很多跟你的认识相悖的事实存在。

事实是我从来没有看到过因为把代码写得更漂亮而遭受损失的程序员，满大街都是被烂代码郁闷到的程序员
过犹不及？huh？我怎么就没见过任何一家中国的软件公司有把代码写得“过于漂亮”的呢？
我孤陋，你给我举个例子吧。
我在一家全球领先的电信设备提供商做咨询的时候，这种话听得耳朵里都起茧子
一边被烂代码郁闷得要死，一边说“过犹不及”，“你们这样的要求不切实际”。那怎么办呢，你都知道该怎么做了，你都知道怎么做才切合实际了，那为什么你还有那么一大堆烂代码砸在手上？
结果我每天跟他们的程序员pair，一个月，然后他们发现原来他们也能做到，他们做到了也有好处。
还是我早就说的，这些事情既然我这么说，我肯定是认真想过做过的。说着“过犹不及”这类永远不会错的废话的人们，你在项目里这样做过吗？你坚持过每个方法不超过5行（或者放松点，10行）吗？你坚持过任何两行以上的代码不重复吗？你坚持过任何超过一行或者两个条件的代码必须有测试吗？如果你没有一段时间坚持过这些最严格的要求，你怎么会知道到底哪里才算是“过”？

81 楼 seen 2008-08-22  

gigix 写道

gurudk 写道

2） 如果抽取出来，不能复用，我觉得没有任何意义，还得费挺大劲想方法名，随便对一个方法命名是可耻的。
3） 一屏幕我都能看到，分段注释又可以帮助理解思路，注释是自然语言，简短的自然语言比一个再好的方法名都好。
4） 如果有复用，我还是赞成重构成方法。
5） 我感觉你可能考虑问题太有层次了，我的哲学是中庸而实用，可理解性好就行。

把注释直接变成方法名
短方法不是为了复用，而是为了清晰思路。复用是一个顺便得到的好处。
一个描述太多细节的方法是没有美感的。我前面就说了，人在同一时间能思考的元素不超过7个。让阅读者第一时间了解这个方法在做什么，这样的方法才是有美感的。
而且反正你也花一分钟来写注释了，那为什么不把代码本身变得能够一眼看懂？
注释是冗余的信息。将来修改代码的同时还要修改注释。信息冗余是没有美感的。
我承认这些很大程度上是审美。不过熵是强大的，有时候没有一点对美感的偏执你会很难和熵做斗争。
这就是为什么那么多项目最终腐化到不能维护的原因。

平均5行一个方法可能仅限于基于ruby的项目
在某些场景下 过多的方法调用会导致性能下降

注释的作用在某些时候是不可替代的
譬如在修改某个bug的时候，程序员发现必须让某个线程等待1毫秒，但是调用usleep在这里又因为性能和精确度或其它的问题不能使用，于是该程序员写了个循环。
如果这里不写句注释，以后的读者看到了会猜测这是为了延时，但是如果有句注释就可以省却一番猜测和验证。
另外一个选择是写个方法叫delay_one_ms，然后调用此方法。但这对我来说这无异于脱裤子放屁，同时，这也会带来额外的性能损失。

而且在现实中，很多方法是没法写得简单到一眼被看透的
譬如初始化一个skbuf，必然会牵扯到好几层的header的填充，附加很多checksum，异常处理等等辅助工作。
读者可以预测到有这些工作要做，但是只有跟到每一行，才能逐渐展开整个过程。

我想说的是，美感是不可或缺的，但是过犹不及这个道理的优先级更高。
稍稍把眼光放远一点，就会发现很多跟你的认识相悖的事实存在。

80 楼 gigix 2008-08-21  

gurudk 写道

2） 如果抽取出来，不能复用，我觉得没有任何意义，还得费挺大劲想方法名，随便对一个方法命名是可耻的。
3） 一屏幕我都能看到，分段注释又可以帮助理解思路，注释是自然语言，简短的自然语言比一个再好的方法名都好。
4） 如果有复用，我还是赞成重构成方法。
5） 我感觉你可能考虑问题太有层次了，我的哲学是中庸而实用，可理解性好就行。

把注释直接变成方法名
短方法不是为了复用，而是为了清晰思路。复用是一个顺便得到的好处。
一个描述太多细节的方法是没有美感的。我前面就说了，人在同一时间能思考的元素不超过7个。让阅读者第一时间了解这个方法在做什么，这样的方法才是有美感的。
而且反正你也花一分钟来写注释了，那为什么不把代码本身变得能够一眼看懂？
注释是冗余的信息。将来修改代码的同时还要修改注释。信息冗余是没有美感的。
我承认这些很大程度上是审美。不过熵是强大的，有时候没有一点对美感的偏执你会很难和熵做斗争。
这就是为什么那么多项目最终腐化到不能维护的原因。

79 楼 gurudk 2008-08-21  

土匪一份子 写道

刚换了家公司2个月  现在做的项目是个四期的项目   听项目经理说这个系统参与人次量估计有80人左右。。。   这家公司以前没有什么规范   好象就是能把业务实现了就完事了。。。  刚接手时真是晕了  里面的代码五花八门  想重构  根本没门。。。  你重构的时间  老总不如直接让你做个新项目。。。   打算呆到年底就闪人。。。  再做下去我都怕自己会被外界淘汰。。

已经成熟的产品，重构代价太大，我觉得没必要重构，推到重来更不值得。我们公司也有这样的产品，每次都有重做的冲动，每次都舍不得。 已经正常履行功能，稳定运行的代码，就不要碰了，不要为了重构而重构。

78 楼 gurudk 2008-08-21  

ccxw1983 写道

有很长历史的项目都会出现这些代码质量问题的，像我们的drp项目，以前只有几个人，干了3年，里面堆砌的代码确实厉害，毕竟他们是php转过来的，能够实现已经是非常让他们骄傲的事情了，况且需求收集不成熟，经常变动。
我们项目的性能优化高手，他的重构能力应该不错，但是我刚做出来的一个东西，他去修改，添加新功能也只是力求加上自己的实现，根本没有把自己加的实现逻辑放到新的方法里面去，为什么？很好理解，这样能够在最少的时间内实现领导需要的东西，能够让自己利益最大化。我从他那还学到一点东西，当你接手旧代码添加新功能的时候，不要破坏以前的代码的逻辑，新功能通过补丁的路径执行得以实现。这样，即使对以前的代码不懂，也不会因为 你加了新功能就导致以前的东西出bug。

项目是否需要重构取决于价值，有限的时间，没有必要为次要因素而增加成败风险，况且现有的可能只是临时用用。

能够满足“开闭原则”，水平已经很高了，值得学习！

77 楼 gurudk 2008-08-21  

gigix 写道

gurudk 写道

方法如果不可避免的大了（为了维护逻辑上的完整性），那一定要将方法中的代码段进行分段，每段注释说明意图。

我就没见过一个例子，在这种情况下有充分理由不把注释变成新方法名字的
有写注释的工夫，抽取一个方法出来好不好？同样的信息为什么要写两次？
而且在我见过的所有代码中，凡是这种情况，无一例外的是考虑问题没有层次，眉毛胡子一把抓
说到底不是代码问题，而是解决问题的思路问题

用许三多的话，没有意义。详细解释一下：

1） 首先不可能是很长的方法，比如超过50行，这只是经验数字，任何时候都有例外，但不影响讨论基本原则。
2） 如果抽取出来，不能复用，我觉得没有任何意义，还得费挺大劲想方法名，随便对一个方法命名是可耻的。
3） 一屏幕我都能看到，分段注释又可以帮助理解思路，注释是自然语言，简短的自然语言比一个再好的方法名都好。
4） 如果有复用，我还是赞成重构成方法。
5） 我感觉你可能考虑问题太有层次了，我的哲学是中庸而实用，可理解性好就行。

场景不同，习惯不同，看法也就不同，正常，呵呵！

76 楼 gurudk 2008-08-21  

<div class="quote_title">lg_techie 写道</div><div class="quote_div"><div class="quote_title">liuqiang 写道</div>
<div class="quote_div">
<div class="quote_title">wcleye 写道</div>
<div class="quote_div">
<div class="quote_title">liuqiang 写道</div>
<div class="quote_div">项目经理都不急，你急什么？ <br />这个现象很普遍啊，不要太在意，建议继续撞钟，机会来了跳到开发规范点的公司</div>
<br /><br />当一天和尚撞一天钟吗?如果我去了下个公司还是这样呢?然后继续跳吗?</div>
<p>很多事情是你一个人改变不了的，是你去适应公司，而不是公司适应你，下次找工作时最好调研一下该公司的各个方面，比如说印客网就不会有你说的那些情况，因为人家的人才梯队做的比较好。当然如果下次你还是那么随意找个工作的话，撞不撞钟只有听天由命了&hellip;&hellip;</p>
<p>&nbsp;</p>
</div>
<p>对，个人的力量太渺小了。很多公司管理不规范，代码一团糟，很多情况下是没有办法的。</p></div><br/>

很多公司当领导的不懂技术，也缺乏胸怀和眼光，急功近利，固执己见，有时凭借手中的权利，去执行只有他自己认为正确的事，突然有一天想到一种方法，兴冲冲的去实践，却不知这是别人早就知道的方法，而他只知其中一二就自我满足，鼠目寸光，这就是中国软件的悲哀。有一天，你们当领导了，一定不要这样，否则，遭殃的是更多的人。