重构-我们在尝试

Refactory， 敏捷4个个人实践之一。

推荐一本书，重构-改善既有代码设计，非常好的一本介绍重构的书籍。

其实对于软件来说，我们面对两种情况，一种是我们新增加或者修改的代码，一种是系统遗留的代码。

参加过一个培训，这个培训说，以前的代码很烂，那是以前的人留下的，可是我们现在在做什么呢，我们现在也许在为以后留下烂代码。

所以我们需要重构，何时重构？

如果团队推广TDD的时候，那么每一个测试用例通过的时候，都需要在看看代码，是不是有坏味道，有的话，需要消除掉。

如果没有的话，那么我们需要时刻注意，当你准备复制粘贴的时候，那么你需要考虑下是不是需要重构了。

使用工具,FindBugs是个不错的选择。

那一次培训还接触到了一个新的东西，圈复杂度，至于怎么计算，网上有说，我们应该能够容忍我们的圈复杂度在10以下。

对于系统遗留的代码又如何呢？

三次原则，如果我们在老代码的三个地方看到同样的代码，那么我们就需要对其进行重构。因为三次看到一段代码，表明它在系统的活跃度很高，需要抽取。

至于如何写出好的代码，没有臭味道的代码，很难，很难，我们认为的好代码，其实就是我们看的最多，看的习惯的。

还有一本书也不错，简洁代码之道，这本书上重很多角度提出了我们应该怎么写出简洁的代码。

在组内，我们为每一个用户故事，都给出了4-8个小时的重构时间，让大家回归一下，我们的代码是不是有坏味道，足够的测试能够保证，我们在重构时候不会伤害软件的功能。

评论

15 楼 huangyuanmu 2010-06-11  

daquan198163 写道

敏捷开发中高质量 Java 代码开发实践

图不错，清晰明了，拿来借用咯

14 楼 huangyuanmu 2010-06-11  

楼主推荐的那本书，去年先看了电子书，后来又买了gigix翻译的实体书，不错。但是具体还没有太多机会去实践。findbugs也试用了下，效果不错。一直想敏捷，但是没能敏捷起来，还欠火候，还需学习和积累经验。

13 楼 shuiguozheng 2010-06-10  

  我正在下载这本书。。

12 楼 showr 2010-06-07  

<<重构 - 改善既有代码设计>> + << 设计模式 >> + <<Thinking in java>>

在看中 ...

都是经典之作 ...

11 楼 狂放不羁 2010-06-06  

gigix 写道

嗯，最近认真用了一下findbugs，确实很好
经常揪出的问题认真看看就发现一些设计和编程的经典坏习惯
消除告警不是目的，能牵引团队学到很多

哈哈，刚买了重构第二版。重温下。

10 楼 changkunyang 2010-06-04  

恩，很有启发性

9 楼 jiangduxi 2010-06-03  

重构的原理倒是不难，但是要运用的很好倒是难事，不过findbugs，PMD的原理倒是希望那位能够发帖讲解下，谢谢了。Hudson确实在持续发布有很大的帮助尤其是加上Sonar。

8 楼 double_f 2010-06-01  

       1

7 楼 rubys 2010-06-01  

抛出异常的爱 写道

gigix 写道

嗯，最近认真用了一下findbugs，确实很好
经常揪出的问题认真看看就发现一些设计和编程的经典坏习惯
消除告警不是目的，能牵引团队学到很多

我可以理解findbugs的原理
但对PMD的原理总是模模糊糊.

把原理给小弟们说一下吧 

6 楼 pipilu 2010-05-31  

楼上是想说hudson吧？

5 楼 realreal2000 2010-05-31  

mock1234 写道

realreal2000 写道

如果团队推广TDD的时候，那么每一个测试用例通过的时候，都需要在看看代码，是不是有坏味道，有的话，需要消除掉。

你们有多少TDD的小测试？等它真的多了，并且完全了，比如你不会故意忽略一些功能测试而只做十几二十几个小练习，也不会故意借口gui不好测试而不写TDD，那时再回想这个帖子吧。

TDD有个原则，你应该主动把没有TDD保护的代码删除掉（注释掉）。这时候，你会有各个方面、各个层次的几百个TDD测试程序，才可能形成一个小程序的保护网。先做好这个，再说什么重构。（原因是我觉得你说的“经验”容易变成作废的东西）

我们有接近17000个测试用例，使用代码覆盖率的机制，代码必须被覆盖，是我们的口号，当然作到这个很难。

但是现在也存在问题，我们代码要求必须没有测试失败，才能提交，全跑一次测试需要15-30分钟。。。

当然这些测试还是不够全面的，我们还有自动的多版本兼容测试，自动边界测试，多版本自动边界测试。

所以下一步就将往持续集成上走，用hudson(谢谢，呵呵)，每次提交代码，自动运行，能够很大的提高工作效率

4 楼 fengfeng925 2010-05-31  

realreal2000 写道

Refactory， 敏捷4个个人实践之一。

推荐一本书，重构-改善既有代码设计，非常好的一本介绍重构的书籍。

其实对于软件来说，我们面对两种情况，一种是我们新增加或者修改的代码，一种是系统遗留的代码。

参加过一个培训，这个培训说，以前的代码很烂，那是以前的人留下的，可是我们现在在做什么呢，我们现在也许在为以后留下烂代码。

所以我们需要重构，何时重构？

如果团队推广TDD的时候，那么每一个测试用例通过的时候，都需要在看看代码，是不是有坏味道，有的话，需要消除掉。

如果没有的话，那么我们需要时刻注意，当你准备复制粘贴的时候，那么你需要考虑下是不是需要重构了。

使用工具,FindBugs是个不错的选择。

那一次培训还接触到了一个新的东西，圈复杂度，至于怎么计算，网上有说，我们应该能够容忍我们的圈复杂度在10以下。

对于系统遗留的代码又如何呢？

三次原则，如果我们在老代码的三个地方看到同样的代码，那么我们就需要对其进行重构。因为三次看到一段代码，表明它在系统的活跃度很高，需要抽取。

至于如何写出好的代码，没有臭味道的代码，很难，很难，我们认为的好代码，其实就是我们看的最多，看的习惯的。

还有一本书也不错，简洁代码之道，这本书上重很多角度提出了我们应该怎么写出简洁的代码。

在组内，我们为每一个用户故事，都给出了4-8个小时的重构时间，让大家回归一下，我们的代码是不是有坏味道，足够的测试能够保证，我们在重构时候不会伤害软件的功能。

最近也在边看重构这本书，边改老系统的bug。发现改别人系统bug的时候，重构确实是非常好的利器。但是难免还是会引入新的bug，按照书里写的重构配合单元测试，发现确实不错。

3 楼 抛出异常的爱 2010-05-31  

gigix 写道

嗯，最近认真用了一下findbugs，确实很好
经常揪出的问题认真看看就发现一些设计和编程的经典坏习惯
消除告警不是目的，能牵引团队学到很多

我可以理解findbugs的原理
但对PMD的原理总是模模糊糊.

2 楼 daquan198163 2010-05-30  

敏捷开发中高质量 Java 代码开发实践

1 楼 gigix 2010-05-28  

嗯，最近认真用了一下findbugs，确实很好
经常揪出的问题认真看看就发现一些设计和编程的经典坏习惯
消除告警不是目的，能牵引团队学到很多