你眼中的 “烂代码”，或许曾支撑过公司的核心业务，甚至藏着你不知道的 “隐形坑”，就像是《左耳》里面写的：“前任也曾是爱的人”。
核心：职场不是 “写漂亮代码的乌托邦”，而是 “解决问题的修罗场”。
如果你正被屎山 “暴击”，先别急着 emo：屎山代码，其实是各个公司的常态。无论是初创公司的 “先跑通再优化”，还是大厂遗留的 “多人迭代无规范”，几乎没有工程师能逃过与屎山共舞的命运。
关键不是抱怨 “这代码怎么这么烂”，而是学会在不掀桌子的前提下，优雅生存并悄悄优化。
一、心态篇：先放弃 “洁癖式重构”，接受不完美
很多工程师刚遇到屎山，第一反应是 “忍不了，必须重写！”—— 但请打住这个危险的念头。
首先，屎山的存在一定有历史原因：
- 早期赶项目上线的妥协
- 前任开发者的能力局限
- 业务迭代太快没来得及重构。
其次，新手上来就全局重构，等于给自己挖坑：
- 对业务逻辑还不熟悉，很可能重构时引入新 bug；
- 全局重构耗时耗力，领导大概率不会批准 “不产生直接价值” 的工作；
- 过度的代码洁癖，会让你陷入 “越看越烦，越改越乱” 的内耗，反而影响核心工作推进。
正确的心态是：接受 “先能用再优化” 的现实，把洁癖收一收。把屎山当成 “职场修炼场”—— 能在混乱中理清逻辑、解决问题，远比写 “漂亮的新代码” 更能体现你的能力。
二、行动篇：局部优化，小步快跑不翻车
面对屎山，“不动全局，只改局部” 是最高效的破局策略。毕竟，重构一座山不现实，但清理脚下的一块石头，既安全又能积累成就感。
1. 先 “看懂” 再动手，别盲目改
刚接触屎山时，最忌讳 “觉得哪里不对就改哪里”。正确步骤是：
- 先找业务流程图：搞懂这段代码对应什么功能，输入输出是什么，核心链路在哪里；
- 顺着 bug / 需求找入口：比如领导让你修复某个问题，先定位到相关代码片段，只关注 “影响当前需求” 的逻辑，别发散！！！
- 画简易逻辑图：把关键流程、函数调用关系简单画下来，标注清楚 “这里是坑”“这里是临时补丁”，避免后续踩雷。
记住：在屎山里，“看懂” 比 “改得漂亮” 更重要。
2. 局部优化：改 1 处，稳 1 处，不添乱
每次接触屎山代码，只做 “最小化优化”，比如：
- 修复 bug 时，顺便把周边 3 行以内的混乱逻辑理顺（比如拆分过长的条件判断、补全关键注释）；
- 给看不懂的变量 / 函数重命名（比如把
x1改成userLoginStatus，但要注意全局引用，避免改崩）； - 补全 “救命注释”：不用写长篇大论，只标注 “这段代码是兼容 XX 设备”“此处不能删，删了会触发 XXbug”，方便自己和同事后续维护；
- 抽离重复逻辑：如果发现多处复用同一坨代码，悄悄封装成小函数（先在本地测试，确认不影响现有功能再提交）。
核心原则：局部优化不影响全局，每次修改只解决 1 个小问题。别想着 “趁这次机会把整个模块翻新”，否则很可能引发连锁反应，最后锅全成了你的。
3. 建立 “安全边界”，别被屎山同化
在优化的同时，要给自己的代码建立规范：
- 新写的代码严格遵循公司规范（或行业通用规范），变量命名、注释格式、函数长度都保持一致；
- 新增功能尽量 “独立封装”，避免直接嵌入屎山核心逻辑，减少耦合；
- 提交代码时写清楚注释
久而久之，你写的 “干净代码” 会像一块块补丁，慢慢覆盖屎山的关键区域，也能带动团队的代码质量。
三、成长篇：从屎山中淘金，积累自己的 “避坑指南”
其实，屎山代码看似是负担，实则是宝贵的学习资料 —— 它藏着无数前人踩过的坑，能让你快速成长：
- 从混乱逻辑中总结 “反模式”：比如 “为什么上千行的函数难维护？”“没有注释的代码会引发什么问题？”，这些经验会让你以后写代码时更谨慎；
- 理解 “业务优先” 的现实：很多屎山是 “业务催着上线” 的产物，这会让你明白 “工程落地” 不是追求完美，而是在时间、质量、成本之间找平衡；
- 锻炼 “问题拆解” 能力：在屎山里定位一个 bug，比在整洁代码里难 10 倍，但搞定一次，你的调试能力、逻辑分析能力会突飞猛进。
文末
面对屎山代码，与其抱怨 “为什么让我接手烂摊子”，不如换个角度：能搞定屎山的工程师，才是公司真正需要的核心人才。先活下来，再慢慢变好；先局部优化，再逐步重构。毕竟，罗马不是一天建成的，屎山也不是一天能铲平的。
💬 互动话题：你入职时遇到过最离谱的屎山代码是什么样？评论区分享你的 “踩坑经历” 和破局妙招～
)