代码极简主义

作者: 程序媛小菜 | 来源:发表于2016-03-14 10:40 被阅读587次

    我是代码极简主义者。

    1:写代码,能够用简单语句写的,绝对不用复杂语句。

    简单语句,不管什么水平的人都能阅读,在读代码的过程中,会很顺畅。而复杂语句,水平不够的人,不一定能看懂。试想一个场景,项目时间很紧,我今天要把这段代码看懂,然后争取把这个bug解决掉。可是突然来了这么一个复杂语句,以前都没有见过,都不知道是什么意思?你说讨厌不讨厌?为了弄懂它,我得摆渡一下,摆渡如果没有结果,那谷还得谷歌一下,如果还是看不太懂。那没办法了,问一下大牛吧。抬头一看,大牛都下班了。于是今天要把这个bug解决的希望彻底破灭,你说闹心不闹心,多耽误时间?

    所以,我从不用复杂语句。你可以说我水平不够,也可以说我没见过世面,无所谓。只要功能实现了就好,只要代码容易维护就好,其他的我不care。

    你也可能会说,写这种复杂的代码,执行效率高。但是,我觉得,以牺牲代码的易读性和易维护性来得到这一点点的性能,不太值得。而且现在的硬件性能都很高,这点性能提升根本就是杯水车薪。写这种复杂代码,我觉得一般都是酸腐程序员的个人技能秀,没有多大的实用意义。

    有人说,一个手机,80%的功能是没有用的,我觉得,一门语言,也有很多语法是没用的,我们没必要一定要用它们。

    2:我从不愿意保留无用的代码。

    记得有一次,我们公司的项目上线运行的时候出了个大bug。同一时间点所有业务进程集体重启了。业务团队查了很久,都没有查出原因,因为没有发现任何异常的日志文件。然后就把我叫过去。说他们发现这些集体重启的业务进程有一个共同特点,就是都包了我提供的一个库,所以他们怀疑是不是我这个库的问题,希望我查一下这个库。

    因为没有经历过,所以我理所当然地认为,这次集体重启事情跟我的库应该没什么关系。就算是我的库有问题,那也只可能影响单个的业务进程,而不可能同时影响其他的业务进程。因为这个库之前不是我做的,我也是刚接手过来没多久,正在整理代码。所以回来后,虽然我不太相信是我的库的问题,但还是把代码仔细走读了一遍。这不走读不要紧,一走读才发现还真的是我这个库代码的问题。

    事情是这样的,这个库代码是从以前老的库代码修改过来的。老的库代码里面有一段逻辑,如果这个库连接服务器失败,那么就会开启一个72小时的定时器,如果72小时还没有重连成功,那么库就会自杀,使用的自杀手段是kill -9 进程pid。如果72小时内重连成功,那么就会把定时器停掉。

    新的库代码不需要这个逻辑,但是相关的代码并没有完全删除。重连成功的时候,停止定时器的代码被删除了,但是网络连接失败的时候,开启定时器的代码没有删除,定时器回调函数也没有删除。所以一旦在业务的运行过程中,出现过网络连接失败的情况,那么72小时定时器就会被开启,即使后面重连成功了,定时器也不会被删除,所以72小时一到,所有业务进程就集体自杀了。

    所以这次事故的根本原因就是没有把老代码删除干净!大家应该都有这样的经历,维护老代码的时候,里面经常会有很多注释的代码。有时候更夸张的是,你会发现有用的代码还没有注释掉的代码多,有用的代码都被淹没在注释代码里,看到这样的代码,你会觉得爽么?还有的情况是,代码没有被注释掉,但是根本没有什么用处,因为没有地方调用他们,或者是已经是没有用的逻辑。这样的代码多了,你可能会迷失在这些无用的代码中,而忽略真正有用的代码。

    所以,我一般接手一份老代码后,第一件事情就是把这些废代码删除。首先是把注释掉的代码删除,然后就是把代码从头到尾走读一遍,把没有注释掉,但是已经明显没用的代码都删除。这样做的好处一方面是减少代码量,另外一方面就是避免了老代码里面隐藏的bug。你只有对每一行代码的用处都有清晰的认知,才能在出bug的时候精准定位。

    之前有个同事跟我说,代码为什么要删除,放在那里,说不定以后还有用呀。这应该就是大多数废代码残留的原因。我不排除这种可能性,但是经常的情况是这种可能性出现的机会很少。即使真的出现了,我再重新写一次,又有什么关系呢?

    3:我不愿意做超前的设计

    很多人在设计一个新系统的时候,会进行过度的设计。

    什么叫过度设计?打个比方,本来计划只是要造一个一层楼的小房子,但是设计人员认为以后这个一层的小房子可能会加到十层,所以地基被设计成能支持十层楼的地基。因为以后可能会加到十层,所以,房子的周围应该要设计一些停车位,以满足以后住户的停车需求。那既然以后这里会住那么多人,那相关的门卫,便利店,菜场,健身产所,幼儿园,小学,中学等等都要考虑起来。

    于是乎,本来只需要几百行代码就能搞定的系统,被这么一过度的设计,变成了几千上万行的代码。各种封装,各种泛型,各种绕。设计人员自己还沾沾自喜,看我设计了一个多么牛逼的系统,以后的扩展性多么地好。而目前真正用到的代码,只是那几百行而已。如果这个系统一直是这个设计人员自己维护,那也就罢了,爱咋整咋整。不幸的是,后来这个设计人员离职了,然后系统被移交给了一个并不熟悉这个系统的同事。

    这个同事傻眼了,这个系统原来这么复杂啊,我都快绕晕了?这里为什么要用泛型?直接定义一个类不就行了?这里为什么要封装,封装类里面什么都没有做呀?是不是里面有什么玄机我还没有参透?是不是我能力有限呀?

    所以,我总不建议在设计的时候考虑太多“以后”这种可能性。现在软件更新换代那么快,以后的事情谁知道呢?你的这种可能性可能还没有出现呢,你设计的模块可能就已经被淘汰了。但是你的那些过度的设计却花费了后续维护人员太多的时间和精力。

    以我的经验,一个软件在初期规划的时候是什么样子,以后基本上就是什么样子,可能会有些小功能的添加,一般不会在结构上有大的调整。如果真的需要在结构上进行大的调整,基本上就需要重新规划一个新的软件了。所以代码满足现在的需求就行了,不需要做过多超前的设计。

    相关文章

      网友评论

        本文标题:代码极简主义

        本文链接:https://www.haomeiwen.com/subject/dssxlttx.html