如果问我工作十多年后相比刚毕业参加的时候，学到了哪些重要的经验，那么“Make it work, make it right, make it fast”一定是其中最重要的经验之一。第一次听到这句话是从以前老板 @沈嵘 那里，然后发现是来源自大牛 Kent Beck 《Make It Work Make It Right Make It Fast》。这是软件项目开发的一条经典原则，实际上不限于软件开发领域，它把一个项目分成三个阶段，每个阶段有不同的侧重。
在这个阶段，了解项目需求后，聚焦于项目所需要的最小需求，尽快让项目先跑起来，不必过于追求设计和性能。同时，展示你的结果，并根据反馈快速调整。
这个阶段的重点在于需求的响应，以最快的速度实现需求。这是个快速试错，快速迭代，验证需求的过程。
到了这个阶段，需求基本上已经稳定，要保证项目执行结果正确，更多的测试，尽可能少的bug。但"Make it right"并不仅仅意味着只要结果正确就够了，还需要对系统进行重构，优化系统设计，让代码更简洁结构更清晰，易于扩展和维护。
这个阶段的重点在于保障系统的稳定，同时优化设计和重构。
当系统已经稳定，设计也趋于成熟的时候，还需要对系统进行性能上的优化，良好的性能，不仅可以提升用户体验，同时也能降低运维的成本。这里的“fast”，不仅体现在程序的性能，也包括对整体项目流程效率的提升，例如自动编译、自动部署的工具或脚本，如果前期没有做，那么这时候就要加上了。
这个阶段的重点在于系统的性能优化，包括项目流程效率的优化。
“Make it work, make it right, make it fast” 这个原则拆开来很好理解，但这三个阶段不是孤立的，而是一个整体，同时又是有先后次序的。
在我初学编程的时候，要达到Make it work也并不是太难的事情，网上找些开源项目，参考书上的教程，总能把一个不算太复杂的项目搭出来，但却没有能力去make it right，更没有办法去make it fast。最终的结果就是做出来的项目难以维护，性能低下。
在我学了一段时间编程后，懂了一些设计模式，了解了一些性能优化的办法，于是开始直接省略第一步，首先考虑的是“Make it fast”，假想系统有超大用户超大访问量，然后考虑的是“Make it right”，设计的时候为了设计模式而设计模式，恨不得把所有设计模式应用个遍，最后再想着"Make it work"，但这时候因为前期的过度设计，系统复杂而臃肿，要让它work，简直是太难了，最终就是开发频繁延期，甚至难产，做出来的程序也难以维护。
经过这么多年的磨炼，现在大到项目，小到具体功能，在每个版本都会尽可能的按照这个原则来实行：
Make it work: 首先最低限度满足项目需求，将初步结果拿出来演示，根据反馈快速调整
Make it right: 需求稳定后，对代码进行重构，良好的设计，易于维护和扩展
Make it fast: 设计稳定后，对实际运行情况中出现的性能问题进行优化
经历这些阶段后，项目的进度和质量都会有一个比较好的结果。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。