正文
大多数开发者都会对自己编写的代码有严格的要求，希望它结构清晰，易于阅读、易于拓展，优雅、健壮、且不会有bug...
这种追求本是好的，首先，是对项目的负责任，其次，从长远来看，它有利于开发者提升自身的技术。
但大多数时候，我们没有把握好时机。我们总是在产品的研发初期就刻意追求那种高质量。在经历了许多次挫折后，我想告诫各位，这种做法是错误的！（至少对于独立开发者来说）
首先，在产品研发的初始阶段，我们甚至连需求都无法确定下来，哪来的依据去编写优秀的代码，辛辛苦苦编写的或许只是海市蜃楼。
其次，在产品研发的初始阶段，会有许多次迭代：第一次编写原型、第一次测试、第一次修改；接着又第二次原型、第二次测试、第二次修改...如此反复多次。试想一下，如果每次迭代，都花费大量时间在代码上（最终很可能会被删除的代码），那这个产品的成型就会遥遥无期了。
可能有读者会问，在初期是不是就可以完全无视代码质量？
当然不是。我们仍需要凭借经验和直觉，先用最简单的方式去实现原型。而不用刻意去想得太长远（数据结构、数据库、算法什么的，可以满足当前原型就行了）。
当你觉得某部分代码，因为设计不当，放缓了开发的速度，你就得去重构这部分代码。
随着原型的不断迭代，需求逐步清晰。每次原型的迭代也伴随着代码的删除、局部重构。你会惊喜的发现心中对代码的模样也会变得愈加清晰。
慢慢的，在产品接近上线时，可以稍微向“长远”去考虑了。
总结
在写出高质量代码之前，让我们先把程序运行起来吧！
代码是实现目标的一种工具，它不是目标本身，我们的目标是解决问题，实现需求。当你写的代码无法满足需求的时候，它质量再高，也毫无用处。（另外需要考虑的是，一段没有解决任何问题的代码，用什么依据来评价它的质量呢？）
相关书籍
《游戏设计艺术（第2版）》，包含了许多游戏设计、研发的指导。 豆瓣评分 9.2
《游戏编程模式》 里面介绍了游戏开发的编程模式，但同样适合非游戏开发借鉴。在阅读该书的时候，可以体会到，每一种模式都有自己的优缺点，没有完美的代码，明显的优点同时也会带来明显的缺点，重点在于“权衡”，找到适合当前使用场景的方案。 豆瓣评分 8.8