|
锁定老帖子 主题：重构-我们在尝试
精华帖 (5) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-05-28
Refactory， 敏捷4个个人实践之一。
推荐一本书，重构-改善既有代码设计，非常好的一本介绍重构的书籍。 其实对于软件来说，我们面对两种情况，一种是我们新增加或者修改的代码，一种是系统遗留的代码。 参加过一个培训，这个培训说，以前的代码很烂，那是以前的人留下的，可是我们现在在做什么呢，我们现在也许在为以后留下烂代码。 所以我们需要重构，何时重构？ 如果团队推广TDD的时候，那么每一个测试用例通过的时候，都需要在看看代码，是不是有坏味道，有的话，需要消除掉。 如果没有的话，那么我们需要时刻注意，当你准备复制粘贴的时候，那么你需要考虑下是不是需要重构了。 使用工具,FindBugs是个不错的选择。 那一次培训还接触到了一个新的东西，圈复杂度，至于怎么计算，网上有说，我们应该能够容忍我们的圈复杂度在10以下。 对于系统遗留的代码又如何呢？ 三次原则，如果我们在老代码的三个地方看到同样的代码，那么我们就需要对其进行重构。因为三次看到一段代码，表明它在系统的活跃度很高，需要抽取。 至于如何写出好的代码，没有臭味道的代码，很难，很难，我们认为的好代码，其实就是我们看的最多，看的习惯的。 还有一本书也不错，简洁代码之道，这本书上重很多角度提出了我们应该怎么写出简洁的代码。 在组内，我们为每一个用户故事，都给出了4-8个小时的重构时间，让大家回归一下，我们的代码是不是有坏味道，足够的测试能够保证，我们在重构时候不会伤害软件的功能。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2010-05-28
嗯，最近认真用了一下findbugs，确实很好
经常揪出的问题认真看看就发现一些设计和编程的经典坏习惯 消除告警不是目的，能牵引团队学到很多 |
| 返回顶楼 | |
|
发表时间：2010-05-30
|
| 返回顶楼 | |
|
发表时间：2010-05-31
gigix 写道 嗯，最近认真用了一下findbugs，确实很好
经常揪出的问题认真看看就发现一些设计和编程的经典坏习惯 消除告警不是目的，能牵引团队学到很多 我可以理解findbugs的原理 但对PMD的原理总是模模糊糊. |
| 返回顶楼 | |
|
发表时间：2010-05-31
realreal2000 写道 Refactory， 敏捷4个个人实践之一。
推荐一本书，重构-改善既有代码设计，非常好的一本介绍重构的书籍。 其实对于软件来说，我们面对两种情况，一种是我们新增加或者修改的代码，一种是系统遗留的代码。 参加过一个培训，这个培训说，以前的代码很烂，那是以前的人留下的，可是我们现在在做什么呢，我们现在也许在为以后留下烂代码。 所以我们需要重构，何时重构？ 如果团队推广TDD的时候，那么每一个测试用例通过的时候，都需要在看看代码，是不是有坏味道，有的话，需要消除掉。 如果没有的话，那么我们需要时刻注意，当你准备复制粘贴的时候，那么你需要考虑下是不是需要重构了。 使用工具,FindBugs是个不错的选择。 那一次培训还接触到了一个新的东西，圈复杂度，至于怎么计算，网上有说，我们应该能够容忍我们的圈复杂度在10以下。 对于系统遗留的代码又如何呢？ 三次原则，如果我们在老代码的三个地方看到同样的代码，那么我们就需要对其进行重构。因为三次看到一段代码，表明它在系统的活跃度很高，需要抽取。 至于如何写出好的代码，没有臭味道的代码，很难，很难，我们认为的好代码，其实就是我们看的最多，看的习惯的。 还有一本书也不错，简洁代码之道，这本书上重很多角度提出了我们应该怎么写出简洁的代码。 在组内，我们为每一个用户故事，都给出了4-8个小时的重构时间，让大家回归一下，我们的代码是不是有坏味道，足够的测试能够保证，我们在重构时候不会伤害软件的功能。 最近也在边看重构这本书，边改老系统的bug。发现改别人系统bug的时候，重构确实是非常好的利器。但是难免还是会引入新的bug，按照书里写的重构配合单元测试，发现确实不错。 |
| 返回顶楼 | |
|
发表时间：2010-05-31
最后修改：2010-05-31
mock1234 写道 realreal2000 写道 如果团队推广TDD的时候，那么每一个测试用例通过的时候，都需要在看看代码，是不是有坏味道，有的话，需要消除掉。
你们有多少TDD的小测试？等它真的多了，并且完全了，比如你不会故意忽略一些功能测试而只做十几二十几个小练习，也不会故意借口gui不好测试而不写TDD，那时再回想这个帖子吧。
TDD有个原则，你应该主动把没有TDD保护的代码删除掉（注释掉）。这时候，你会有各个方面、各个层次的几百个TDD测试程序，才可能形成一个小程序的保护网。先做好这个，再说什么重构。（原因是我觉得你说的“经验”容易变成作废的东西） 我们有接近17000个测试用例，使用代码覆盖率的机制，代码必须被覆盖，是我们的口号，当然作到这个很难。 但是现在也存在问题，我们代码要求必须没有测试失败，才能提交，全跑一次测试需要15-30分钟。。。 当然这些测试还是不够全面的，我们还有自动的多版本兼容测试，自动边界测试，多版本自动边界测试。 所以下一步就将往持续集成上走，用hudson(谢谢，呵呵)，每次提交代码，自动运行，能够很大的提高工作效率 |
| 返回顶楼 | |
|
发表时间：2010-05-31
楼上是想说hudson吧？
|
| 返回顶楼 | |
|
发表时间：2010-06-01
抛出异常的爱 写道 gigix 写道 嗯，最近认真用了一下findbugs，确实很好
经常揪出的问题认真看看就发现一些设计和编程的经典坏习惯 消除告警不是目的，能牵引团队学到很多 我可以理解findbugs的原理 但对PMD的原理总是模模糊糊. 把原理给小弟们说一下吧 
|
| 返回顶楼 | |
|
发表时间：2010-06-03
重构的原理倒是不难，但是要运用的很好倒是难事，不过findbugs，PMD的原理倒是希望那位能够发帖讲解下，谢谢了。Hudson确实在持续发布有很大的帮助尤其是加上Sonar。
|
| 返回顶楼 | |
|
发表时间：2010-06-04
恩，很有启发性
|
| 返回顶楼 | |
