我与祖传屎山代码有个约会

目录索引

阅读本文大约需要4分钟。

---

什么是屎山代码

职业生涯至此，不知该是感慨有幸还是不幸，曾见到过数份被鄙人定义为屎山的代码。这不最近，又接手一份祖传屎山代码，属实又一次刷新认知底线。

鄙人是怎么认定一份代码的好坏以及判断该代码算不算屎山代码的呢？

只要是跑在线上基本能够满足业务需求，并且能给公司和用户创造价值的代码，就能被称之为好代码，或者可以说一句写得不错。

坏的代码呢？可能里面有很多高大上的技术和创新，代码质量也很高，但是在用户数上少的可怜，无法创造价值，或者价值无法被大多数人认同，那么这样的代码估计也很快会消失在历史中。

关于屎山代码的定义，则比较复杂，代码质量肯定是一个维度。但屎山代码并不影响它所创造的价值和已经取得的成绩…

不过屎山代码大致可总结为以下几点：

• 变量命名不规范、封装极少或基本没封装
• 代码目录划分或代码内逻辑混乱
• 基本无文档或者文档就寥寥几十或百来字
• 产品侧或技术侧的最新业务流程或技术设计概要甚至产品原型都没有
• 拓展性差，或压根就没考虑过让其他人拓展
• 动不动一个函数或方法上来就是几千上万行
• 模块耦合度高
• 直接在代码中写死需求(例如需求是希望网站拒绝张三的ip访问，不考虑将其做成一个公共黑名单功能，反正直接在代码加个if完成下班，如果不懂技术的leader估计还会觉得其技术好效率高，但业务扩大要拉入的黑名单突然剧增到1000个，后来维护者也能天天加if？)
• 没有注释或注释约等于没有
• 臃肿不堪，甚至很多已经弃用的代码还保留
• 项目核心人员已离职或者只剩几天交接时间
• 就连项目开发环境和线上部署都留下坑点(故意保留很多弃用的依赖和复杂化部署流程，比如在前面说的黑名单功能故意引用websocket，再假装注释掉，并且故意引入一些复杂架构，例如php编译安装一些冷门拓展、docker部署后日志切割故意不用docker提供的，再安装一个冷门包，然后必须每次启动容器手动去启动，否则报错)
• 数据库创建有一堆无用的表或者莫名其妙甚至没用的表字段
• 完全没有单元测试，导致后期代码总是时不时出现一些预期之外的结果(例如js 加法运算只考虑整数1+2 不考虑0.1 + 0.2 例如php使用in_array忘记开启strict 导致结果字符串’1any’存在于数组[0,1]中])
• 其他让人抓狂的点…

以上说的点，有些屎山代码可能全中，有些屎山代码可能只踩到其中几个点。

至于祖传屎山代码，则是特指至少两人或以上经手过的屎山代码…并且已经有一定年限，有年限就意味着技术栈有点老旧，可能还存在某些上古写法…

屎山代码是怎么来的

每个公司的屎山代码诞生的历程估计不尽相同，反正能被后来者接手的屎山代码基本都是历史遗留问题，但一定存在部分共性。

大抵的诞生可能含有如下方面的原因：

• 公司的业务都还没有成型，业务需求缺乏规划，变动太快
• 因为业务需要或个人想法导致的快速上线迭代计划
• leader或编码人员或公司层面不关心代码质量
• 没有实际项目经验导致的编码人员能力不足
• 编码人员缺少职业道德，甚至故意为之
• 找第三方混乱的外包开发
• 没有建立或执行完善的代码规范

身处编码人员行业，博主甚至见过个别编码人员写出屎山代码还沾沾自喜，殊不知有些习惯一旦养成很容易害人害己。

也见过有些同僚，故意不留下注释或文档，至于为什么？一是因为担心自己被替代，想增加被替代产生的成本，简单来说就是不希望自己的劳动成果被别人摘走，可能也存了些想离职后给公司带来一些不太明显的但又有力的障碍。二是部分"敏捷"开发、业务驱动，动不动就到996，压根也没时间去写，正好有借口故意不写。

当然，也见过找外包导致的屎山。但是值得说明的是，不是每个外包公司写出的都是屎山代码，博主也曾见过比较正常外包开发的代码，只是外包公司相比自研公司更易诞生屎山代码。

因为外包公司人员流动性大，可能代码经手人数多，而且有些是项目制，可能需要同时开发几套代码。而且外包公司的开发肯定是拿钱办事，只追求快速低成本上线。

当然，博主自己也曾生产过屎山代码，偶尔回头看时直呼辣眼睛。

屎山代码该不该重构

博主认为，该不该重构的维度可以参考如下考虑：

• 取决于公司所处的阶段和战略重心是否允许
• 还有一个重要维度就是代码是不是真的已经到了除非推倒重来、否则无法进行正常迭代和日常开发的地步
• 重构真的就能避免产生一个新的屎山代码吗

翻译成人话就是：你的leader会不会给你时间重构？重构完成到测试稳定中间出现的问题你和你的leader能不能接受？重构之后你能保证愉快开发多久？

博主认为，应该敬畏屎山代码。除非出现公司还需要大量迭代新版本、或者维护为主时间空闲、或者不打算长干能一顿忽略上新技术简历加亮点跑路、又或者确实迭代和修bug已经举步维艰，否则建议不要轻易重构。

总而言之，重构和不重构，主要取决于编码人员的个人主观和外部客观因素。

但是，能跑的还能满足迭代需求的并且时间也不太充裕的情况下，还去重构屎山代码，那可真是勇敢。因为重构并不意味着创造新价值，反而很容易面临新的风险–花几个月的时间做不出成绩、甚至出来的成品也需要时间稳定，而过程中出现问题还得自己承受。

怎么与屎山代码和解

和解第一要义，放平心态，争取同事和leader的支持。 虽然要去攻克屎山代码做成的话会是一件很酷的事情，但如果多次沟通协调后，leader不能理解和认可，没有必要死磕，不行至少可以痛快打包行李跑路下一家。如果没有同事和leader的支持，任何业务和技术方面的工作估计都很难开展。编个笑话，某大厂技术大牛被挖到新公司，新公司老板虽不懂技术但对其很是重视，把普通程序员小张三个月工作的迭代计划丢给大牛，并且对大牛说：“以你的技术是不是三天就能干完了，我是不是还得再给你找点其他活？”。

和解第二要义，重在梳理、局部重写。 离开业务谈代码都是耍流氓，如果不能理解业务或者本身都不知道业务以后的发展方向，并将业务和代码梳理出来，至少先做到业务流程和代码逻辑一一对应，否则估计很难修复原有bug和进行迭代，即使勉强写出来的代码可能也是下个屎山。至于局部重写，可以将部分功能单独拆为一个新系统或新模块或微服务进行重写，循序渐进逐步优化不合理的代码，切勿操之过急，否则容易翻车。

和解第三要义，单线追踪，先接受屎山代码，快速出成绩。 在接手屎山代码过程中，经常会遇到修复重要bug的时刻，某些时候，如果时间紧迫，必须要学会顺着单个api和bug追踪到后面涉及的各个环节，然后找到出问题的地方，先快速缝补解决即可。千万别走到误区，总是想着追求完美，发现一处bug非想把整个链路都优化一遍，却忘记先完成后完美。假设让你修复一个bug，你搞了十天半个月，你说你修复的时候优化了里面一条链路多少多少代码，相信博主，大多数情况你的leader和老板不会为你点赞，甚至还会觉得你是个水包技术差所以才干活慢。

和解第四要义，切记远离不懂装懂的人，特别是那种只会在嘴巴上说简单或者瞎指挥的人。 因为这种人会把你带进坑或者影响领导走向错误的预期，导致你与屎山和解的痛苦至少乘以三倍以上，这个要义严格意义上来说不止适用于与屎山代码和解。犹记得之前也在接手几个旧项目代码(只有一个官网项目能算得上是屎山代码，但有一项目采用新技术整体难度较大)时曾遇到一个这样的后端同事，有技术问题请教他说不出个一二三，但博主每每提出问题他仗着老员工资历说很简单，甚至这货还会在开会时当着领导的面对博主工作进度或汇报提出异议，觉得博主效率低下，说很简单他如果干只需要几下或者在时间减半就能完成。其实当时一度很想怼他你行你上，但考虑到大局，诸多忍让。后因其他原因离职，未曾想到风水轮流转，leader让其接手我手上的项目，我当时手上的项目基本是技术难度最大的几个项目，而官网项目更是乱成一锅粥，其低声下气问我要文档和新技术项目相关资料(当时有个项目用了一些新技术、其没用过但是平时在领导和博主面前经常都说贼简单、这样那样很简单就搞完了)，而我出于职业道德，文档照给甚至花了一上午时间带他梳理业务流程和代码逻辑走向，但仍然感觉其的恐惧都只差写在脑门上，博主只好安慰他说:“我之前干的时候你都说很简单，只需要几下就能搞定的，你的技术水平比我好太多，我相信以你一定很快能上手的，要相信自己！”。

和解第五要义，如果原本能正常跑的功能或者api，千万不要想不开去优化。 敬畏屎山代码，只要是没有问题的或者业务上不需要的你去改的地方，听网上众多前辈和过来人一句劝，最好别碰。因为你接手了屎山代码，之前出bug的地方你负责修复，需要你迭代的功能你负责修改，leader和管理层以及你应该都会很自然认为是理所当然。但假设你优化没让你修复bug没让你迭代的api还搞出了bug，你的leader会倾向于这是屎山代码导致的还是你技术拉胯导致的吗？再换个角度来说，你优化原本不属于你工作范围的正常接口，扪心自问，你的leader真的关心吗？这个行为真的能为公司和用户带来价值吗？又或者你能收获奖金还是夸奖呢？

根据博主实践，只要将上面五大要义应用好，基本就能满足在正常公司维护和迭代屎山代码。

当然，如果有人连勤看代码、基础的技术知识储备这种最基本的条件和认知都还没有达到，建议趁早提桶跑路下一家。

但遗憾的是，只要你还在编码的职业生涯和行业中，应该很难避免遇到屎山代码，而且没有最烂，只有更烂。

---

所属分类： 闲谈

文章标签： #laravel #php