我为什么很少需要回退代码

每当我有新的业务功能需要添加时，我首先会review当前的所有代码，将当前的代码逻辑进行梳理，重构到可以方便添加新的业务功能为止。简单说，修改任何代码的前提是对当前业务逻辑代码进行梳理，对代码进行重构，重新命名函数和变量，添加或者修改注释，达到自己对当前业务代码逻辑理解非常清晰的程度。重构过程中即使一行代码也没有写，但是我所添加的注释和函数、变量重命名都会给代码带来正向的一个改进，都具有价值，但同时没有带来任何新的问题。重构过程中甚至还可能修复之前因为逻辑混乱而引起的问题。每一次代码提交都会进行缜密的本地测试和代码review，所以这些提交而产生的新的版本，可能比之前的版本还要优秀，还要稳定，并且是可维护的，可以被更好理解的。每一次提交遵循小而完整的方式进行频繁提交，每次测试环境的自动部署和自动化测试都会检验我的代码，我对修改后的代码比之前的版本更有信心。我遵循在成功重构当前代码基础上才会再添加新的业务功能的原则，而业务功能的添加，还会使用配置的方式，使这个业务功能可以随时进行关闭回退，而不影响当前已有的业务逻辑，这样可以保证在出现问题时可以随时关闭此次添加的业务功能进行测试。其实，在任意时刻，代码都是可进可退，都是完整可交付的，而并不需要去通过git仓库的revert代码进行回退某个功能。简单说，不是不能通过git回退，而是已经不需要了。当我要求我的同事不要去revert代码时，一方面不想让测试资源，reviewer的时间被白白浪费，还想让他们也能理解修改代码之前先重构、步步为赢，防御式编程等优秀的编码理念。