摘要：你肯定有过这样的经历吧：项目经理问你预计完成的时间，你里想着 “两周就行”，嘴上却说 “三周吧，保险点”，可即便如此， deadlines 还是一次次失守... ...

你肯定有过这样的经历吧：项目经理问你预计完成的时间，你里想着 “两周就行”，嘴上却说 “三周吧，保险点”，可即便如此， deadlines 还是一次次失守... ...

去年，我开始对比自己和同事的开发速度，结果让我震惊。与和我资历相仿的开发者相比，我交付功能的速度大概是他们的 3 倍，当然我并没加班加点，也没用到大家都在聊的那些花哨 AI 工具。

一、“完美代码”的陷阱

我刚入行写代码时，觉得每个函数都必须经过完美测试，每个变量名得优雅得体，每个抽象概念都要清晰易懂，追求零 bug 和完美架构。这在理论上听起来无可挑剔，但实际操作中却并不灵光。

真实情况往往是这样的：花 3 个小时给变量命名，结果这变量都没活过下周；为某个功能搭建了精妙的抽象层，但是预想的第二个使用场景压根没出现；为一段代码写了详尽的测试，最后却发现这段代码解决的是个伪问题。

直到我在一场 24 小时的黑客马拉松里栽了大跟头，才彻底明白这个道理。我们团队花了 18 个小时搭建 “整洁的解决方案”，而获胜团队 6 小时就做出了能正常运行的软件。他们的代码乱糟糟的，到处是 TODO 注释，说不定还有不少 bug。但它能用-这就足够了。

那一刻我突然顿悟了，不同的项目，需要不同的质量标准。

如果是设计心脏起搏器的代码，每一行都必须完美无缺，因为它关乎生命；如果是周末练手的小项目，只要能验证想法就行。而大多数的项目都介于两者之间。现在，动笔写代码前我都会问自己一个问题：“这个项目“足够好”的标准是什么？”有时候，“足够好” 意味着 60% 的质量，比如我在测试某个想法时；有时候则需要 95% 的质量，比如开发付费使用的功能。但几乎从不需要 100%，因为 “完美” 是 “完成” 的天敌。

二、“草稿代码”的魔力

就像作家一样，他们不会一开始就写出完美的文章，先写个初稿（可能是糟糕的），再修改成佳作。但在编程领域，我们却总觉得应该一次写出完美代码。这似乎完全弄反了。

我的 “草稿代码” 可能糟透了，也许有 bug、测试通不过、TODO 注释满天飞。但为了省事，我复制粘贴代码，把该用变量的地方硬编码，还留着调试用的打印语句。但这种方法却很有效，是因为草稿能暴露 “未知的未知”，那些你一开始根本想不到的问题。如果一开始就追求完美代码，便只能基于不完整的信息做决策，你不知道哪些部分会很难实现，哪些功能会变更，真正的性能瓶颈又在哪里。而草稿能帮你快速摸清这些情况。

上个月我要做一个数据处理流水线，第一反应是设计一个优美、灵活的架构，能兼容所有数据格式。但我最终只写了个处理当前数据的杂乱脚本，只花了 2 小时，幸亏我这么做了，因为第二天需求就全变了... ...

现在我的工作流程是先写最丑但能解决问题的代码，确保它能正常运行，再找出需要优化的部分，只重构关键模块。这不是说直接把草稿交付出去，而是用草稿摸清问题本质后，再去构建真正的解决方案。

三、质疑一切，尤其是需求

有件事没人会告诉你：大多数需求都是可以协商的。

产品经理或客户常常会提复杂的需求，也许是因为他们没考虑过更简单的替代方案。虽然他们提出要 10 个不同的页面，但也许 2个就够了；他们想要处理只影响 0.1% 用户的边缘情况。以前我只会照单全收，现在我会主动问一下：“这两个页面能合并吗？”“这个边缘情况真的需要处理吗？”“支持 10 个条目而不是 1000 个行不行？”“我们能不能先上线简化版？”一般情况下，答案都是 “可以” 的。

上季度，有人让我做一个复杂的报表仪表盘，包含 15 种不同的图表。我没直接动手，而是问：“您想通过这些数据做什么决策呢？”结果发现，他们其实只需要知道销售额是涨是跌。而这个核心的问题只需要一个简单的折线图就解决了，而花费的工作量也就是原需求的零头。

最快的代码，是不用写的代码。但我并不是表达要无视需求，而是要理解需求背后的目标。通常，实现同一个目标，根本不需要那么多工作量。

四、专注是一种超能力

工作久了，慢慢会发现最大的效率杀手并不是打字慢或工具不好用，而是分心。本来在修 bug，瞥见旁边有段丑代码，就开始重构；然后觉得变量名能改得更好，又花时间调整；接着发现整个模块的结构都有问题…… 不知不觉可能4个小时过去了，最初的 bug 还没修好。

我们通常把这种情况叫做 “效率表演”：你觉得自己很忙，但根本没在核心任务上取得进展。解决的方法很简单：计时器 + 小额提交。

现在每个任务我都设 25 分钟计时器，时间一到就停手，无论完成度如何都提交代码。这迫使我先搞定核心部分。而且计时器会创造紧迫感，让我不会漫无目的地陷入重构迷宫，始终聚焦在要解决的具体问题上。如果还有剩余时间，再去清理代码。小额提交还能创造动力，每一次提交都让人感觉在前进。就算偶尔分心，计时器也会把我拉回来。还有个意外收获是我的代码质量反而提高了。当时间有限时，你会专注于真正重要的部分，而不是那些 “某天可能有用” 的东西。

这个方法虽然简单，但却很难实践，毕竟习惯的改变是非常困难的。

五、重要的技能

以上的策略固然有用，但真正能让你提速的绝对是技术能力，主要有以下几个方面吧。

1.读代码：这可能是最被低估的技能。能快速看懂现有代码，调试就会轻松得多 ，不用瞎猜，能直接定位问题。同时，看别人的解法也能让你更快成长。

2.数据建模：这一步值得慢下来。糟糕的数据库设计或数据结构会困扰你好几个月，这也是少数值得前期多花时间、后期能省大量功夫的领域。

3.脚本编写：这能让所有事都变快。我经常写小型 bash 和 Python 脚本，用来转换数据格式、生成模板代码、查找重复内容、清理文件。只要一件事要做超过两次，我就会写脚本自动化。

4.用调试器代替打印语句：打印调试看似更快，但真正的调试器能让你探索问题本身，而不是瞎猜该在哪加下一个打印语句。

5.卡壳时就休息：这听起来显而易见，做起来却很难。太多次，下午 5 点还觉得无解的问题，第二天早上 9点一看就有了答案。

六、真正的秘诀

速度来自少犯错，而非打字快。

多年来我一直思考如何提高速度，后来发现瓶颈从来不是打字速度或快捷键熟练度，而是能否做好 “该建什么” 和 “何时停手” 的决策。解决错问题的完美代码毫无价值，解决对问题的杂乱代码却很有用。所以，从草稿开始写起，质疑需求，聚焦核心任务，频繁交付小额修改。记住，“足够好” 往往就真的足够了。

管理者会对你的交付速度印象深刻，同事会好奇你是怎么做到的，而你也能有更多时间享受编程中真正有趣的部分。所以，秘诀是做对的事，并知道何时停手。

来源：不秃头程序员