屎山是如何形成的？

你好，我是加百利

今天我们要聊的话题是，『屎山』是如何形成的

每当我在项目里，看见那种屎一样的代码时

总是会禁不住感叹：

这后浪们的屎，果然是比前浪的种类更加繁多啊

所谓青出于蓝，而胜于屎。

接下来，我想来探讨一下关于屎山形成的真正原因

以及如何的避免它

如果，你就是那个创造屎山的后浪

甚至，你就是那个直到今天还在创造屎山的前浪

那么，请你现在屏住呼吸

跳出屎来

好好反思一下自己。

屎山形成的第一大原因：

大概的意思就是说，你总是会绕开问题本身

只解决表面现象，至于会不会埋下更多的坑，根本不在考虑范围

这是一种的思维方式上的严重缺陷

我还是举个例子吧

比如你要修改一个BUG

就是有个按钮在手机A和B上面正常，但是在手机C上面太大了

测试希望你改小一些

一开始，你还挺纳闷，为什么之前没发现这个问题呢？

然后你一查代码不要紧， 发现这个按钮的大小，用的PX这种单位

你心中暗骂，这TM是哪个SB写的代码

移动端难道不知道做适配吗？ 怎么能用PX这种单位呢？

可是又转念一想

移动端适配？！

老子我好像也不会啊

于是你灵机一动，想出了另一条妙计。。。。。“媒介查询”

虽然媒介查询你也不熟，但感觉比移动端适配简单多了

最终，在百度的帮助下，你使用媒介查询，修复了这个按钮大小

并且更重要的是，你所做的修改

仅仅只是修复了BUG

并没有对之前的代码造成任何影响

你觉得自己简直就是个编程小天才

你看， 这就叫用打补丁来解决问题

当然你也不用抬杠，我这个例子举的确实非常含蓄

因为过于现实的例子，可能会伤害到我身边的人

所以，

不能，

过于，

真实。

我还是再举个例子吧

比如说这是一个json字符串，原本你需要将它解析为对象

但是由于这个字符串的内容不符合json的标准，导致你解析失败

于是你决定。。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

改为用字符串提取的方式，将对象的内容取出来

作者此处采用了暗讽的方式

主要表达了对那些年轻人清奇的脑回路无法理解的情绪

为了显得高大上一些，你甚至写了一段连自己都解释不了的正则表达式

来提取字符串的内容

可喜可贺，最终效果实现了，BUG修复了

不过，从这一刻开始，形成屎山的惯性，就已经被打开了。

通常， 这种补丁打到第4层以上时， 就基本无法再解决了

通常总是要回到前1层，或前2层重新打补丁

总结：  形成屎山的第一大原因，就是不解决或者故意忽略问题的本质

选择在之前错误的基础上进行修补。

屎山形成的第二大原因：拿项目练手

你是不是发现项目中莫名其妙的使用了$nextTick方法却不知何意？

你是不是发现项目中莫名其妙的使用了provide和inject特性却毫无作用？

你发现在一个根本没必要使用 vuex的地方使用了vuex？

你发现在在一个没有图表的地方，引入了echarts？

你发现在一个根本没有分享功能的地方，有微信API的代码？

你发现项目中有大量毫无卵用的工具类根本没有被用到？

你还发现，通用组件库中

经常有名字类似、功能一样，但实现完全不同的两个组件

是的，你没猜错，

这就是一个（可能不止一个）菜鸟，把公司的项目当成了自己的实验室

更可怕的是，由于水平低下， 它的试验品通常都是漏掉百出

要么最终沦为废代码（项目中没有用到）

要么最终就形成潜在的隐患

这种行为，几乎在所有职场新人里都不可避免的出现过

无论是从职业素养，还是个人道德，这种行为都是不可取的

屎山形成的第三大原因：变量与注释

说起来，变量名和注释可以很好的帮助我们理解程序的含义

但是，一旦它们到了某些人手里之后

那真的是能发挥出你无法想象的毁灭性灾难

把视频起名叫做audio，把音频起名叫做video

把数组起名叫obj，把对象起名叫arr

把数据叫date，把日期叫time

把暂停叫stop，把查询叫goto

一些新人由于英语水平不佳，同时又极度的不自信

有时候在相同的页面，会把同样一个东西叫出很多种名字

轮播图 一会叫banner，一会叫slide，一会叫swiper  一会叫PPT

还有一些变量的数据类型也非常的诡异：

isWifi 是字符串类型？！

network 是布尔类型？！

这个时候，我们只能寄希望于注释能够写的清楚一点

然而，逻辑自洽的地方就在于

一个能把变量名起成这样的鳖孙

你指望他写注释？ 

所以很多时候，遇到这种情况

因为实在搞不清楚，那些通用的变量方法以及组件，到底用在了多少地方

而且开发时间又比较紧迫

即便是我本人，也只能放任这些屎一样代码，继续存在

直到有天，你离开这个项目组或实在受不了了为止。

总结： 混乱的变量名与注释是导致项目逻辑混乱且难以修复的重要原因。

奉劝各位同仁一句话，当英语不好的时候，写拼音和注释是一种美德。

屎山形成的第四大原因

这个比较简单了，甚至无需解释。

一句话：项目组里全是菜鸟

解决方案呢？ 

不好意思，我暂时也不知道。

刚才讲的这些，听起来只是在吐槽，似乎没有什么真正的解决方案

其实，在我看来，解决方案并不重要。

重要的是，我们找到了问题的真正所在

当你敢于去直面它的时候，

当你能在内心里，勇敢的承认自己符合上述情况的时候

我相信，你已经有了解决方案

最后，再给一条价值连城的建议

一般人我不告诉他

那就是

在大多数时候，很多人从来没打开过官方文档

而在大多数时候，百度没有官方文档好用——加百利

以上，就是今天的分享

我是加百利

我们下期再见。