代码中的那些偷懒

【代码中的那些偷懒】在开发新功能,维护老功能,或者重构优化前人的代码时,不知有没有踩过坑,或者觉得前人为了偷懒而使用了很多不可持续的方法。
业务逐渐丰富后,代码也日益复杂。复杂的代码维护成本很高:看的时候很费时间,改的时候也战战兢兢的。所以,为了少犯错,就很有可能偷懒。看别人的代码,会发现偷懒的代码;回过头看自己的代码,也有偷懒的地方。
譬如,需要对现有接口进行扩展,为了不破坏先前的功能,直接将先前接口的的代码全部复制,然后进行修改,增加新的功能。这种做法很稳妥,因为对于原有的功能没有影响,即使出了问题,也是新功能出问题,可以将影响最小化。但是,后人在维护时,就有很大的难度。譬如,扩展接口和非扩展接口都需要针对新场景增加功能,代码都是相同的。如果后人也偷懒,直接在扩展接口和非扩展接口中使用同样的代码,就又增加了维护的难度。如果后人有心,将扩展接口和非扩展接口统一后,在增加新的功能,开发及维护起来都很方便。
再譬如,一个函数入口有很多 switch - case (或者 if - else)语句,翻了 N 页都还没有见底。看到这种情形,你已经知道这段代码不可读了。但是,你依然需要再增加一个或者几个 case 语句。你知道不应该这么做,但是,你更不愿意去优化这些代码。因为优化就有犯错的可能,犯错一般是有惩罚,而主动优化代码不一定有那么快的奖励。所以,你很不情愿的把代码增加进去了,留给后人更多翻页的机会。但是,反过来想想,如果你主动去优化,通过详细的测试保证没有问题,那么你的劳动会被看到,会被认可。纵然,没有直接的奖励,自己也成长了,这也挺好的,重要的本来就是自己的成长。
再譬如,为了快速开发,你没有进行详细的设计就吭哧吭哧的敲击键盘。噼里啪啦,噼里啪啦,写的很尽兴,功能也逐渐实现,心里也挺有成就感的。你告诉自己,等功能调试通过了,再对代码进行优化,可是后来,再也没有考虑完善自己的代码。突然有一天,回头看,代码怎么这么难看,怎么什么功能都揉在一起,根本就没有经过设计嘛,对于有些代码,自己都不清楚为什么那么写,没有注释,也没有文档说明。这个时候,即使有心优化完善,也不敢了。后人就更不敢改了,那些代码只能默默的睡在那儿。
再譬如,一段代码复用性很高,很多地方都在用。你需要用时,直接复制过来。而不是把公用的代码提取成函数,简化调用关系,后续的维护也容易。如果需要增加新的代码,只需在提取的函数中增加就好了,不用在很多地方一一增加。如果不进行提炼,需要新增功能时,很有可能只增加一个地方,毕竟需求是在那个场景下暴露的。如果对整体代码不熟,哪里知道还有其他地方也需要增加该功能。
再譬如,多线程下的竞态,直接用各种玄学的 sleep 函数减少出现的频率。根本不去思考如何彻底解决竞态。如果觉得自己没能力解决,可以问身边的大佬。如果解决起来确实很难,可以专门投入人力进行攻关。再不济,应该给后人留些遗产,详细说明一下原因。
再譬如,使用各种变量的组合进行各种状态的切换,自己看的一头雾水不说,后人就更看不懂了。这样的代码,自己以后不会看,因为太费脑了,后人更不愿意看,除非被逼着。
再譬如,代码没有注释,函数名、变量名很随意,封装性很差等等。
以上的偷懒,有些自己也会犯,有些不会。有则改正,无则加勉了。
代码中的那些偷懒
文章图片
扫描二维码,关注“清远的梦呓”,手机端查看文章

    推荐阅读