独自驻场的 FDE，为什么该读《程序员修炼之道》

《程序员修炼之道》（The Pragmatic Programmer）开篇不久有一节叫“我的源码被猫吃了”（The Cat Ate My Source Code）。前线部署工程师（FDE）在客户面前恰恰不能找这种借口，因为现场没人会替你担责。

这本书由 David Thomas 和 Andrew Hunt 合著，1999 年 10 月首次出版。出版社明确列出的要点之一，是对自己的工作和职业负责。这也是 FDE 独自面对别人的系统时，首先要学会的事。

如果你是有两到八年经验的开发者，正考虑转做 FDE，这本书值得排在许多技术书之前读。它不教工具，只教习惯，而独自工作时能否扛住，靠的正是习惯。

建议读的版本是 The Pragmatic Programmer, 20th Anniversary Edition: your journey to mastery（Addison Wesley，2019 年 9 月，320 页）。这一版是重写，新增了提示和主题，全书都有修订。这本书并不构建系统理论，而是汇集了许多简短的建议，不绑定任何语言、框架或方法论。

观点一：提供选择，而非借口

FDE 用得最多的一条提示，大概是“提供选择，而非借口”（Provide options, not excuses）。它把上面说的“负责”落到了具体行动上。

设想一个场景：客户希望周五前让一个智能体读完全部扫描合同档案，但较早的扫描件光学字符识别（OCR）效果很差。如果你只说“数据太差，赶不上”，那就是在找借口。

带着三个选项去谈就不一样了：只处理较新的扫描件；全部处理，但把低置信度结果标出来交给人工复核；或者把截止日期推迟一周，先清洗数据。这时你是在帮客户做决定。

每遇到一次这样的情况，就在工作日志里记下来，每次大约三行。

面试时，这条日志可以改写成 STAR 回答。情境（Situation）：扫描合同档案过旧，赶不上演示截止日期。任务（Task）：周五前交付结果。行动（Action）：提出三个方案，并说明各自的代价。结果（Result）：客户选择人工复核方案，演示如期进行。

对应的简历条目可以写成：“旧扫描件阻碍试点时，提出三种范围取舍方案；在原定演示日期交付人工复核方案。”这样一行字既体现了决策，也体现了结果，而不只是罗列用过的技术。

观点二：不留破窗，即使在别人的系统里

书的前部有一节叫“软件的熵”（Software Entropy），由此引出提示“不要留破窗”（No broken windows）：看到糟糕的设计或代码，立即修复。Dan Lebrero 的总结把它编为第 5 条，其他总结的编号有所不同。

对 FDE 来说，难点在于破窗通常在客户的系统里。假设你发现一个抽取、转换、加载（ETL）脚本里硬编码了密码。

你可能还无权修改，但应当记下来，告诉负责人，并在当天提出修复方案。第一处破损没人理，后面的破损就更容易被忽视。

观点三：第一周就做出曳光弹

Lebrero 总结中的第 20 条是“曳光弹”（Tracer Bullets），也叫行走骨架（walking skeleton）。做法是先搭一条贯穿整个系统、端到端跑通的细路径，再逐步充实各个部分。

放到客户现场，意思是第一周就要让一种文档类型走完全程：从上传，到客户自己屏幕上出现答案。

在真实数据和真实基础设施上运行，能尽早暴露防火墙、访问权限、特殊格式之类的问题。等到第六周才发现，就太晚了。

用错了会怎样？

这三个习惯很容易只做一半。最常见的错误是给出选项却不说代价：“全部处理但做标记”听起来不错，可如果不说明谁来复核、要花多少小时，客户仍然没有足够信息做选择。

第二个错误是未经许可就修客户的破窗。直接给那个 ETL 脚本推补丁，可能弄坏一个你不知道的任务，好心变成事故。在别人的系统里，“立即修复”应当理解为立即报告、立即提出修复方案。

第三个错误是在样例数据或自己的机器上做曳光弹。这样它就不再是曳光弹了，因为它恰好绕开了你需要尽早发现的问题。

应该按什么顺序读？

先通读“务实的哲学”（A Pragmatic Philosophy）。这部分共七个短节，从对职业负责、不找借口，到软件的熵，再到够好的软件、知识组合和沟通。客户想在过短的时间里拿到完美结果时，“够好的软件”（Good-Enough Software）一节尤其有用。

接下来，在接手第一个项目前，读关于曳光弹的部分。开始和客户团队合作后，再读“务实的项目”（Pragmatic Projects），这部分讲团队协作和让用户满意。

“做变革的催化剂”（Be a Catalyst for Change）这条提示适合这个阶段：与其强迫客户团队改变工作方式，不如让他们看到新方式是什么样子，让他们自己想改。

最后是“定期投资你的知识组合”（Invest Regularly in Your Knowledge Portfolio）。每个 FDE 项目都逼你学一个新领域，所以要把记录所学当作定期投资，而不是等有空再做。

这本书最值得重读的时候，正是你最需要它的时候：独自站在别人的系统前，需要一个比“我的源码被猫吃了”更好的回答。