很多朋友不同意我的意見，其實我想表達的是一個先后順序的問題， 并非是重要程度。好的產(chǎn)品能讓技術(shù)重要起來.

做項目，特別是創(chuàng)業(yè)項目,  實現(xiàn)好的點子總是一件令人抓狂的事情。明明非常有經(jīng)驗，為什么還是總延期呢？看上去沒有技術(shù)難度，卻很容易陷入到實現(xiàn)細節(jié)中出不來呢。這幾天想了很多，基本上筆者總是遇到下面一個循環(huán)：

• 關(guān)于某個功能，有了一個好點子
• 開始實現(xiàn), 但是很快發(fā)現(xiàn)在細節(jié)上要做的東西貌似比較多
• 于是開始設(shè)計復(fù)雜的對象關(guān)系和結(jié)構(gòu), 希望通過代碼把它們管理起來. "以后好擴展"(很多人的口頭禪)
• 但是...發(fā)現(xiàn)點子需要調(diào)整， 設(shè)計上有變化。
• 發(fā)現(xiàn)明明只是小調(diào)整, 卻要改很多地方, 大量的"以后好擴展"的設(shè)計完全用不上了?
• 直接重新開始寫代碼, 但是不知不覺又慢慢滑入步驟3的流程中.

這個循環(huán)，很明顯會浪費掉寶貴的時間。如果是創(chuàng)業(yè)的小團隊，更是耗不起，但是為什么會這樣呢？直觀的看：這是過度設(shè)計。但是這個錯誤背后，我覺得有一個更大的錯誤：在好產(chǎn)品還不存在的情況下就開始追求好代碼

這是一個錯誤嗎? 我想很多人可能不會同意。 但是仔細想一下， 它很有可能是！ 特別是在時間緊迫的情況下。 我的理解是這樣：好代碼的用處不是為了自娛自樂, 而是為了方便修改, 應(yīng)對變化.  但這一切都有賴于產(chǎn)品細節(jié)的支撐, 可惜的是, 初創(chuàng)的產(chǎn)品細節(jié)可以認為是最不穩(wěn)定的.  沒有它們做支撐. 強求好代碼,  結(jié)果多半是一些設(shè)計模式/經(jīng)驗?zāi)Ｊ降亩哑?  寫起來很爽,  過期得更快. 畢竟我們?nèi)祟惖闹橇κ强偨Y(jié)經(jīng)驗， 而不是預(yù)測未來。

結(jié)論： 對于創(chuàng)業(yè)的團隊來說, 最重要的東西不一定是***先的，就算技術(shù)是核心競爭力，代碼雖然重要，但是必須得先有好產(chǎn)品，等產(chǎn)品相對靠譜了，再仔細設(shè)計你的技術(shù)架構(gòu)吧

原文鏈接：http://www.cocoachina.com/gamedev/misc/2013/0628/6496.html