”你是那种囤积有用信息，让别人挣扎或重新发明轮子的类型吗？你是否做出了你认为很聪明，但只有你自己理解的决定？是时候问问自己了：“这真的是最好的做事方式吗？其他人可以进来并立即了解发生了什么吗？这种反思可以帮助您更加了解自己的习惯，并为更深思熟虑和更容易获得的解决方案打开大门。“

“很多这种无意的虐待狂都隐藏在善意的背后。它披着“最佳实践”、“简洁架构”或“现代工具”的外衣。但是，当你把它剥开来看，它往往只是伪装的技术债务。
这些借口可以而且会让你放慢脚步。它们使代码更难更改、更难修复和更难信任。真正的问题是，没有人认为他们在编写代码时编写了糟糕的代码。这就是陷阱。”

“我们还有很多罪可以指出来，但我会把这些留到另一天。现在，考虑最后一个例子：我曾经认识一个开发人员，他设置了如此严格的 CI 检查，以至于他甚至无法合并自己的拉取请求。他一定是觉得看着团队转圈圈很搞笑。剧透警告：没有人在笑。”

AI 摘要：本文探讨了“开发者虐待狂”（Developer Sadism）现象，即开发者无意识地编写复杂、难以维护或过度设计的代码，导致团队效率下降和士气受损。作者通过个人经历和行业观察，分析了这一现象的成因、表现及后果，并提出了改善建议，强调代码应具备可读性、实用性和同理心。

1. 引言
• 作者因被同事评价代码“虐待狂式”而反思开发者行为，提出“开发者虐待狂”概念，即故意或无意编写难以理解的代码。

2. 并非所有代码都同等重要
• 作者解释实验性代码（如 CodePen 测试）的复杂性是学习过程的一部分，但真正的“虐待狂”行为体现在生产代码中，如过度设计或缺乏同理心的工具设计。

3. 开发者虐待狂的“七宗罪”
• 过度工程化：为追求架构完美牺牲实用性，导致代码难以维护。
• 盲目追逐潮流：滥用新工具或库，忽视项目实际需求。
• 工具滥用：过度依赖特定工具（如 React Router 或 Flexbox），即使不适用。
• 哲学极端化：过度追求编程范式（如函数式编程），忽视代码可读性。
• 懒惰命名：使用模糊的变量名（如 a 或 doit()）或无效的错误提示。
• 复杂逻辑：如深层嵌套的三元表达式，降低可读性。
• 严苛流程：如设置过于严格的 CI 检查，阻碍团队协作。

4. 后果
• 技术债务伪装：以“最佳实践”为名的过度设计最终拖累项目。
• 人力成本：导致团队倦怠、效率下降和创造力枯竭。

5. 改进建议
• 自我审查习惯：定期反思代码是否易于他人理解。
• 同理心设计：考虑开发者与用户的体验，优化文档和错误提示。
• 容错设计：提供“撤销”选项或试运行功能，减少错误惩罚。
• 持续反馈：邀请他人审查代码，发现潜在问题。
• 投资开发者体验（DX）：完善文档和示例，提升团队效率。

6. 结论
• 呼吁开发者避免“虐待狂”行为，通过小步骤改进代码可读性和协作性，营造健康的开发环境。

Frontend Masters

Am I a Sadistic Developer? Are You?

Sadistic, as in I purposefully wrote the code this way to make things harder for myself. Coding in a way that no typical developer would ever write on purpose.