重构乃程序员的义务

最近在分析现有代码，将一部分逻辑抽取出来做服务化，分析的时候才发现里面有很多“坑”。在对相关负责人访谈的时候，发现绝大多数程序员都有这样的习惯：

• 面对一个新的需求，通常的做法是完全沿用现有的设计，完全不考虑现有的设计是否适应新的需求，是否要做改造；
• 想尽一切办法对现有的代码进行修修补补，完成新的功能，以达到修改最小的目的。
• 面对老旧的、无用的代码，很少甚至从来不做删除，以确保风险最低。

然后，用不了多久，代码就变得很难读懂了，只有少数人掌握其中的“真理”。我个人认为，如果是针对某一个特定的应用，规模不大、用户比较少、软件生存周期比较短、需求变更很少的情况下，这样做是可以接受的。 但如果是互联网行业，情况则完全不同：产品周期很长（除非死翘了）、需求频繁变更、业务方向经常变更，这样的做法会让代码很快就变得难以理解（我最近重构的逻辑实际上才过了1年半左右）。 最后导致的结果就是没法维护，重新开发，进入下一次恶性循环。

 

这种情况以前也经常遇到，绝对不是个案，甚至是普遍的。我开玩笑地对同事说，程序员就是被别人写的代码恶心，再把本来已经很恶心的代码变得更恶心，再用来恶心别人的过程（他离职或者去做其他的系统，别人接替他的工作）。这样对程序员整个的生存环境造成了极大的影响。 维护的工作没人愿意做，但是大多数工作都是维护类型的工作。

 

为什么不换一种思路来进行呢？

• 首先，收到一个需求，评估需求与现有的架构是否完全吻合，对于不吻合的地方，做少量的调整；
• 确保每次提交的代码，让可读性变好一点点（至少不会变差） (摘自《程序员应该知道的97件事》)
• 架构师或者资深程序员充分参与到项目里面，做好相应的支持；
• 建立较好的单元测试、集成测试、自动构建体系，尽可能减少重构带来的风险。

一些程序员遇到了拆分的问题，比如有个程序员知道底层是不能调用上层逻辑的，但是遇到了底层的一个处理必须要通知上层，又没人告诉他应该怎么做，只好硬性依赖了。对此我只能说IOC几乎每个Java程序员都知道，但是能够深入理解的就不那么多了，如果理解了IOC，就不会不知道如何处理了。

 

紧张的工期也是一个问题，当然，有些程序员不去动原有的逻辑并不真正的因为是工期的问题，而是以工期为托辞，不愿因做那些费力不讨好的工作。我个人将之归结为职业素养，宁愿晚一点下班，也要把代码写的好一些，这是职业程序员应该遵守的“道德”规范。