重构乃程序员的义务

黑马程序员 2014-06-20

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

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

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

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

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

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

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

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

相关推荐