科技中的善意案例：“shitty code”

Source: Dev.to

介绍

免责声明：本文仅代表个人观点，并非绝对真理。

在我短暂的职业生涯中，我经常听到开发者在审查他人工作时嘀咕“真是shitty code”。即使是 Robert C. Martin 在《Clean Code》中也把“bad code”作为一个度量标准。虽然这种沮丧情绪可以理解，但这种表达没有建设性价值：它没有解释，也没有帮助同事改进的意愿，纯粹是评判性的。而且，它可能在团队内部制造紧张。如果你把同事刚写的代码标记为“shitty”，他们会有什么反应？

为什么该术语有问题

• 缺乏建设性反馈 – 该短语未提供如何改进代码的指导。
• 潜在冲突 – 即使在致力于无我团队中，这种语言也可能被视为攻击。
• 自我与心理安全 – 从管理者角度看，该术语可能有毒。除非完全摆脱自我，否则此类评论会损害人际关系并侵蚀信任。

背景很重要

对“好”或“坏”代码的认知会随时间变化。2000 年代被视为稳固的代码库，二十年后可能被认为过时。在快速变化的环境中——例如专注于验证商业模型的初创公司——速度往往胜过优雅。团队可能会有意承担技术债务，以快速交付 MVP。在这些情境下，“快速且脏”的解决方案是一种务实选择，而非无能的表现。

对心理安全的影响

研究始终表明，心理安全是高绩效团队的首要预测因素。使用严厉标签会：

1. 阻碍心理安全环境的建立。
2. 降低获得坦诚反馈的可能性。

这两种影响都会妨碍团队发挥全部潜力和生产力。

建议

1. 替换该短语

• 使用中性词汇，如 “suboptimal code” 或 “code that could be improved.”（可改进的代码）。
• 解释代码为何需要改进，并提出具体的改进步骤。

2. 直接处理问题

• 如果该术语让团队感到不适，进行一对一对话，讨论其影响。
• 鼓励一种文化，使反馈聚焦于代码本身，而非个人。

3. 促进建设性对话

• 强调批评应具体、可操作且尊重他人。
• 避免复杂的解决方案；简单的中性语言转变通常足够。

结论

“shitty code”这一表达有害，因为它不提供建设性指导且可能破坏心理安全。通过采用如 “suboptimal code” 之类的中性术语，并专注于明确、可操作的反馈，团队可以在保持尊重氛围的同时提升代码质量。保持中立，保持建设性，并优先营造开放讨论的安全环境。