space的終結

space不做了，辛辛苦苦coding了兩個月的space不做了。我想原因很複雜，這裏不用多說，還是自己總結一下自己的得失吧。 雖然space最終流產，但是我從中學到很多的東西。現在就簡要的說幾點。 一、需求分析的重要性 需求分析的重要性，在本科時老師都講爛了，可能正因爲在本科就講爛了，所以在實際的項目中才會如此。其實需求分析說白了還是交流問題，產品和研發的交流，我想說沒有那個產品能在最初就能把需求給全搞完，並把需求給定死了，所以二者之間的交流至關重要。 但是我還發現一個問題，在基本需求出來後發現一些需求實現起來有問題（這裏的問題不是能不能實現的問題，而是代價的問題），這就會有問題，你說需求提得不合理？不是吧，去改需求？這個情況最終的結果是，可能按照原需求繼續高代價coding，修改需求再coding，我遇到的情況往往是第一種。很不爽！ 二、團隊代碼的公用 畢竟項目不是一個人在開發，大家不可能自己悶着頭寫不顧其他人的代碼。大家代碼之間的重用就很重要，怎樣讓大家彼此知道對方的code，定時的交流、統一的交流平臺、及時更新的文檔、共用的整合、等等。 三、代碼的效率 大型產品對效率要求的很高，怎樣在高訪問量高併發的情況下保持系統的可用，效率。我感覺代碼重用和效率有時候是有矛盾的，人們不可能把所有的情況都給封裝起來，有時需要一個頁面就有一個策略在後臺支持，你想重用？還是先想好吧。單個功能單個底層有時不失爲一種好的策略。 四、不要小看前臺 大家視乎都感覺前臺是很easy的工作，比如我事先已經把某個功能給做出來了，等真正開始應用時你會發現很多意想不到的事情，條件不能滿足、新的功能的增加、甚至頁面位置的改變都會給這個應用產生影響。功能做出來了？原來離應用還早着呢。 五、一個成熟的產品不是一蹴而就的。over