大家好，我是米洛，求点赞!求关注!求分享！🙋🙋🙋
关注公众号: 米洛的测开日记，让我们进一步交流。
以下文章纯属个人观点，请勿对号入座，共勉🍦🍦。
# 什么是屎山代码?
大家可能在脉脉或者其他程序员论坛看到过这样的帖子:
其实它就是字面含义: 屎堆成了山，简称屎山，这个屎其实恰恰是个形容词，就像神一样的男人，它形容的是屎一样的代码。你以为开发不想给你开代码权限，是因为他们的代码很机密吗😂?
# 屎山代码的形成🍭
在大家都调侃它的时候，我想为它说几句公道话。屎堆叠成为山，其实经历了漫长的过程。
可能每个朋友在接受一个新项目的时候都是信心满满，干劲十足的。那为什么还是会形成屎山代码呢？我觉得有以下几方面的原因:
# 项目周期过长💔
一个项目迭代过多，导致我们在项目初期尽管考虑得再全面也不能考虑到几十个版本后的需求。
因为这些改动是后续添加的，所以我们做的基本都不是去重新设计整个逻辑，而是想办法改一改，支持一下新的逻辑。长期下去，你会发现代码里出现了很多判断，或者按照我常用的堆叠方法: getUserV2，也就是写一个新版本的方法，但又保留原来的方法达到兼容的目的。
项目进度太赶🎧
大家作为测试，也没少被催过进度。很多时候老板可能早上说完，晚上就要看到这个功能。没办法呀，只能堆呀。这个时候可不是什么
方案设计，逻辑梳理的时候，生怕不能按时完成老板的要求。在这样的情况下，自然什么牛鬼蛇神的代码都会出来。你可能会在一个方法里面看到无数个:
if xxx:
pass
elif xxx:
pass
else:
pass
if xxx:
if xxx and xxx:
if xxx and xxxx:
return
continue
2
3
4
5
6
7
8
9
10
11
再者，项目这么赶，哪有时间写注释呀！能在最不容易看懂的地方加上一句话，已经算给力了！
如此便是恶性循环，如果不慎引入不太靠谱的中间件，那么技术改造就在所难免了。
# 开发激情褪去💣
这玩意儿和谈恋爱一样，我见过刚入职的新人（不知道是不是为了确保转正），那个干劲儿真的很足。每天能研究怎么优化代码，怎么改善方法，用什么设计模式等等。
可随着时间的打磨，激情的褪去，可能他们就不再追求完美，只要求任务完成，没有啥毛病就好，比如:
# 平时不那么常用到的一个方法
with open(f"{filename}.txt", encoding='utf-8', w) as f:
f.write(data)
2
3
如上是一个写文件的方法，你说它长吧，好像就2行。而且假设我当前还只用得到一次，我可能就随手一写。如果我单独抽到FileUtils方法，确实是没啥毛病的。但你确定下次你需要写文件的时候，会调用FileUtils.write_file吗？而不是直接写出潇洒的: with open?
# 越来越懒🔨
def a():
....3行代码
具体的逻辑
....3行代码
2
3
4
有上面这样的方法，现在需要写个方法b，只有具体逻辑地方会有变动。
我想很多人在其他代码加起来只有6行的时候，会直接这样做吧，封装方法哪有ctrl+cv舒坦？
def b():
💩💩💩3行代码
💩💩💩
💩💩💩
具体的逻辑（新）
💩💩💩3行代码
💩💩💩
💩💩💩
2
3
4
5
6
7
8
# 接手别人的项目(项目被多人接手)🍌
这个就不多说了，屎山虽然人人喊打，但自己不会打自己。如果去接手别人的代码，你看到的只有他赶进度，偷懒，摸鱼时候堆起来的高山。所以这也就解释了为什么声讨屎山总是在刚入职的时候~
好比我司，我接受了一个API自动化的项目，仅仅是帮忙维护，一个函数里面居然有2000行代码，一个文件就更别说了。连idea都快被卡死了，变量定义以后还是显示红的（因为代码太多，还没反应过来）。
# 如何避免屎山代码🎤
说了那么多，怎么避免写出屎山代码呢？
代码review代码review是个很好的环节，虽然我那前leader写代码不咋地，指点别人却是一流的。当时还是被
看出不少问题，比如zookeeper连接忘了关这样的，靠自己还是比较难看出来的，因为这个错误不会很明显。多回顾项目再忙，也要抽空梳理以前的逻辑，该补上注释的补上注释，该优化的优化，当然如果没有给充足的时间，就等项目空闲期进行。
定期重构重构其实也是回顾的一种，当你觉得某个方法2000行了，你就必须得动手了，不然卡到IDE就是你的不对了！
写程序也是，不断总结，不断回顾，才能提高自己。如果你回过头来看自己1年前写的代码，肯定别有一番滋味。加油，屎作俑者们！👍👍👍