程序员必看：让代码“活起来”的三步法则！

引言

---

大家好，这里是hikktn。
前些天，在粉丝群里有个大学生很焦虑。他说，自己简历上的项目一边写一边踩坑，设计一直在改，一直在优化，每样都要慢慢摸索。现在快毕业了，这个项目还没有完整做出来。

对于他的情况，我引用了一句名言来回复：“Make it work, make it right, and make it fast.” 这句著名的软件开发原则的字面意思是：把它做出来，把它做对，然后把它做快。

但这句话的重点不在于“work、right和fast”，而在于它们的先后顺序。所以，更准确的表达是：
“Make it work first, then make it right, and finally make it fast.”

不少人可能听过这个原则，甚至照着做，但未必深究过为什么要这么说。核心观点：“Know why, then know how.” 今天，我们就来剖析这个被认为是软件开发中最重要的原则。

---

项目进行中的误区

群里这位小哥的项目总是改了一半又改另一半，永远在重构、优化。表面上看，架构设计和代码质量似乎变得更好了，但实际上，项目并没有因此更接近完成，反而越走越远。

我看过许多简历，列出了各种炫酷的项目，但每次我都会问：

• 它做完了吗？
• 上线了吗？
• 被谁用过吗？

答案通常是：做完了，但没上线，也没有用户。这样的项目不能算真正完成，因为一个没有实际被使用的软件，根本没有生命。软件只有上线的那一刻，才是生命的开始。

写简历的建议： 如果你只是为了在简历里多列一些技术名词，还不如去背八股文，因为你没有让软件真正运行起来，也就无法体会技术在实战中的价值。

---

“Make it work” 是第一原则

只有在“Make it work”的基础上，才有资格讨论“Make it right”和“Make it fast”。有些人会问：“为什么不能直接从 right 开始？”
这就像“第七个包子”的故事——既然吃七个包子就能饱，为什么不直接吃第七个呢？

理论上可以一开始就做对，但实际很难，因为“正确”本身是动态变化的。

---

“正确”的三大决定因素

1. 认知范围：
   你的学习会不断接触新理论、新工具。例如，从直连数据库到 Connection Pool，再到 ORM，甚至缓存优化，每一种技术都会刷新“正确”的定义。

2. 行业动态：
   当前的“正确”往往是阶段性的。例如，前端技术更新频繁，不同社区对技术的接受度也不同。

3. 相对性：
   软件开发没有绝对的“正确”或“错误”，只有“更好”和“更差”。追求“足够好”即可，过度完美只会拖延整体进度。
   

---

关于“Make it fast”

大多数软件开发项目不会走到“Make it fast”这一步，因为：

• 优化从 10 秒到 1 秒，用户会明显感知；但从 1 秒到 900 毫秒，用户感知微弱。
• 性能优化往往被更高优先级任务（如修复 Bug、新功能开发）取代。

如果有幸进入“Make it fast”阶段，那么优化代码和架构才有实际意义。否则，只是在“千疮百孔”的基础上研究“回字的四种写法”。

---

总结与升华

“Make it work”是软件开发的生存需求，
“Make it right”是生活需求，
“Make it fast”是升华需求。

软件开发不是“一锤子买卖”，而是一个动态过程。希望今天的讨论能为大家打开思路，让你的编程再次伟大！

如果你觉得这篇文章对你有帮助，不妨点个「赞」支持一下，收藏以便日后参考，也欢迎留言分享你的看法！记得关注，带你解锁更多有趣内容！感谢你的支持，期待与你在下一篇相见！🙏