代码极简主义

     我是代码极简主义者。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

欢迎关注我的微信公众号 ^_^