iOS App 開發的那些事兒 1：如何創建合適的規範

《iOS App 開發的那些事兒》系列文章從更宏觀的角度出發，不單單侷限於具體某個功能、界面的實現，而是結合網易雲信 iOS 端研發負責人多年的經驗，從如何優化現有代碼的角度出發，深度分析如何創造出 iOS App 開發中比較合適的規範和框架。

將代碼規範合理分級

你們都理解軟件開發須要合適的規範：代碼規範，程序規範，流程規範等等，以此來減小意外的出現：最少驚訝原則。但在實際執行中卻會碰到各類狀況，其中最大的問題是：怎麼鑑別哪些規範是須要強制執行，哪些規範是推薦執行。
規範的強制執行帶來的是代碼的可讀性提高和二義性減小，而壞處也是顯而易見的：對於大部分有想法的程序員而言這種規定太死板，容易引發抵觸心理，產生不安定因素。這種狀況常見於各類標準的外包公司。
而若是大部分的規範設定爲推薦執行，在沒有良好的引導下，規範容易被忽視。 網上有不少關於ObjC的代碼規範，好比蘋果自家的規範和《Google Objective-C Style Guide》等。這些規範通常只有兩種分級:推薦和不推薦。而我更推薦把代碼規範分紅五個等級：強制要求，強烈推薦(但不強制)，良好，可接受和不可接受。
如下僅舉部分例子加以說明。

符合蘋果規範的命名方式

• 類名開頭大寫，方法和變量名以駝峯法命名。強烈要求，這沒有什麼好說的，蘋果系統類庫和絕大多數的第三方開源庫都是如此。但在部分蘋果的 sample 中也看到過用m作前綴表示類成員變量的寫法，這些都是屬於遺產代碼的問題，仍舊是可接受範圍，可是本身代碼內部使用相似匈牙利的命名法就是不可接受。
• 類名使用至少三個字符作前綴，內部方法使用兩個下劃線作前綴。強烈推薦。上面的作法能夠最大程度避免和系統類庫發生重名的狀況：由於蘋果宣稱保留全部兩位字符前綴的使用權，同時其內部方法命名以一個下劃線作前綴。
• 不管使用 K&R Style 仍是 Allman Style 都是可接受的範圍，可是強烈推薦在一個文件內保持一種形式。
• 在保證代碼可讀性的基礎上保持代碼的簡短和統一性：小類，小方法，統一的函數返回。小類，小方法能夠保證他人閱讀時更方便地關注類邏輯，而不是具體細節，而統一的函數返回能夠減小意外錯誤和下降錯誤排查的難度。而保證代碼的簡短和不羅嗦也是很重要一點，常常會看到以下代碼： if (count > 1) { return YES; } { return NO; }，真心沒法直視。

良好的代碼/工程結構

• 爲整個工程建立 workspace。
• 按照權責分門別類存放資源文件：每種類型的資源存放於獨立的目錄下：圖片，聲音，配置文件等等。而圖片又能夠按照類型分別存放在不一樣的子目錄下：全局類型，背景圖，logo，登陸等等。
• 合理的代碼結構。

Core：工程內一些通用的機制實現類：統一的任務管理，模塊管理，服務管理。
General：公用類和方法，包括工程內ViewController,UITableViewCell基類(Base)，公用Category(Category)：公用UI組件(CustomUI)，公用輔助方法(Helper)和宏定義(Marco)。
Model：公用數據模型
Sections：不一樣程序單元。如登陸，設置等等。其下又能夠按照功能分紅不一樣的子目錄：當前單元使用的自定義UI組件，管理類，數據模型和ViewController等等。
Vendors：第三方庫。

《iOS App開發的那些事兒》第二篇文章將會向你們介紹什麼是合適的框架，如何搭建合適的框架，歡迎你們積極發表本身的見解，與咱們共同討論。

---

隨着即時通信以及音頻處理和壓縮技術的不斷髮展，效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現，若是你有好的技術或者分享，歡迎關注網易雲信官方博客和 GitHub：

關注更多技術乾貨內容： 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網