the5fire

这是一个有趣的问题——如果地上有一摊shi，你刚好走到那，你会怎么做？踩上去？亦或是绕过去？或者文明一点，帮忙清理掉？

位置可以再具体一点，假设这泡shi刚好在你家客厅，你选择怎么做？

写到这，又想起郭德纲和于谦的那段相声：冬天开着地暖，狗在客厅中间拉了一泡shi，这是扫地机器人开始工作了，穿过shi，打扫了整个客厅。

虽然说shi这个东西很低俗，但是那种感受理解起来会更容易。一般我们常说，要吃掉自己的“狗食（Dog Food）”，亦或是经常说“shit code”，大意相同。

那么还是那个问题，如果你在维护的工程中有这样的一摊“shit code”，你怎么做？

其实围绕着这个shit可以再说一些招人和用人上的事，毕竟尽量不招那些能够产出“shit code”是我们每个人的愿望。但实际情况是，在面试时很难判断这个哥们是不是会在你的工程里生产出来“shit code”，不是吗。这个就是另外的话题了，暂且不写。回来说下客观上已经存在的“shit code”。

在一个normal的环境中，有位老大用尽毕生经历，完美的写完了整个项目，任你是横看还是竖看都挑不出什么问题来。在这样的情况下，接手维护的同事相互之间或许也未必能看的出来水平。大家都是按照之前的逻辑处理嘛，老的代码写的好，那我扩展新的业务代码也不会看起来烂到哪去。因此在这样的情况下很难看出来大家的代码水平。

But，如果代码里有这样的一段或者一片“shit code”之后，就不一样了。

对于我现在正在维护的代码，少说也有四年的历史了，经手过的“前辈们”不计其数，各种招法都有用到。现实场景中没人会去踩shi，但是在工程中真的会有人去踩，并且还很开心的留下注释：老代码写的不合理，优化改进。Oh，Shit！

当然也会有比较“负责”的同事，遇到代码的时是这样：咦~，握草，还好“没下脚”，太烂了，shi样的代码，谁写的，MD，老子还是新开一个函数吧。于是代码行数越来越多，重复的逻辑，重复的功能，此起彼伏。

另外还可能存在这样的情况，代码这么复杂，重复的逻辑这么多，要不我给他们统一包装一下，设计模式里不是有一个门面模式（外观模式）吗，提供统一接口就行了。对于上层来说确实有了优化，但是对于现在的代码所在层，只是进一步的增加了复杂度。就好像是一栋地基都没打好的房子，为了防止倒，旁边用木棍支柱一样。

最好的一种方式，主动清理掉。但是需要对整个项目有足够的把握，这意味着，在保持业务进展的同时，必须能够抽出时间来干这个。什么？你说专门排期来做优化、重构？这确实是每个有追求的程序员的心声。我以前也经常这么想，但我现在更明白软件的作用。第一点是支持业务运转，之后才是效率和维护成本。因此，更好一点的做法是，跟着业务需求走，走到哪里优化到哪里，so easy。

那么，你遇到这种情况或怎么做呢？