关于项目重构,知道真相的程序员眼泪笑了出来

关于项目重构,知道真相的程序员眼泪笑了出来

其实过完年回来,我们的项目也一直在强调重构,在实践重构中,但是到目前为止,基本没啥进度。关于项目的重构,我说:基本上大部分都是骗人的。你们信不信?那你可能会问:为什么一开始不把代码写的更好一些,逻辑更严密一些呢?那欢迎大家看我写的这篇文章《代码质量差,bug多?我们都是被逼的 》,看完你会深有同感的。

关于项目重构的问题,为什么一直做不完呢?直到我在浏览微博时,看到了一个非常好玩的对话,可谓是:感同身受,深有同感。知道真相的我,眼泪都快笑出来了,估计看到下面的对话,你们也会感同身受的,身临其境都有可能。对话如下:

A:重构80%都会失败,因为业务线的需求永远都不会停,资源有限,所以不花大代价,轻易不重构,宁可开发的慢一点,写好。

B:其实以业界大部分产品经理的水平99%的项目都活不到重构的那天,所以业务量上来再重构更省资源。

对话内容来自于@Easy的微博

看到第一句话A说的,一看就是深受其害的程序员说的,是不是说到你心坎里了。中招的同学请举手,作为我们有责任的程序员只能仰天长啸:有心写码,无力高效。bug其多,痛哉痛哉!下次你们老板和产品经理再催你赶进度,你就大喊:时间不够,代码瞎凑,毁了软件,完了项目。上线以后,如果用户体验不好,老板来找你谈话或者训你,你就说:这个锅我们程序员不背。B说的话,眼光很长远,要这么说的话,确实更省资源。要是产品经理和老板看到的话,估计不开森了。

其实项目重构是一个非常锻炼程序员能力的活,而且重构是一个不断优化和学习的过程。项目重构的重要性更不用说了,通过调整程序代码改善软件的质量、性能,使其程序的设计模式和架构更趋合理,提高软件的扩展性和维护性。可能你会问:为什么不一开始就把项目做好,代码质量写的更好呢?话虽说可能是时间问题引起的代码质量差,程序员为了赶工期,但是即使是给程序员充足的时间,他也不可能预见未来的需求的变化, 可扩展性和可维护性就无从谈起,今天你想好了代码这些,明天估计需求就又变化了。所以一个持久的好的项目也不可能避免重构的发生,写代码的高手和大神也一样,都得经历这个阶段。

那何时才能触发重构呢?答案其实很简单,你是在忍受不了混乱的代码的时候或者感觉可读性很差的时候。你的忍耐力决定重构的时机。当然如果你写的程序一直在崩溃的话,估计你得被迫去重构和优化了。其实代码重构的出发条件应该是一下几点:

  1. 牵一发而动全身的修改

  2. 代码中存在过多的重复代码

  3. 过渡的耦合

  4. 过长的方法和类(过长的代码,逻辑复杂,bug可能几率上升)

  5. 太多代码无注释,你已看不明白

如果中了上述几条,你该想想代码重构了。不要被动的去重构,主动去重构还是非常有必要的,可以避免很多问题的发生。

代码重构其实最重要,最应该注意的两点,也是应该达到的目的就是:代码的简洁,逻辑严密和性能的优化。这就是重构的意义所在和内涵。

写到这里,你们可能会问我:那该如何重构呢?是啊,我一本正经的写了这么多,你们肯定想知道这个问题的答案,到底该如何重构?那我就一本正经的告诉你们答案:如果老板和产品经理不好好对待程序员,你们基本到不了项目重构的那一天。A和B说的就是真理,你们服不服?

如果不服的话,我怕你们打我,我还是再一本正经的说两句吧,如何重构:在不改变软件系统外部行为的前提下,改善它的内部结构即可。也可以借助工具完成,重构工具能够修改代码同时修改所有引用该代码的地方。

请大家把这篇文章转发到朋友圈,让你们的老板和产品经理看看吧,让他们认识到问题的严重性,给自己争取更多的开发时间。下次如果产品经理再催你们进度,你们一定要记着一起大喊:时间不够,代码瞎凑,毁了软件,完了项目。

移动开发者的聚集地,公众号“非著名程序员”,每天一篇原创技术分享和移动互联网知识分享,微信公众号:smart_android ,头条号和百度百家账号都是“非著名程序员”。

相关推荐