代码极简主义

     我是代码极简主义者。

1：写代码，可以用简单语句写的，绝对不用复杂语句。

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

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

     你也可能会说，写这种复杂的代码，执行效率高。可是，我以为，以牺牲代码的易读性和易维护性来获得这一点点的性能，不太值得。并且如今的硬件性能都很高，这点性能提高根本就是杯水车薪。写这种复杂代码，我以为通常都是酸腐程序员的我的技能秀，没有多大的实用意义。

有人说，一个手机，80%的功能是没有用的，我以为，一门语言，也有不少语法是没用的，咱们不必必定要用它们。

2：我从不肯意保留无用的代码。

    记得有一次，咱们公司的项目上线运行的时候出了个大bug。同一时间点全部业务进程集体重启了。业务团队查了好久，都没有查出缘由，由于没有发现任何异常的日志文件。而后就把我叫过去。说他们发现这些集体重启的业务进程有一个共同特色，就是都包了我提供的一个库，因此他们怀疑是否是我这个库的问题，但愿我查一下这个库。

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

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

      新的库代码不须要这个逻辑，可是相关的代码并无彻底删除。重连成功的时候，中止定时器的代码被删除了，可是网络链接失败的时候，开启定时器的代码没有删除，定时器回调函数也没有删除。因此一旦在业务的运行过程当中，出现过网络链接失败的状况，那么72小时定时器就会被开启，即便后面重连成功了，定时器也不会被删除，因此72小时一到，全部业务进程就集体自杀了。因此此次事故的根本缘由就是没有把老代码删除干净！

      你们应该都有这样的经历，维护老代码的时候，里面常常会有不少注释的代码。有时候更夸张的是，你会发现有用的代码尚未注释掉的代码多，有用的代码都被淹没在注释代码里，看到这样的代码，你会以为爽么？还有的状况是，代码没有被注释掉，可是根本没有什么用处，由于没有地方调用他们，或者是已是没有用的逻辑。这样的代码多了，你可能会迷失在这些无用的代码中，而忽略真正有用的代码。

      因此，我通常接手一份老代码后，第一件事情就是把这些废代码删除。首先是把注释掉的代码删除，而后就是把代码从头至尾走读一遍，把没有注释掉，可是已经明显没用的代码都删除。这样作的好处一方面是减小代码量，另一方面就是避免了老代码里面隐藏的bug。你只有对每一行代码的用处都有清晰的认知，才能在出bug的时候精准定位。

      以前有个同事跟我说，代码为何要删除，放在那里，说不定之后还有用呀。这应该就是大多数废代码残留的缘由。我不排除这种可能性，可是常常的状况是这种可能性出现的机会不多。即便真的出现了，我再从新写一次，又有什么关系呢？

3：我不肯意作超前的设计

      不少人在设计一个新系统的时候，会进行过分的设计。

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

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

      这个同事傻眼了，这个系统原来这么复杂啊，我都快绕晕了？这里为何要用泛型？直接定义一个类不就好了？这里为何要封装，封装类里面什么都没有作呀？是否是里面有什么玄机我尚未参透？是否是我能力有限呀？

      因此，我总不建议在设计的时候考虑太多“之后”这种可能性。如今软件更新换代那么快，之后的事情谁知道呢？你的这种可能性可能尚未出现呢，你设计的模块可能就已经被淘汰了。可是你的那些过分的设计却花费了后续维护人员太多的时间和精力。

      以个人经验，一个软件在初期规划的时候是什么样子，之后基本上就是什么样子，可能会有些小功能的添加，通常不会在结构上有大的调整。若是真的须要在结构上进行大的调整，基本上就须要从新规划一个新的软件了。因此代码知足如今的需求就好了，不须要作过多超前的设计。

-----------------------------------------------------

欢迎关注个人微信公众号 ^_^