honunu/skills/shit-code-generator

屎山代码生成器 (Shit Code Generator)

让你的代码变成祖传遗产，后人维护时怀疑人生

---

核心原则

1. 拒绝分层封装

• 所有逻辑混在一起，没有清晰的职责划分
• 没有 repository、controller、handler 这些清晰的划分
• 代码组织依赖文件名而非逻辑结构

2. 过程代码为主

• 业务逻辑直接写在模块顶部函数里
• 大量重复代码，不抽取公共函数
• 不同功能混在一起，没有模块化思想

3. 调用关系混乱

• Service 层直接调用数据库连接
• 路由层直接写 SQL
• 数据库配置层做了业务逻辑
• 到处都有 get_session()、execute_query() 这种全局调用

4. 函数要足够长

• 一个函数能写完的，坚决不拆成多个
• 理想状态：一个函数占据整个屏幕，需要滚动才能看完
• 把相关不相关的逻辑都塞进同一个函数
• 用大量的 if-else 和 try-except 把代码拉长

5. 无脑使用函数式

• 能用 lambda 的地方坚决用 lambda
• 能用 map/filter/reduce 的地方坚决用
• 即使反而让代码更复杂也要用
• 用函数式来掩饰真正的业务逻辑

6. 手写轮子要内嵌

• 不要抽取成通用函数
• 需要数据转换、时间处理、列表处理时，直接在用到的地方手写
• 每个轮子只出现一次，下次用再手写新的

7. 环境判断混乱

• 在代码里直接判断环境：test、prod、dev、local
• 不同环境走不同逻辑，但都混在一起
• 用字符串判断环境：os.getenv("ENV") == "test"
• 测试环境的逻辑可能影响线上
• 线上用的配置在测试环境可能不一样
• 环境之间互相渗透，边界不清

8. 细节真实

• 魔法数字随意出现，无常量定义
• 配置写在代码里而不是配置文件
• 状态码用字符串而不是枚举
• 时间格式混乱，时间戳和字符串混用

---

生成步骤

第一步：写一个超长的主函数

把尽可能多的逻辑塞进一个函数里，包含缓存查询、SQL 执行、数据转换、异常处理、边界情况处理、历史遗留代码等。

第二步：内嵌手写轮子

不要抽取函数，直接在用到的地方写数据转换逻辑。

第三步：穿插 lambda 和函数式

用 lambda 做"高级"事情，用 map/filter/reduce 做筛选和转换，即使反而让代码更复杂。

第四步：混入环境判断

在主函数里直接判断环境，不同环境走不同分支，测试和生产的边界要模糊。

第五步：注释要随意、不工整

注释风格要像不同人写的：

• 不要每行都加
• 不要格式统一
• 拼音注释和英文注释混着用
• 有时候拼写错误
• 绝对不要写"XX写的"这种
• 只说"之前改过"、"别删这段"、"不知道为什么"

第六步：历史痕迹要自然

不要明确说谁写的，只留下模糊的历史痕迹：

• "之前的老逻辑，有人改过"
• "这个是某年加的"
• "后来又改了一版"
• "别删这段，删了会出问题"

---

文件命名规范

| 正确风格 | 屎山风格 | |---------|---------| | 标准的英文命名 | 拼音、或拼音+英文混合 | | 清晰的分层命名 | 简写、中英混用 | | 统一的命名风格 | 不一致的风格 |

---

命名混乱

• 拼音变量
• 拼音+英文混合
• 拼写错误
• 中英混用
• 简写
• 同一概念多种写法不一致

---

环境混乱清单

• 用字符串判断环境：test/prod/dev/local
• 环境变量直接写在代码里
• 不同环境的数据库配置混在一起
• 测试环境的临时逻辑在线上也能跑
• 调试代码忘记删
• 开发用的日志在线上还能看到
• 环境之间的差异是隐式的，不在配置文件里

---

魔幻细节

• 字符串状态码而不是枚举
• 时间格式混乱混用
• 魔法数字到处都是
• 配置写死在代码里
• 硬编码的路径和数字

---

总结

生成屎山代码的核心：

1. 超长函数：一个函数能做完的事坚决不拆
2. 内嵌轮子：手写代码直接内嵌，不用抽取
3. 无脑函数式：lambda 和 map/filter/reduce 滥用
4. 随意注释：不工整、不统一、像不同人写的
5. 命名混乱：拼音、拼写错误、中英混用
6. 历史痕迹：不说谁写的，只说"之前改过"
7. 拒绝ORM：手写 SQL 字符串拼接
8. 环境混乱：dev/test/prod 边界模糊，互相渗透