正文
大多數開發者都會對自己編寫的代碼有嚴格的要求，希望它結構清晰，易於閱讀、易於拓展，優雅、健壯、且不會有bug...
這種追求本是好的，首先，是對項目的負責任，其次，從長遠來看，它有利於開發者提升自身的技術。
但大多數時候，我們沒有把握好時機。我們總是在產品的研發初期就刻意追求那種高質量。在經歷了許多次挫折後，我想告誡各位，這種做法是錯誤的！（至少對於獨立開發者來說）
首先，在產品研發的初始階段，我們甚至連需求都無法確定下來，哪來的依據去編寫優秀的代碼，辛辛苦苦編寫的或許只是海市蜃樓。
其次，在產品研發的初始階段，會有許多次迭代：第一次編寫原型、第一次測試、第一次修改；接着又第二次原型、第二次測試、第二次修改...如此反覆多次。試想一下，如果每次迭代，都花費大量時間在代碼上（最終很可能會被刪除的代碼），那這個產品的成型就會遙遙無期了。
可能有讀者會問，在初期是不是就可以完全無視代碼質量？
當然不是。我們仍需要憑藉經驗和直覺，先用最簡單的方式去實現原型。而不用刻意去想得太長遠（數據結構、數據庫、算法什麼的，可以滿足當前原型就行了）。
當你覺得某部分代碼，因爲設計不當，放緩了開發的速度，你就得去重構這部分代碼。
隨着原型的不斷迭代，需求逐步清晰。每次原型的迭代也伴隨着代碼的刪除、局部重構。你會驚喜的發現心中對代碼的模樣也會變得愈加清晰。
慢慢的，在產品接近上線時，可以稍微向“長遠”去考慮了。
總結
在寫出高質量代碼之前，讓我們先把程序運行起來吧！
代碼是實現目標的一種工具，它不是目標本身，我們的目標是解決問題，實現需求。當你寫的代碼無法滿足需求的時候，它質量再高，也毫無用處。（另外需要考慮的是，一段沒有解決任何問題的代碼，用什麼依據來評價它的質量呢？）
相關書籍
《遊戲設計藝術（第2版）》，包含了許多遊戲設計、研發的指導。 豆瓣評分 9.2
《遊戲編程模式》 裏面介紹了遊戲開發的編程模式，但同樣適合非遊戲開發借鑑。在閱讀該書的時候，可以體會到，每一種模式都有自己的優缺點，沒有完美的代碼，明顯的優點同時也會帶來明顯的缺點，重點在於“權衡”，找到適合當前使用場景的方案。 豆瓣評分 8.8