我的重构哪里不规范？

2007-06-15

关键字: 重构

在项目中，由于没有经过大脑思考，结果产生了流水账形式的代码。

流水账代码：就是根据是详细设计书把整个业务的流程顺序完成到一个类的一个方法中，
而没有根据功能划分成若干个小的方法。

这种流水账式的代码非常不容易测试，因为详细设计中已经将设计细化到对字符串如何操作了，
所以从这样的设计书的高度看业务，简直就是乱七八糟！

所幸，还有重构这个工具，就重构，发现很多的局部变量，因为在多处改变值，而且后续还要使用，
所以只能把这种变量，提到类变量的高度，好多啊。

这样一来，
1。如果要用junit测试，还需要再给相应的提出来的变量加上set,get方法。
2。因为重构出来的方法都是private的，所以测试的时候还要用反射的方法。

上面这两种情况可以避免吗？这是一个问题。
还有一个对自己的警告：小心费力不讨好！

08:40
浏览 (9808)
评论 (47)
进入论坛
相关推荐

topcloud 2008-05-24

设计不良埋下的祸端，要在后期代码重构中解决。开发者的悲哀！

szlyf 2008-05-24

ojava 写道

所幸，还有重构这个工具，就重构，发现很多的局部变量，因为在多处改变值，而且后续还要使用，
所以只能把这种变量，提到类变量的高度，好多啊。

重构不仅仅是简单的将一个方法分成几个方法，要考虑接口、类的重新设计以达到代码间耦合度的最低。

wangx1949 2007-07-31

拥有short methods的对象会活得比较好,比较长.不熟悉面向对象技术的人,常常觉得对象程序中只有无穷无尽的delegation,根本没有进行任何计算.和此类程序共同生活数年之后,你才会知道,这些小小函数有多大价值.[间接层]所能带来的全部利益--解释能力,共享能力,选择能力--都是由小型函数支持的.

----

出自<重构-改善即有代码的设计>,我想这段话可解释gigix为什么要强调函数的lines要尽可能少.

----

另外谁解释一下[间接层]?

geszJava 2007-07-30

同意楼上的,平均多少行要看情况.不过有没有这个习惯就是另外一回事了.

xinbo.tang 2007-07-30

gigix 写道

我觉得，重点在于
一个方法应该做并且只做一件事
所以，如果一个方法纯粹是delegate另一个方法，那是不好的，因为它什么都没做
但如果方法长度普遍地超过10行，也很可能是有问题的，因为根据我的经验，需要用10句话才能说清楚的事情并不是太多的

强烈支持噢，
说平均10行，只是给你一个准则作为参考，当你的方法超过10行的时候，
你就自己问自己一下，我这个方法粒度最小了麼？
在很多情况下立马就能发现可以改进的地方...

人家ruby4行，java 罗嗦点，自己控制一下，
每当超过10-15行就去多思考一下，并不为过，
又不是强迫你只能写10行，只是强迫自己养成一个良好的习惯而已。

小天蝎 2007-07-26

gigix 写道

xly_971223 写道

ojava 写道

公司新加代码规范条目：所定义的方法尽量不要超过100行。
某一方面来说，可以避免这种流水账式的代码吧！
并且强制我们进行Xiaohanne所说的面向接口不要面向实现的编程。

100行？太长了吧
我一般情况保持在20行左右

3.5 lines in average

理想状态吧很多公司都不搞敏捷、TDD之类的东东
你叫他3.5 难啊

hlxiong 2007-07-23

我觉得对外暴露的主体方法在10行以内大部分都是可以做到的，但是处理具体业务的私有方法可能不太好控制，应该是由业务来决定规模。

Godlikeme 2007-07-20

先是有剑，才能无剑。
这是一种升华，基本的招式还不了解，怎么可能升华。
重构在一些具体问题上，肯定有不同理解，是正常的。
顺其自然感觉是一种主观无用论。

jjx 2007-07-20

重构是水到渠成的事情

你到一定的阶段,就自然知道代码该怎么重构,所谓手中无剑,心里有剑,哪里有那么多规则

fanth 2007-07-18

平均10行倒也没有什么，如果每个方法都10行以内可能有些牵强了。

yeshucheng 2007-07-16

Godlikeme 写道

同意尽量避免long method，但重构方法到10行这个级别，我一直认为martin在这个问题上有点学究。
个人认为重构是对已有设计、实现的一个优化过程，让类职责更清晰，消除重复、冗余代码、使层次明确、逻辑清晰、增进可理解性、可测试性、可维护性、可扩展性。
写代码很多时候实现了事，没必要那么严格的照搬martin的原则。理论性可以帮助实践，在实践中也要灵活运用，别教条。优化是无止境的过程，关键要权衡，“是否值得”。当发现为了优化而优化，或者说为了重构而重构就有些过了，该打住了。

简单的就是最好的，有必要再重构。

这个话我很赞同！重构的目的就是为了使代码更加简洁而且易用，但是一味的寻求简单，我到觉得没有这个必要，毕竟重构不是为了最短化

Godlikeme 2007-07-16

yeshucheng 2007-07-14

gigix 写道

xly_971223 写道

方法越短越有利于复用
我一直把方法的长短作为判断一个coder水平的标准

能否举个实例呢：）JAVA方面的，大家也好学习下

gigix 2007-07-13

xly_971223 写道

方法越短越有利于复用
我一直把方法的长短作为判断一个coder水平的标准

xly_971223 2007-07-13

方法越短越有利于复用
我一直把方法的长短作为判断一个coder水平的标准

gigix 2007-07-13

songail 写道

gigix 写道

ojava 写道

TDD is THE solution of your problem:
you just can't write a test for a hundred-lines-long method.
Actually, in normal cases,
methods should not be longer than 10 lines.
(I'd say 5 lines indeed.)

真的有必要达到这个程度？

我只是告诉你，我这样做了，感觉不错
真的有必要吗？
真的有必要把身体锻炼得那么好吗？只要不生病就行了吧。
真的有必要把自己打扮得那么精神吗？只要衣服不太邋遢就行了吧。
真的有必要赚那么多钱吗？够吃饭就行了吧。
就是这样。

songail 2007-07-13

gigix 写道

ojava 写道

TDD is THE solution of your problem:
you just can't write a test for a hundred-lines-long method.
Actually, in normal cases,
methods should not be longer than 10 lines.
(I'd say 5 lines indeed.)

真的有必要达到这个程度？

yeshucheng 2007-07-11

LZ可是说JAVA代码哦？

gigix 2007-07-11

yeshucheng 写道

这个总觉得很神话，呵呵。可能最后程序员会为了重构而重构

又一个例证：FoR(Finance on Rails，http://for.thoughtworkers.org)
源代码在Google code上：http://code.google.com/p/finance-on-rails/
到目前为止，平均每个方法4行代码。请注意，这是把方法开头的“def”和结尾的“end”两行也算在内的。

yeshucheng 2007-07-11

gigix 写道

javastudy 写道

gigix 写道

xly_971223 写道

ojava 写道

100行？太长了吧
我一般情况保持在20行左右

3.5 lines in average

有点太短了吧

that's our stat in previous project
you can try to show me an example: why do you need a method longer than 5 lines?
(some complex algorithm implementations are exceptions.)

这个总觉得很神话，呵呵。可能最后程序员会为了重构而重构