游戏行业程序员的期望与职业建议：如何成为顶尖开发者

Game Developers Conference

演讲开场与主旨 [0:06]

• 演讲者Mike Acton以“所有观看此视频的人都被解雇了”的挑衅性开场白，迅速吸引了观众的注意力，并表明这将是一场“吐槽模式开启”的演讲。
• 他表示，在与许多声称是专业人士的程序员打交道后，发现其中许多人未能达到他认为的“最低标准”。
• 演讲的核心将围绕这些未达标之处展开，通过50个“是/否”问题来评估开发者的技能和思维方式。
  • 观众需要统计自己回答“是”的数量，并在演讲结束时进行评估。
  • 强调这50项只是样本，并非详尽无遗的个人不满列表。

核心开发技能与问题 [1:14]

• 1. 准确阐述问题 [1:14]
  • 许多程序员在埋头编码时，无法清晰地说明自己正在解决的具体问题。
  • 这导致在团队中产生“噪音”，浪费时间和资源。
• 2. 能够清晰地阐述正在解决的问题 [1:54]
  • 不仅自己知道，还能向他人准确表达。
  • 缺乏有效沟通会导致团队理解偏差，交付不符需求的产品。
• 3. 能够阐述问题解决的重要性 [2:48]
  • 许多人投入时间解决的并不是真正重要的问题，导致无价值的努力。
• 4. 能够阐述问题解决的价值 [3:23]
  • 任何问题都有解决的价值上限，不能无限投入时间。
  • 开发者需要能够量化解决问题所需的投入（人力、时间、精力）。
• 5. 具备B计划 [4:05]
  • 在解决方案可能失败时，是否提前制定了B计划。
  • 未提前准备B计划会在项目临近截止日期时造成巨大压力和混乱。
• 6. 已实施B计划 [4:54]
  • 最好提前实施B计划，作为安全网，增加团队信心。
  • 有时B计划本身就足够好，甚至无需继续A计划。
• 7. 明确解决当前问题的步骤 [5:44]
  • 无法明确解决问题的步骤是导致卡壳和效率低下的根本原因。
  • 需要花时间列出并理解所需的具体行动。
• 8. 清晰阐述未知和风险 [6:19]
  • 许多预估不准确是因为未能清晰识别项目中的未知因素和潜在风险。
  • 无法识别这些因素，就无法给出合理的预估。
• 9. 及时沟通时间问题 [6:57]
  • 当出现延误时，是否立即与团队沟通，而不是自行承担并希望“补回时间”。
  • 及时沟通可以避免问题扩大，减轻团队整体压力。
• 10. 编写并多次使用框架 [7:51]
  • 编写的框架应能多次用于实际解决预定问题，而非仅仅是推迟问题给他人。
• 11. 阐述完成测试 [8:28]
  • 如何判断一个问题已经解决？需要有明确的测试标准。
  • 模糊的完成标准会导致无休止的优化和不确定性。
• 12. 阐述问题相关的假设并如何证伪 [9:03]
  • 需要主动思考如何证明自己的假设是错误的，而非仅仅关注如何证明其正确。

系统设计与优化 [9:46]

• 13. 阐述延迟需求 [9:46]
  • 了解系统各部分数据所需的延迟时间，避免不必要的即时性要求。
• 14. 阐述吞吐量需求 [10:31]
  • 明确系统需要处理的数据量和速率，避免过度设计或不足。
• 15. 阐述最常见的使用案例 [10:58]
  • 了解系统的主要应用场景，确保设计符合实际需求，避免不必要的通用性。
• 16. 了解数据实际值 [11:43]
  • 清楚地知道数据在实际使用中的典型值，避免对数据范围的错误假设。
• 17. 了解数据可接受范围 [12:17]
  • 定义数据可接受的上下限，确保系统的健壮性和正确性。
• 18. 阐述超出范围数据处理 [12:50]
  • 当出现超出可接受范围的数据时，系统应如何响应，而不是寄希望于永远不会发生。
• 19. 清楚了解输入数据并按可能性排序 [13:33]
  • 能够列出并按可能性排序系统可能接收的输入数据，有助于优化处理流程。
• 20. 了解数据变化频率 [14:06]
  • 明确数据实际变化的频率，避免不必要的频繁计算或更新。
• 21. 阅读硬件、平台和工具文档 [14:27]
  • 至少部分阅读并理解常用硬件、平台和工具的文档，以避免低级错误和提高效率。
• 22. 观察实际用户使用系统 [15:06]
  • 亲身观察用户如何使用自己的系统，了解其痛点和实际工作流程。
• 23. 了解用户工作流程中最慢的部分 [15:25]
  • 识别用户工作流程中的瓶颈，以进行有针对性的优化。
• 24. 了解用户有效使用解决方案所需的信息 [15:53]
  • 确保用户获得足够的信息来高效使用系统，而非盲目期待。
• 25. 阐述硬件集合对系统设计的影响 [16:09]
  • 明确设计解决方案所针对的硬件范围，并理解硬件特性如何影响设计决策。
• 26. 阐述硬件如何具体影响设计 [16:31]
  • 深入理解特定硬件特性（如SIMD、FPU）如何具体指导系统设计。

调试与团队协作 [17:06]

• 27. 最近分析了系统性能 [17:06]
  • 定期对系统性能进行分析，了解其运行状况，而不是一劳永逸。
• 28. 最近分析了内存使用情况 [17:20]
  • 定期检查内存使用情况，避免内存泄漏和过度消耗。
• 29. 使用多种分析方法来衡量系统性能 [17:29]
  • 不仅限于FPS等单一指标，而是利用多种工具和方法全面评估性能。
• 30. 了解如何在不改变输入/输出接口的情况下显著提高系统性能 [18:00]
  • 具备在不破坏现有接口的前提下进行内部优化的能力。
• 31. 知道如何调试失败的实时发布版本 [18:46]
  • 即使在生产环境中，也应具备有效调试故障的能力。
• 32. 了解解决方案读取的数据及其来源 [19:18]
  • 清晰地知道系统读取哪些数据，以及这些数据的来源，以便进行并行化等优化。
• 33. 了解读取不必要数据的频率 [19:43]
  • 识别并减少读取冗余数据的频率，提高内存带宽利用率。
• 34. 了解写入的数据及其用途 [20:21]
  • 清楚地知道系统写入哪些数据，以及这些数据被何处使用，以便进行优化。
• 35. 了解写入不必要数据的频率 [20:40]
  • 识别并减少写入冗余数据的频率，提高系统效率。
• 36. 阐述内存中所有数据布局 [21:07]
  • 了解所有数据在内存中的具体布局方式，而非依赖“神奇的内存管理”。
• 37. 从不使用“平台无关”一词 [21:40]
  • 认识到真正的平台无关几乎不存在，应具体考虑不同平台的特性。
• 38. 从不使用“未来可证明”一词 [21:47]
  • 认识到预先解决所有未来问题是不可能的，更应关注当前和近期问题。
• 39. 能够良好地安排自己的时间 [22:03]
  • 具备有效的自我时间管理能力。
• 40. 警惕不浪费他人时间 [22:21]
  • 懂得何时寻求帮助，何时独立解决，避免成为团队的瓶颈。
• 41. 积极寻求建设性反馈并认真对待 [22:48]
  • 主动倾听并根据反馈改进，而不是回避或置之不理。
• 42. 不主动避免任何不舒服的（专业）对话 [22:58]
  • 敢于直面问题和挑战，进行必要的艰难对话。
• 43. 始终以专业态度与他人互动 [23:19]
  • 保持专业的沟通和协作方式，即使在压力之下。
• 44. 能够阐述他人对自己的期望 [23:38]
  • 清楚地理解团队对自己的职责和产出的期望。
• 45. 无需多次提醒即可响应或完成工作 [23:50]
  • 具备责任感和执行力，按时完成任务，无需反复催促。
• 46. 适时回馈社区 [24:03]
  • 积极参与社区，分享经验和代码，贡献自身价值。
• 47. 积极为同事带来价值 [24:17]
  • 在团队中发挥积极作用，帮助他人，共同进步。
• 48. 积极确保代表性不足的声音被听到 [24:36]
  • 促进包容性，确保所有团队成员的声音都能被听到和重视。

评估与总结 [25:14]

• 评分标准：
  • 0-20分：被解雇 (Fired)
  • 21-40分：被解雇 (Fired)
  • 41-49分：被解雇 (Fired)
  • 50分：达标 (Thumbs up)
• 演讲者强调，这些只是对游戏开发者最低限度的期望，并非高标准。
• 鼓励所有开发者反思并提升这些基本技能。