Make it run, make it right, make it fast

若是问我工做十多年后相比刚毕业参加的时候，学到了哪些重要的经验，那么“Make it work, make it right, make it fast”必定是其中最重要的经验之一。第一次听到这句话是从之前老板 @沈嵘 那里，而后发现是来源自大牛 Kent Beck 《Make It Work Make It Right Make It Fast》。这是软件项目开发的一条经典原则，实际上不限于软件开发领域，它把一个项目分红三个阶段，每一个阶段有不一样的侧重。

Make it work

在这个阶段，了解项目需求后，聚焦于项目所须要的最小需求，尽快让项目先跑起来，没必要过于追求设计和性能。同时，展现你的结果，并根据反馈快速调整。

这个阶段的重点在于需求的响应，以最快的速度实现需求。这是个快速试错，快速迭代，验证需求的过程。

Make it right

到了这个阶段，需求基本上已经稳定，要保证项目执行结果正确，更多的测试，尽量少的bug。但"Make it right"并不单单意味着只要结果正确就够了，还须要对系统进行重构，优化系统设计，让代码更简洁结构更清晰，易于扩展和维护。
这个阶段的重点在于保障系统的稳定，同时优化设计和重构。

Make it fast

当系统已经稳定，设计也趋于成熟的时候，还须要对系统进行性能上的优化，良好的性能，不只能够提高用户体验，同时也能下降运维的成本。这里的“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: 设计稳定后，对实际运行状况中出现的性能问题进行优化 经历这些阶段后，项目的进度和质量都会有一个比较好的结果。