Refactory, 敏捷4个个人实践之一。
推荐一本书,重构-改善既有代码设计,非常好的一本介绍重构的书籍。
其实对于软件来说,我们面对两种情况,一种是我们新增加或者修改的代码,一种是系统遗留的代码。
参加过一个培训,这个培训说,以前的代码很烂,那是以前的人留下的,可是我们现在在做什么呢,我们现在也许在为以后留下烂代码。
所以我们需要重构,何时重构?
如果团队推广TDD的时候,那么每一个测试用例通过的时候,都需要在看看代码,是不是有坏味道,有的话,需要消除掉。
如果没有的话,那么我们需要时刻注意,当你准备复制粘贴的时候,那么你需要考虑下是不是需要重构了。
使用工具,FindBugs是个不错的选择。
那一次培训还接触到了一个新的东西,圈复杂度,至于怎么计算,网上有说,我们应该能够容忍我们的圈复杂度在10以下。
对于系统遗留的代码又如何呢?
三次原则,如果我们在老代码的三个地方看到同样的代码,那么我们就需要对其进行重构。因为三次看到一段代码,表明它在系统的活跃度很高,需要抽取。
至于如何写出好的代码,没有臭味道的代码,很难,很难,我们认为的好代码,其实就是我们看的最多,看的习惯的。
还有一本书也不错,简洁代码之道,这本书上重很多角度提出了我们应该怎么写出简洁的代码。
在组内,我们为每一个用户故事,都给出了4-8个小时的重构时间,让大家回归一下,我们的代码是不是有坏味道,足够的测试能够保证,我们在重构时候不会伤害软件的功能。
推荐一本书,重构-改善既有代码设计,非常好的一本介绍重构的书籍。
其实对于软件来说,我们面对两种情况,一种是我们新增加或者修改的代码,一种是系统遗留的代码。
参加过一个培训,这个培训说,以前的代码很烂,那是以前的人留下的,可是我们现在在做什么呢,我们现在也许在为以后留下烂代码。
所以我们需要重构,何时重构?
如果团队推广TDD的时候,那么每一个测试用例通过的时候,都需要在看看代码,是不是有坏味道,有的话,需要消除掉。
如果没有的话,那么我们需要时刻注意,当你准备复制粘贴的时候,那么你需要考虑下是不是需要重构了。
使用工具,FindBugs是个不错的选择。
那一次培训还接触到了一个新的东西,圈复杂度,至于怎么计算,网上有说,我们应该能够容忍我们的圈复杂度在10以下。
对于系统遗留的代码又如何呢?
三次原则,如果我们在老代码的三个地方看到同样的代码,那么我们就需要对其进行重构。因为三次看到一段代码,表明它在系统的活跃度很高,需要抽取。
至于如何写出好的代码,没有臭味道的代码,很难,很难,我们认为的好代码,其实就是我们看的最多,看的习惯的。
还有一本书也不错,简洁代码之道,这本书上重很多角度提出了我们应该怎么写出简洁的代码。
在组内,我们为每一个用户故事,都给出了4-8个小时的重构时间,让大家回归一下,我们的代码是不是有坏味道,足够的测试能够保证,我们在重构时候不会伤害软件的功能。