專案開發總結

有時候一些奇怪的想法會突然出現在腦海中，那一瞬間彷彿有所領悟

本篇中所分析的所有內容都是以中小型專案為前提的，ios，android，server這3端開發人數不超過20人。由於我本身是做ios的，因此，會從乙個ios開發者的角度來剖析問題。不一定百分百正確。

因此，需要有乙個方案上的設計，這個設計的主要目的就是處理專案中產品方面的臨時變更。

在真實開發中，最經常出現的乙個場景就是遇到這訪問的問題去問產品，產品當時記住了，可能過段時間就忘了。這些產品方面的問題最少喲通知到跟該專案開發相關的所有人，如果到了測試階段，還需要修改互動設計，那麼上述的設計就是有問題的。

產品設計是開發前期最重要的乙個環節，假定我們已經有了乙個良好的設計，那麼接下來，需要讓專案開發的相關人員對必須對產品有乙個清楚的了解。

還是那句話，在這個階段，讓開發人員把問題精確到每乙個if上，肯定不現實，但通過大家的頭腦風暴後，大部分隱藏的問題和衝突都能被發現。

後台開發應該和移動端開發共同制定乙份資料互動規則。

說點題外話，我一直覺得不管是寫後台還是移動端，整體框架的良好設計能夠給程式帶來巨大好處。每個人寫**的風格千差萬別，有的時候同乙份資料需要建立好幾個模型，這幾個模型大部分的屬性都是相同的，想想，這對於開發和**優化會帶來多大的阻力。

我個人認為，如果後台開發，以模型為單位組織資料，會給移動端開發帶來極大的便利性。最好有乙個人能夠專門維護乙個屬性池，大家所有的屬性都在這個池子裡獲取，從而就能夠避免各種衝突了。

簡單說說ios端的設計，基本的檔案目錄結構的設計，咱們就不提了，這都是最最基本的要求。網路層的設計也不提，每個公司都會有這方面的封裝庫。我們首先來**下模型的設計：

最單純的模型就是用來儲存資料和提供資料的。如果控制器中的邏輯很複雜，最好寫乙個處理控制器與資料模型邏輯的管理類，資料的處理全都封裝在這個管理類之中，控制器拿到處理好的處理，去輕鬆的完成他的任務。上邊的管理類是乙個核心思想，相信有經驗的開發者應該明白。

對於儲存的設計應該有乙個統一的類去管理，資料的持久化不應該隨隨便便的散落在**中的各個角落。這個管理類負責了資料儲存的讀取和寫入，以及穩定性的考驗。

除了網路，模型，儲存，就剩下控制項的設計了，控制項的設計就一句話，把你寫的每乙個控制項都當做乙個小的元件來寫。每乙個控制項都不應該是僅僅基於當前的乙個小的需求考慮的，最起碼從其他開發人員也會使用這個角度去考慮問題。

在真實開發中，我發現乙個小小的問題，即使元件的介面寫的很簡單，別人也不一定會用，因此，這些元件應該需要乙份文件來描述它的使用方法，乙個很好的例子就是github。

上邊描述的種種都是基於理論方面的內容，需要在開發中慢慢體會。

根據每個人的個人能力，把不同的模組，不同的功能指定給合適的開發人員。

我個人認為能夠處理好上述的問題的人選一定是架構師，乙個良好的設計，乙個高度可維護的設計都應該是架構師必備的技能包。

但我認為，在開發中讓所有的人的技術提高是一件很難的事情，正是由於技術水平的不一樣，才產生了開發中的各種障礙，這裡就不多說了。

通過這個專案，我個人得到的領悟就是設計非常重要。