我的 知識星球 裡有人問到 Coding-iOS 這個開源專案值得學習嗎，這個開源客戶端有著 3500 + stars，看起來很受歡迎。
我把程式碼下載下來後看了一會，我的結論是：這個專案不值得作為優秀專案進行學習。說明一下，我並不是說這個專案程式碼寫的爛，只是作為一個模範專案來學習的話，這個專案整體水平一般。
這個專案的問題
細節處程式碼質量差
這個專案裡的程式碼我看到時間比較早的有 2014 年，意味著這是一個已經持續多年的專案。程式碼的細節質量做的很馬虎，小到語法格式，大一點的命名，再大一點到函式的實現邏輯都很普通。
落後的資源管理
都 9012 年了，專案裡的圖片資源沒有使用 Assets 管理，還是使用古老的 @2x @3x 圖片進行圖片管理。可以說因為歷史原因，這個專案剛啟動的時候沒有用 Assets，但是到現在這麼簡單的遷移都沒做，說明開發者對新技術的運用很不敏感。
簡單的架構
這個專案裡的程式碼組織非常的單純。繼承了 MVC 的光榮傳統，專案主要邏輯分成三個資料夾 Models、Views、Controllers。也許專案剛啟動的時候按照這個思路去管理程式碼檔案還能接受，但是專案稍微發展大一點，這個結構就會非常的不利於專案的維護。
比如有一個業務 A，為了實現這個業務你寫入了 XModel、YView、CController。過了一段時間後發現業務 A 效果不好，需要對其進行下線。這個時候維護的人需要非常清楚的找到分散在三個資料夾裡的三個程式碼檔案將其刪除。否則專案裡有了無用的多餘程式碼。這麼說起來感覺也還好，實際業務中可能一個業務對應了很多個 View、Cell。執行下線任務 A 的開發者很可能不是之前負責的開發者。下線的可能是一個 3 年前的業務，當時負責開發的程式設計師已經離職了。這個時候維護的人是很難確切的把業務相關的程式碼都找到的，就算找到了也要花很多時間。尤其是這個專案裡 MVC 下一級的層級也沒怎麼區分，要在幾十個 Cell 裡找到一個檔案還是挺費勁的。
元件化
這個專案沒有對業務模組進行元件化劃分。所有的業務程式碼都堆在一個專案裡。專案增長的越大，維護成本就越高。新人的理解成本就越高。也不利於多人同時開發。
建議的學習路徑
想通過學習優質的開源專案，提高自己的程式設計水平這個心情可以理解。不過大多數時候學習一個真實的專案價效比是很低的。
一個真實的專案常常會有這樣的問題：
- 很多設計是針對具體業務展開的，如果你不瞭解業務場景，你就不能明白程式碼為什麼這麼寫。這樣就導致你需要先熟悉這個專案的業務，才能看的懂程式碼。
- 實際開發中大概率會遇到一些 featrue 來不及開發了，先用成本的實現釋出一版再說。所以專案裡的程式碼可能有些不錯，有些實現的很差。作為專案而言是無所謂的，功能穩定就行，使用者使用的時候不管程式碼實現的好不好。但是對於學習的開發者而言，花時間學習的是很爛的程式碼，得不償失。
- 真實專案中的需求是持續迭代的。很多專案本來是按照需求 A 設計的，結果做著做著客戶要求再加一個需求 B。那麼原來程式碼的設計沒考慮到這點需求，繼續在原來的程式碼上實現就會很蛋疼。如果大家維護一個老的專案也會遇到這樣的場景，有個地方命名直接實現就好了，卻用了一個蹩腳的方式。其實是因為原來的需要兼顧 另外一塊功能，只是後來需求變了，不再需要兼顧了。那麼最後看程式碼的人就覺得為什麼不按照直接的方式來實現。
因此即便有一個優質的專案，學習前的成本也是挺高的。
我認為一個優質的專案分為兩塊：良好的架構和優秀的實現。就像一個大的專案會拆分成很多模組一樣，想要提高自己的程式設計能力也要拆分成很多小模組去達成。比如你的覺得你的命名不好，程式碼可讀性差，你就去找這方面相關的資料去針對性的學習。可以看看《編寫可讀程式碼的藝術》《Clean code》。如果你覺得自己模組抽象能力不好，學習一下物件導向、設計模式之類的。如果本身這些具體模組的好壞自己不瞭解，直接學習一個優質專案也是囫圇吞棗。假設有一個老外只喝過咖啡，沒喝過茶。然後你給他一堆好茶葉給他喝，最後讓他總結好的茶葉有什麼特點，他也講不出個所以然來。