代码脏乱的“蛀牙”效应

前几天去看了牙医，把之前发现的蛀牙给补上了，处于好奇问了些牙齿方面的知识，结果和我想的颇有出入，很奇妙的是和代码脏乱的情况有出奇的一致性。

有一颗牙的蛀牙产生我以为是这样的：

有一次我吃榛子，我向来是直接用牙咬碎的，结果有一次就把一个牙崩掉一块，我也没以为然，后来发现这个牙开始有蛀牙了，我的理解是牙掉了一块，然后细菌会容易驻留，但是看起来并不严重，加上工作也忙，就拖了有段时间才去看。

然后医生告诉我实际情况是：

蛀牙早就在里面悄悄产生了，直到把我的牙里面弄空了好大一块，但是你照镜子的时候，一点都发现不了（必须要用专门的仪器扫描出来），而且咬榛子什么的都没什么问题，直到弄空了很大一块的时候，我再去咬榛子的时候，发现没搞定榛子，自己牙反而掉了一块。

而我缺乏这方面的知识，并不会认为是这个原因，却以为是这次没咬好，是个寸劲，是个偶然。

后来发现的蛀牙，看起来不严重，感觉上也没痛，其实它完全不是你看起来的样子，也不是你感觉到的样子，它是在向内发展，已经非常接近牙神经了，后来补牙清理阶段，发现距离牙神经只有薄薄的一层，晚上2个月，这个牙只能废掉了。

读者如果是一线的程序员，相信可能会出现会心一笑。

如果是个技术爱好者，我不妨再多解释一下，

如果你是这个软件的使用者，并没有深入去接触代码的话，只看功能，易用性，甚至去测量性能都不会察觉到悄然生成的代码脏乱化。

而这个脏乱化几乎是个天然的过程，即便是顶级开发者，也要每段时间停下来，重新过一下，才能保证清洁。（就像你吃的总是很健康的水果，也要注意刷牙，如果是巧克力等，那就更要注意了）。

然后会发现开发团队做东西越发的慢，bug越发的多，但是这个慢和bug到底是多少由脏乱引起的，如果不接触代码，是不会知道的，当然可以猜，也有可能猜的比较准。（就像内蛀牙，观察表面是看不出来的）。

但是这个对开发效率的损害是客观存在的，处理一些软柿子类的任务还是得心应手的，直到那一天遇到一个棘手的事情，一个真正的挑战的时候，发现搞不定了。（咬榛子把自己牙崩掉了）。

如果还是没发现，或者发现了但是觉得可能不严重，依旧把其他事情的优先级拍得更高，那只能祈祷再最终发现之前，模块还有救了，脏乱到一定程度，对于项目来讲，重构代价甚至高于重写。（相当于还是觉得没事，晚上累了就懒得刷牙了，工作忙了就不去看医生了，真疼了，牙基本废了）。

实际中，代码脏乱会有加速的情况存在，以破窗效应的方式影响开发者，就越来越乱，而且乱的理所当然，乱的理直气壮。

最后补上牙齿保健：天天刷牙必须的，也没什么难度，比较好的是定期（一年期可以）去用仪器照一下，发现蛀牙立刻补上，然后就是牙好，胃口就好，身体倍儿棒，吃嘛嘛香。

也祝愿广大项目也是身体倍儿棒，吃嘛嘛香啊！！！