业务开发中的一些tips – 持续更新中

关于丑陋代码的定义:一切不具备扩展且无法再适应新变化的业务需求的代码都可以视为丑陋的代码。这里的『丑陋』没有贬义之意,那些以前很优秀的代码经过了一段时间后也会变得丑陋,没有任何漂亮的代码可以考虑所有时间段内的需求变化。
1. 不要让过时的代码在现有的新业务上起舞(可又名:戴着镣铐跳舞):如果当前的代码已经不适应业务变化的需求,立刻推翻它,即使是自己写过的。
2. 不要与丑陋的代码同流合污(又名:复用不是万能,单指复用优秀的代码):在接手一个已有系统时,如果该系统的代码比较丑陋,建议重新思考问题本身来解决新问题。
3. 警惕穷举的陷进,当程序代码中出现类似穷举的逻辑时,应该停下来思考一下是否有更好地方式。否则写下去的代码可能会难以扩展与维护。
 4. 不可过度模块化。类似于过度优化,过度模块化将会导致代码模块的粒度过细,这对于代码维护十分不利,因为代码太过分散,不易理解。
 5.依据事情的本来面目(第一原因/第一原理)去写程序。首先程序需要尽量保持健壮,然后在健壮性基础上考虑发生异常时尽可能止损。
 

穷举的陷阱

当编程遇上穷举,那将是bug的起点。
穷举,即把所有的情况都列下来,逐个考虑,碰到一种情况处理一种情况,找到所有的都处理完。在程序语言里对应的就是if语句:如果遇到***,则***。
这本质上是一种不通用的做法,即属于特殊处理的部分才需要用到if语句,属于单独的处理逻辑。即如果碰到一个问题,需要写许多的if来解决时,就要思考下是不是还有更好的解决办法。
  • 当出现多个if嵌套的时候,是否考虑下编程的思路是否正确
  • 当出现多个if/else连接的时候,是否考虑下需求的理解是否正确
  • 当出现多个if并排的时候,是否考虑下while替代的可能性。

小心,别戴着镣铐跳舞

经常有这样的场景,特别是对于新人,偶尔会接到一些已有项目的维护工作,或者在当前系统中做一些修改或增加一些新的业务逻辑。
一般的做法是:
1)学习现有代码的规范(如环境配置,变量命名,代码组织结构等)与编程逻辑(如一些基本功能的写法,可以直接作为子模块调用)
2)编写与当前代码风格一致(或相近)的代码
2)尽可能地复用当前代码逻辑
3)在复用的基础上做些微调
这种做的理由是:
一般工作中的任务都是有截止日期的,即要在规定的时间内解决问题,当然是能复用的地方尽量复用(复用的好处不用多说),从而达到用最少的成本解决问题。并且,复用代码也有利于后期维护,试想维护一个风格不一致的系统是一件多么令人蛋疼的事儿。
然而一定是这样的吗?
的确,这样做法一般都能解决。但是,最终解决问题的方式优雅与否就不一定了,这完全取决于当前已有系统的代码是否有足够优秀。
有一类情况是,如果当前的代码比较糟糕或者本来就是基于先去糟糕代码的修修补补而成的,那可能复用的时候就比较吃力和混乱了。数据挖掘领域有一种说法叫做Garbage In Garbage Out,即如果你的数据源选取的不得当,那无乱如何挖掘采取如何优秀的挖掘算法也是徒劳。换句话所,如果你复用的代码本身就不可靠:仅能照常运行,无法兼容和扩展,那么复用只会使你的代码变得更加不可扩展。而且一旦出现异常,排除问题也会变得困难重重,因为此时的代码已经是没有『逻辑』可言的,它仅仅是在当前代码上不断地打补丁,做一些修补的操作,长此以往的话,补丁越来越多,最后代码将会变得无法维护了。
这样一来,不但耗时而且耗费精力,长远看得不偿失(为什么不把这些浪费的精力用到更有用的地方呢)。
一旦陷入了此种境地,就如有戴着一副镣铐在跳舞,即使身体再灵活,笨重的镣铐戴在手里也很难优雅地舞蹈
此时,应该挣脱镣铐,勇于推翻,勇敢地重来