Folklore in Software Engineering: A Definition and Conceptual Foundations
本文通过将文献综述与对12位瑞典从业者的访谈相结合，定义并刻画了软件工程民俗，从而建立了一个概念框架，用以理解非正式叙事、神话和启发式方法如何塑造开发社区内的职业身份、价值观和集体知识。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，一个软件开发团队不仅仅是一群编写代码的人，而是一个生活在数字村庄里的现代部落。就像古代部落有关于雷电为何发生的传说、确保丰收的仪式以及只有长者才懂的笑话一样，软件工程师也有他们自己的文化产物。
这篇题为**《软件工程中的民俗》（Folklore in Software Engineering）的论文指出，软件团队充满了“民俗”**：这些故事、神话、内部笑话和不成文的规则通过走廊闲谈、咖啡休息时间和入职培训，而非通过官方手册，在人与人之间传递。
以下是作者的研究发现，并使用简单的类比进行了说明：
1. 什么是“软件民俗”？
将民俗想象成团队的**“不成文规则手册”**。
- 官方手册就像政府法律：清晰、成文，并且应该被严格遵守。
- 民俗则像是“村里的八卦”或“家族传奇”。它是人们实际相信并践行的内容，即使这些内容与官方规则相抵触。
作者将其定义为非正式传播的故事和捷径（启发式方法），这些东西塑造了开发者如何看待自己、他们重视什么以及他们如何协作。这是这一职业的“文化底蕴”。
2. 软件民俗的三大主要成分
研究人员将这种民俗分为三个主要类别，并引用了对 12 位经验丰富的瑞典软件专业人士的研究案例：
A. 神话与传说（“夸张的故事”）
这些是每个人都相信是真的故事，即使它们并没有硬数据支持。
- “10倍开发者”的传说： 存在一种持久的信念，认为一个超级天才程序员的价值相当于十个普通程序员。论文指出，这通常是一个用来解释项目成功或失败原因的神话，但很少得到证实。
- “无 Bug”的承诺： 一个普遍的信念是，如果你完美地遵循特定的流程（例如检查清单），软件就会神奇地没有任何 Bug。实际上，Bug 仍然会发生，但这个故事依然存在，目的是给管理者一种掌控感。
- “新技术更好”的炒作： 即认为最新的技术或框架自动优于旧技术，仅仅因为它很新，而不考虑它是否适合特定的问题。
B. 仪式与实践（“典礼”）
这些是具有比“完成工作”更深层含义的重复性动作。
- 每日站会（Daily Stand-up）： 官方层面，这是 15 分钟的同步会议。从民俗角度看，它可能变成一种向老板展示“我正在工作”的表演，或者是增强团队凝聚力的社交纽带。
- “门槛检查”（The Tollgate）： 在项目进入下一阶段之前进行评审的会议。有些团队将其视为一种神奇的仪式，即通过它，“事情就会自然顺畅”，即便之前的开发过程一团糟，软件也会突然变得好用。
- 用甜点为冲刺命名： 一些团队会用饼干或蛋糕来命名他们的工作周期。如果达成了目标，他们就能获得奖励。这把压力巨大的截止日期变成了一场共享的游戏。
C. 器物与幽默（“内部笑话”）
这包括带有文化意义的迷因（Memes）、笑话和实物。
- 迷因（Memes）： 论文提到了像“这很平常”（一只坐在着火房间里的狗）这样的迷因，开发者用它来表达虽然身处混乱，却假装一切如常。
- “凌乱的桌面”： 有一种观点认为，凌乱的桌面是荣誉勋章，显示出开发者正处于深度思考中。
- 测试是一种负担： 一个常见的笑话是，与“令人兴奋”的编码工作相比，测试是一项枯燥、乏味的琐事。这个笑话强化了“测试人员不如开发者重要”的观念。
3. 这些民俗是如何传播的？
论文解释说，这些知识并不通过教科书传播，而是像病毒或篝火旁的传说一样传播：
- 入职培训： 当新人加入时，他们不仅阅读手册，还会听到资深员工讲述的“战争故事”。
- 饮水机旁（Water Cooler）： 故事在茶歇室、午餐时间以及聊天频道中交换。
- 导师制： 高级开发人员教导初级开发人员的方式不仅是回答问题，还包括告诉他们：“我们 20 年前尝试过那个，结果失败了”，却并不解释具体原因。
4. 为什么这很重要？
作者认为，我们不应忽视这些民俗，而应开始研究它们。
- 好的方面： 民俗可以是一种有益的捷径。它能帮助新人比阅读手册更快地了解特定公司的“真实”运作方式。它能建立团队认同感，并通过幽默帮助人们应对压力。
- 坏的方面： 民俗也可能带来危险。如果每个人都相信一个神话（比如“测试是浪费时间”），他们可能会做出损害产品的错误决策。它还可能阻碍团队尝试新的、更好的方法，因为“我们曾经试过，但没成功”（即便当时的情况完全不同）。
核心结论
论文总结道，软件工程民俗是定义软件团队运作方式的非正式共享的故事、信仰和仪式。
正如历史学家通过研究神话来理解一种文化一样，软件研究人员和管理者也应该研究这些“软件神话”，以理解团队为何做出那些决策。通过让这些隐形的叙事变得可见，团队可以在保留有益传统（如建立士气的良好内部笑话）的同时，挑战有害的神话（如认为某些人天生就比别人强 10 倍的观念）。
简而言之： 软件不仅仅关乎逻辑和代码；它也关乎我们围绕代码所讲述的故事。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。