再看了有关敏捷的书籍以及参加一个敏捷团队扫盲培训之后,又重点学习了重构-改善既有代码设计这本书之后,更加坚持了对于测试驱动开发原则.
首先重构是建立在拥有完备的功能测试以及完备的单元测试的基础上的.
因为这样代码的重构的代码才能保证不会影响软件的正常运行,还会给予自己很大的信心,重构可能出现的错误能够被检测到.
我们的项目经历了上百个feature开发,不断的迭代,缺没有任何重构的过程,所有的代码虽然都经过评审,但是很多重复的代码被留在了项目中(不是一个人写的,不是一个时期写的,存在不同的文件中),老人不断离去,刚发现,自己已经是队伍中最老的几个人了,大量新人的加入,使得很多已经实现的东西,又重复被实现,散落在各处.
幸好我们对所有代码都要求测试覆盖率.可是我们没有信心去修改他,覆盖是覆盖了,可是测试用例到底全不全不知道.
每一次抽取函数,修改里面的动作,都要无比小心,因为害怕使用到他的地方被影响了,但是测试没有覆盖到.
看过无数的敏捷的书中,对于测试都无比的强调,而TDD模式正好能够转变我们开发中的思想,测试比代码重要,有可靠测试的代码才是好的代码.它能保证我们大多数的 bug都会被追查到.
只有这样我们才能放心的重构.
首先重构是建立在拥有完备的功能测试以及完备的单元测试的基础上的.
因为这样代码的重构的代码才能保证不会影响软件的正常运行,还会给予自己很大的信心,重构可能出现的错误能够被检测到.
我们的项目经历了上百个feature开发,不断的迭代,缺没有任何重构的过程,所有的代码虽然都经过评审,但是很多重复的代码被留在了项目中(不是一个人写的,不是一个时期写的,存在不同的文件中),老人不断离去,刚发现,自己已经是队伍中最老的几个人了,大量新人的加入,使得很多已经实现的东西,又重复被实现,散落在各处.
幸好我们对所有代码都要求测试覆盖率.可是我们没有信心去修改他,覆盖是覆盖了,可是测试用例到底全不全不知道.
每一次抽取函数,修改里面的动作,都要无比小心,因为害怕使用到他的地方被影响了,但是测试没有覆盖到.
看过无数的敏捷的书中,对于测试都无比的强调,而TDD模式正好能够转变我们开发中的思想,测试比代码重要,有可靠测试的代码才是好的代码.它能保证我们大多数的 bug都会被追查到.
只有这样我们才能放心的重构.