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: 设计稳定后,对实际运行情况中出现的性能问题进行优化
经历这些阶段后,项目的进度和质量都会有一个比较好的结果。

上一篇:可以获取get post url 传递参数的统一方法


下一篇:如何在Ionic2项目中使用第三方JavaScript库