我們以一個APP成功上線，作爲思考的起點，往前推，看看我們需要做些什麼？
1一個99美元的開發者帳號 嗯，如果不需要真機跑程序，這個可以是最後一步。當然早早買個開發帳號，好處會非常大，看到自己的程序在真機上跑，整個人都興奮起來，就不用老喝雞湯。
2一個App包 當然，這纔是真正難點。所以這裏會有大量的細分步驟。
1)異常控制 在所有數據都沒有問題之後，我們需要反覆用各種奇葩操作來把應用搞崩潰，或者把數據搞亂，看看會有哪些異常。除此之外，在設計的過程中，也需要處理一下，現實中不大可能出現的，自己能想象出來的異常情況。
2)聯調數據 在所有色差都調整過來之後，我們需要切換到線上環境(或稱生產環境)進行真實數據聯調。這一步主要的工作不在iOS端，而是推送數據的後端。iOS開發，主要是協助後端發現計算或算法或接口問題。
3)適配色差 在完成第一套界面之後，我們需要找不同型號的終端來檢驗屏幕適配和色差調整。一般的情況，會讓設計師出全套分辨率的圖標、大圖，和給顏色的具體色值。如果做得徹底一點，可以根據不同的設備在代碼上使用不同的色值。
4)切圖界面 在實成性能調優之後，我們需要開始讓App向“最後樣子”靠攏。我們需要設計師給我們一套切圖，包括圖標、背景、啓動頁大圖，甚至色值等。 然後，我們開始做界面，把該加的Image都加上，把該有的動畫效果都加上。在這個過程中，如果有些效果自己不熟悉，可以先做一版勉強可看的，在這個基礎上再繼續優化。要保證，至少能用得上，不至於太慘不忍睹。
5)重用性能 在所有視圖都做完之後，我們可以從重用和性能的角度把代碼重構一遍。當然最理想的狀態就是動手之前先考慮好怎麼重用怎麼優化性能，只是一般很難做到。尤其是對於新手，幾乎不可能做到。所以，先完成再調優，是一般人的一般原則。 App開發上的重用，一般包括幾大塊：TableView和CollectionView上的單元格Cell重用，獨立視圖重用(這個在Storyboard上比較麻煩一點，在xib上比較方便一點)，類的重用。 重用的最大好處是方便改。因爲重用後，在同一個地方的代碼或設計，只需要改一個地方就可以在所有地方完成效果的修改，比較好維護。 性能調優，也有幾大塊，一般關注得比較多的是內存和CPU執行的優化，這兩塊一般用專業工具來完成，比如專門看一下這個鏈接裏的內容:# 19 調試 比較容易忽略的是方法的“輸入輸出控制”。就是一個方法開始之前，傳遞進來的數據應該符合什麼要求，方法結束之前，傳遞出去的數據應該符合什麼要求。這個一般會被歸爲“測試驅動開發”，在寫任何功能代碼前，應該先設計好。事實上做起來或推廣起來並不容易。多數人一般只會在功能完成後，加一步做檢查。
6)效果視圖 在所有功能實現之後，如果這個時候設計師也已經完成效果圖，我們可以開始完成基本的視圖開發。 視圖的開發，兩大類：TableView和CollectionView。相對於簡單的數據呈列，一般會通過TableView來完成。如果對分佈排版有更多的要求，一般會通過CollectionView來完成。把這兩個View吃透，可以完成多數的簡單視圖開發。 如果APP有非常多的個性化奇效果的視圖設計，那就沒辦法了，只能開個空的ViewController，自己一點點堆。這裏，也會有兩個層面。一、通過標準控件堆疊出效果。這樣的性能可能會差一些。二、代碼手寫視圖。箇中苦逼，誰寫誰知道。還有第三層次：代碼“畫”視圖。 做視圖時，要儘量貼近設計效果，否則產品或測試會把達不到效果的地方報Bug，可能會收到一份長達5頁紙的BugList。爲什麼不是百分百實現原設計，誰做過誰知道。
7)存儲請求 在所有回調處理都正常之後，可以開始接入後端接口請求數據。請求主要有四類GET/POST 和同步/異步。請求過程中要特別注意所要求的協議和參數類型。 因爲不是所有情況下都能保證網絡暢通，爲了讓用戶在無網絡的情況下，都能做一些基本的操作，我們需要緩存部分從服務器上請求過來的數據。 如果緩存的東西比較少，可以用NSCoding。如果比較多，就需要CoreData或者其它可以增量存儲的類庫。 緩存的操作最好開個線程異步處理。
8)方法回調 在基本的流程交互實現之後，我們往往需要考慮單向操作後的回調。比如單擊一個按鈕後，把數據傳回上一個頁面或刷新上一個頁面等。 回調有兩大類，一個是Delegate，一個是Block。Delegate的好處在於方便統一管理。Block的好處在於實現方便。 我現在基本上用Block。先在類裏增加一個Block屬性，屬性特性注意用Copy。然後在需要用的地方創建Block對象，把Block變量賦給對應的對象屬性。
9)流程交互 在數據容器都設計完之後，可以開始根據產品設計的APP操作流程實現模型的交互。比如對數組的查刪增改。這裏要儘量滿足產品設計的流程，否則也會歸入BugList。 過程中需要注意打印Log觀察數據容器的變化，看看變化是不是符合自己的交互預期。
10)單例組典 在對象屬性設計完成之後，可以考慮模型裏用到的數據通過什麼數據容器來裝載。 常用的數據容器有單例、數組和字典。 單例裝載整個程序裏都會用到的同一份數據。數組裝載有順序要求的數據。字典裝載需要按值查找的數據。
11)對象屬性 在功能模型統計完成之後，可以開始類的設計。類的設計，是一個面向對象的過程。 所謂面向對象，就是把所有東西都抽象爲一類屬性和方法。 比如一個APP的首頁，需要顯示最新熱點和用戶關注，那麼我們就針對“首頁”這個對象設計一個Home的類，這個類裏有Hots和Collects兩個屬性，ShowHots和ShowCollects兩個方法。
12)功能模型 上帝是我們的老闆，所以，老闆說要有首頁，於是我們有了首頁；老闆說要有最新熱點，於是我們有了最新熱點；老闆說要有用戶關注，於是我們有了用戶關注。 這種上帝暢想的統計工作，一般由產品完成。當上帝非常“民主”，只說“要有APP”之後，就開着車帶着祕書“躲貓貓”的話，後續暢想工作會交給產品來完成。等產品統計完了，她們會以“老闆說”或“用戶習慣”開頭向我們講述她們的偉大統計或設計。 這是APP一切的開始，是混沌，是太初，是太守，是太太，是什麼都行，就是一定得定啊，這裏不定，上面的所有步驟都沒法幹了啊。定定定定定定，一定要定定定定定啊啊啊啊！！！！！
完了嗎？沒完！
就像蘋果公司喜歡“One More Thing”一樣，程序員的世界裏，數字永遠從“0”開始。於是一切結束之後，我們也需要一個：
0)指南模塊 這纔是軟件工程師跟碼農的真正區別。真正的軟件工程師，他應該可以對外輸出開發指南和成熟模塊，大大提升開發界的開發效率。 很多老手害怕技術開發這個日新月異的世界，害怕那些無限進取的同行，他們會選擇閉帚自珍，然後就是閉門造車，然後就是閉目等死。 凱文.凱利大法師告訴我們，所有科技的發展都必然會發生，不可避免，科技在人類創造出來之後，就已經不受人類控制，人類最終只能被科技奴役。我們可以選擇在科技上加上自己的一腳，也可以選擇被科技壓斷雙腿拖着前行。就像《黑客帝國》裏一樣，紅還是藍，你自己選。
完了嗎？沒完！
粉絲羣的一位朋友問我，在這個技術日新月異的世界裏，已經累覺不愛了，怎麼辦？
瘋子答曰：何以解憂，唯有搞基！
人，是羣居動物。我們對同夥的需求，超出我們的想象。也許，沒有任何同夥，我們也能過一輩子，然後孤獨地死去。但是，只要嘗過同夥的快樂，我相信少有人願意重回孤獨。就像酒一樣。
所以，讓我們再來一個助於我們衝破天際的反作用力：
-1)共研開源 共同研究，開放源碼，不在於我們可以從別人那裏得到多少東西，而在於我們自己本身確實有實打實的輸出需求。我不知道怎麼解釋這個需求，我只知道我確實有，我接觸過的優秀夥伴們都有。而且，往往輸出越多的人獲得越多，超標輸出的人贏得了全世界。 如果一定要讓我好好解釋一下，或許我只能說：只有射了才快樂！
完了嗎？沒完！
爲防一片赤血丹心遭摺疊，保險起見，讓我們回一下正題：）
在看完整個開發注程之後，我們不難知道，作爲開發的真正工作，從模型設計開始。這也是無數大牛說“開發就是數據結構設計”的原因。
單從代碼的層面來看開發工作，大體可以分以下兩類四步： 二進 位置(內存地址)、解釋(數據類型) 對象 屬性(實例數據)、方法(數據操作)
所以，其實，不管是從底往上做開發，還是從頂向下做開發，看點基礎類型的書，都不會吃大虧，就算特別高大上地想一開始就上來開發APP，一層一層剝下去，最後還是免不了要做功能模型設計。
不要想速成，不要急，因爲急也沒用。無根之萍，漂到哪都只是漂。
我發現我說那麼多，還是容易被打爲“沒用也”，怎麼破。。。。 我想到啦，我有終極大法：開發很簡單，無非是多寫代碼多讀書！！！少年，你缺的只是行動！！！ 唉，終極大法就是好使，麼麼噠：）
