我的重构哪里不规范？

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

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

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

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

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

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

评论

27 楼 stonecat 2007-07-06  

小步快跑，不见的就要严格按照什么标准来执行。粒度还需要自己来把握。但一定要记住OO是根本。如果数据库设计的还可以的话，工作量也不会太大。每天早上花1个小时去review自己昨天的代码，应该是一种习惯。随便说一下，我写了7年的代码，依然喜欢。写代码不丢人，因为那是劳动。

26 楼 lzmhehe 2007-06-18  

ojava 写道

我工作时间不长，之所以这样问，是因为我想在项目中提高自己，我不会也不愿意一辈子编码，但是我想使我所作的一切尽量规范!
所以，我问的问题不光是针对这一个项目，而是从项目开发角度对自己的要求！

您的随便的一句话，就可能给我很多启发，谢谢！

使用一下spring 吧
我在没有使用spring的时候 也不太在意面向interface

使用了之后就不同了，更能体会到，模式中的“对于扩展开发，对于修改封闭”

现在写一些测试性的小东西都会不自觉的使用interface （尽管不使用spring）

还有那本重构的书真的是本好书，在不知不觉中就会影响你

还有一个我个人的经验（可能不对） 不要做太多的设计，到了真正coding 的时候，会发现可能根本就不是那么回事

25 楼 ojava 2007-06-18  

我工作时间不长，之所以这样问，是因为我想在项目中提高自己，我不会也不愿意一辈子编码，但是我想使我所作的一切尽量规范!
所以，我问的问题不光是针对这一个项目，而是从项目开发角度对自己的要求！

您的随便的一句话，就可能给我很多启发，谢谢！

24 楼 sun113 2007-06-18  

我告诉你快别干了！

23 楼 dongbin 2007-06-17  

ojava 写道

无知地问一句，详细设计书拿到手，怎样进行面向接口编程？

现把详细设计书烧掉。从测试开始。

22 楼 Xiaohanne 2007-06-16  

强制我们进行Xiaohanne所说的面向接口不要面向实现的编程??
如果你们对日外包,又这么强制的话我保证你们最后会操作成,为了面向interface而面向interface.
我要改建议,请面向详细设计书编程,这样会让你过得心理舒服点
如果你实在受不了这种日子的话,面向辞呈好了

21 楼 ojava 2007-06-15  

无知地问一句，详细设计书拿到手，怎样进行面向接口编程？

20 楼 ojava 2007-06-15  

引用

抛出异常的爱     4 小时前

我只能说呸。。。。只有日本人能想的到。。。

没错，外包的，不过还得做。设计不是自己做的。

我这里就有个例外---gigix说的exception

这里一个Bean竟然有13000行，编译过程中，eclipse累得哼了声：stackOverflow...（类似的），就直接挂了。真够痛苦的！

19 楼 gigix 2007-06-15  

javastudy 写道

gigix 写道

xly_971223 写道

ojava 写道

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

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.)

18 楼 sg552 2007-06-15  

重构—— 改善现有代码的设计。 看看这本书吧。LZ

另外，多测试，常测试，保证每个重构都是成功的。

至于具体细节，就要看经验了。

17 楼 抛出异常的爱 2007-06-15  

javastudy 写道

ojava 写道

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

得在设计时就得想到拉

我只能说呸。。。。只有日本人能想的到。。。

16 楼 xly_971223 2007-06-15  

gigix 写道

xly_971223 写道

ojava 写道

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

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

3.5 lines in average

这个。。。。
有点难度 。。。

15 楼 xly_971223 2007-06-15  

诺铁 写道

因为要后续使用而把局部变量提到成员变量是最差的作法。
你需要的不是重构，是重设计。

重构跟重新设计是冲突的吗
在功能不变的情况下，我们可以通过重新设计完成重构

14 楼 gigix 2007-06-15  

xly_971223 写道

ojava 写道

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

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

3.5 lines in average

13 楼 xly_971223 2007-06-15  

ojava 写道

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

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

12 楼 gigix 2007-06-15  

诺铁 写道

因为要后续使用而把局部变量提到成员变量是最差的作法。
你需要的不是重构，是重设计。

please man ...
sigh

11 楼 诺铁 2007-06-15  

因为要后续使用而把局部变量提到成员变量是最差的作法。
你需要的不是重构，是重设计。

10 楼 gigix 2007-06-15  

ojava 写道

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

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.)

9 楼 ojava 2007-06-15  

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

8 楼 gigix 2007-06-15  

抛出异常的爱 写道

gigix 写道

抛出异常的爱 写道

不过对于拿不准的，写出来出错看不出来，找不到错的
还是要写中间测试帮助编码

nope...
if you make any mistake during refactoring and break any test,
and if you can't fix it immediately,
you should revert to previous successful step immediately.
(that's why you should check in as frequently as you can.)

那么不动老的代码。。。
写新方法，新的测试，
所有需要的方法都写完了
再一次把老的代码删去
用新的代码顶上？

please man...
what is "refactoring"?
answer: to improve the internal structure of code, WITHOUT CHANGING ITS EXTERNAL BEHAVIOR
when you refactoring, you move forward by SMALL STEPS. you remove the bad smells little by little, and always keep all tests passing.