第一個公司的iOS專案總結

青衫無名發表於2017-07-03
iOS
第一個正式的universal專案差不多快要結束，總結一下，分享給大家。因為可能我的比較具有代表性，如何從壓根不懂開始做起。（分享的另外一個目的也是希望大家提提建議，畢竟只有互相交流中才能更快成長）
　　———————————————–
　　做專案前：
　　零物件導向實際專案經驗，更不用說透徹理解design pattern
　　零iOS實際專案經驗
　　只懂一點點的C和彙編程式碼，其它如java、ruby、php、HTML5一點不沾邊，可以說是不屬於網際網路的業餘玩家
　　專案的情況：
　　做專案過程中，客戶需求變化極其頻繁和巨大，對程式碼結構的robust是一大挑戰。雖然本人特別討厭需求變動，但是在外，身不由己
　　Universal專案，即是iPhone + iPad 的一個專案
　　基本上這個專案涉及到了iOS的方方面面，麻雀雖小，但是五臟俱全
　　關於程式結構設計
　　嘗試用物件導向的方式去設計結構，但設計的時候流於形式，根據現有的一些best practice依葫蘆畫瓢，但實際上只有實踐了才知道，比如：
　　1. 屬性： 什麼時候用和為什麼用屬性、如何保持屬性私有、self.的使用，屬性的記憶體釋放;
　　2. 成員變數和屬性的區別
　　3. 方法：什麼時候用類方法和物件方法
　　4. 好的設計真的是“增之一分則太長，減之一分則太短”；好的設計關係到以後重構的方便性
　　5. 解耦設計：物件之間如何通訊，如何傳值，如何回傳，如何用好notification、delegate、KVO；如何保持物件的純潔（不受玷汙）
　　6. MVC中的M和C分離，一直覺得自己做的專案是小專案,而且一直認為過於注重結構，會增加程式碼量，但是實際上專案不分大小，好的設計：
　　能隨時應對客戶的需求變化
　　能自己看得懂自己寫的程式碼（改的多了，都看不懂自己的程式碼了，這是最悲催）
　　迴歸測試，一旦客戶需求改變，亂糟糟的程式碼更加亂，這樣迴歸基本上是需要全部。好的設計可以把客戶需求改變帶來的迴歸測試降低到最低
　　關於物件導向設計
　　之前從沒有物件導向設計的經驗，所以第一次從這種角度去解決問題。“實踐出真理”，無論你平時看多少書，如果沒有實踐過，真的是無法體會物件導向設計的：
　　一切從物件導向出發設計：類、物件、（私有）方法、（私有）屬性
　　所謂物件導向，就是根據現實世界中客觀存在的事物（即物件）出發來構造軟體系統
　　只有真正從物件導向去設計，幾個月甚至幾年後，你才能覆盤你的程式碼。以前一直覺得程式碼覆盤如同圍棋覆盤絕對是天才才有的本領，現在才明白，其實關鍵是：你要清楚的知道你的程式碼用在了哪裡，為什麼用
　　從物件導向出發，不要覺得一個功能很簡單一個方法就搞定，儘量用物件導向去考慮。這是做專案過程中犯的最大的錯誤
　　關於ARC
　　我是專案做了1個月後，才決定把專案從MRC轉到ARC，現在回頭看看，當初真實明智，因為在第一個月，記憶體管理上的問題和處理讓我很頭疼也很花時間。關於ARC
　　沒有想象中的會比MRC效能差，ARC不是JAVA的垃圾回收，效能其實與MRC基本一致
　　ARC中沒有明確的release操作，這時更需要注意記憶體管理，比如在一個Controller中使用Gyro sensor的時候，這種操作是絕對不能賦值給區域性變數的：[[CMMotionManager alloc]init]
　　雖然ARC似乎能為你做很多事，但是有些事情自己解決還是自己解決，比如當不需要用Gyro sensor時，_motionManager = nil（此時如果不設定，則startDeviceMotionUpdatesToQueue中的更新會一直進行）;
　　總之，對於ARC，難得糊塗中要“時刻保持覺醒”
　　關於Perfomrance設計
　　Coding真的是一點都來不得馬虎，以前一直覺得iOS效能強大，無須擔心效能，但是專案做下來，一大痛苦之處就是效能不夠：
　　應用程式、UIViewController和UIView的生命週期的認識如果不十分清楚，就很容易造成效能瓶頸
　　大量的UIView插入移除操作會導致效能問題
　　UITableView和UIScrollView導致滑動不順暢的best practice
　　關於知識點
　　成為一名優秀Programmer需要豐富的經驗和知識面，但是知識永遠是學習不完的，所以要抓核心和基本，個人覺得以下幾個知識點是iOS開發必須的。至於有些比如CoreText、CoreImage等，其實等到需要用時再去學習也來得及。
　　記憶體管理，MRC和ARC
　　多執行緒，iOS下有多種多執行緒實現方式，什麼都應該瞭解一下，但是除了dispatch需要精通，其它只需要看懂 （dispatch效率最高，使用最方便）
　　資料庫，無論是Core Data，FMDB還是基本的Sqlite，萬事不離其中，掌握Sqlite和SQL基本語法是必須的
　　UIViewController、UITableViewController 和應用程式的生命週期
　　看似簡單但是很有深度的View之間的轉場處理，因為涉及到大量生命週期，如presentModalViewController, presentViewController, pushViewController, addSubview, removeFromSuperview, self.view….
　　網路處理相關的，如何請求JSON資料，如何HTTP GET和POST
　　旋轉處理，特別是iOS4、iOS5、iOS6的不同處理
　　Debug的能力
　　基本的設計模式：MVC、delegate、notification、target-action
　　物件導向的核心思想，例如：不要以使用者無法使用或不感興趣的東西擾亂類的公有介面、類之間應該零耦合、把不相關的資訊放在另一個類中
　　不重複造輪子
　　這個也不例外，iOS下的開源framework都太多了，基本上你需要的都能在Github或者Stackoverflow上找得到，所以平時：
　　不要做井底之蛙，平時多瞭解開源的框架
　　框架適合就行，就像爭論AFNetwork和ASIHttpNetwork更棒沒有意義的。寫程式的有兩類人，一類人追求技術極致，一類人技術只是實現產品的一種手段，我就是後面這個
　　關於開源框架的學習
　　這世界好的開源框架太多了，給我10年都看不完，所以需要選擇，就像讀書不在於都多，而在於讀精，個人推薦如下。
　　Three20 （其實我是不推薦的，因為它過時了，但是因為淘寶客戶端用到）
　　AFNetwork
　　MBProgressHUD
　　SDWebImage
　　關於Continuous Improvement
　　Six sigma中提到了持續改進，我們的能力提高也是這樣。通過讀好的開源框架是最好的進步方式。如何讀開源框架，我們讀開源框架的目的：
　　其中的花式寫法我們只是瞭解，不是我們的目的
　　瞭解作者寫框架的思路
　　對比自己現有的，求改進
　關於設計模式
　　做專案前，把GOF的23種設計模式都看了一遍，專案做下了，體會到：
　　單看設計模式的書，純粹是無用；
　　設計模式的核心在於平時的有意無意的使用，因為它本身來源於實際；
　　能熟背23種設計模式固然是件好事，但是不能也不見得是壞事（反正我是記不住的）
　　欲速則不達
　　程式碼之間往往只查一兩個字元，但效能和結局多半千差萬別，因為專案緊，壓力大，又是第一個專案，所以寫程式碼的時候，追求：”meet requirement，先滿足功能，再考慮程式碼結構”，但是實際：
　　需求無論大小，程式碼結構設計是必須的而且是第一位的，因為這關係到未來的改動，未來自己能否看懂；
　　欲速則不達，真是一個真理
　　關於Best Practice的重要
　　iOS已經很成熟了，基本上，所有問題都能找到答案，所有的需求都有現成的framework，或者只需要稍許改改。但是也正因為“萬能的internet”，所以很多答案或者很多framework都是有問題的，所以適時總結很重要：
　　把常用的程式碼或者容易錯的程式碼寫到Xcode的snippet中
　　要有自己的library，不是自己擺酷，而是知識需要積累，有些開發中經常會遇到的
　　用好的framework。不流行的框架要注意是否用了私有方法（蘋果 will reject it）
　　best practice，比如如何自定義TableCell，如何自定義Navigation bar
　　不玩花的，不玩偏門的，寫程式碼就是規規矩矩，一切按照蘋果的best practice寫
　　物件導向的思想有很多概要，平時要時刻提醒自己
　　關於HTML5
　　iOS原生與HTML5 WEB APP天生就是一對敵人，做HTML5的可以不懂iOS開發，但是做iOS開發必須懂點HTML5：
　　iOS應用中一些“高度變化”或“效能要求不高”或“上線緊迫”的地方會用到UIWebView
　　iOS原生與UIWebView的之間互動其實也可以很棒，甚至JSP互動
　　HTML5是“可能”的未來，世界都在談論
　　HTML5看似只有一個知識點，但是其實要求比iOS原生開都高：一個典型的移動HTML5頁面 = JSP + HTML + CSS + JQuery + backbone.js。或者學習PhoneGap也是不錯的注意。
　　關於未來：
　　如何讓自己在最短的時間內成為優秀，這是每天都在思考的，因為對比別人_大學+工作下來的多年工作經驗，我是不懼任何優勢的，但是既然入行，就必須做優秀。所以選擇值得做的事尤其重要：
　　看書沒用，實踐和Coding是提高能力的唯一途徑；
　　做實際專案比自己玩玩靠譜十萬倍
　　壓力下工作成長更快，所以不斷挑戰自己，人的潛力是無限的
　　番茄工作法則比較適合我（每次集中做半個小時）


最新內容請見作者的GitHub頁：http://qaseven.github.io/


相關文章