一個優質的專案應該具有什麼特點
我的知識星球 裡有人問到 Coding-iOS 這個開源專案值得學習嗎，這個開源客戶端有著 3500 + stars，看起來很受歡迎。 我把程式碼下載下來後看了一會，我的結論是： 這個專案不值得作為優秀專案進行學習 。說明一下，我並不是說這個專案程式碼寫的爛，只是作為一個模範專案來學習的話，這個專案整體水平一般。
這個專案的問題
細節處程式碼質量差
這個專案裡的程式碼我看到時間比較早的有 2014 年，意味著這是一個已經持續多年的專案。程式碼的細節質量做的很馬虎，小到語法格式，大一點的命名，再大一點到函式的實現邏輯都很普通。
隨手舉個例子，上面的程式碼聲明瞭一組 Label，本身 UILabel 縮寫成 L 已經不是一個規範的做法了。但是如果團隊都約定成 L 表示 Label 也是接受的，但是同一行裡，還被縮寫成了 T 和 V。團隊稍微對程式碼質量有點要求應該都不會允許這樣程式碼的出現。
落後的資源管理
都 9012 年了，專案裡的圖片資源沒有使用 Assets 管理，還是使用古老的 @2x @3x 圖片進行圖片管理。可以說因為歷史原因，這個專案剛啟動的時候沒有用 Assets，但是到現在這麼簡單的遷移都沒做，說明開發者對新技術的運用很不敏感。
簡單的架構
這個專案裡的程式碼組織非常的單純。繼承了 MVC 的光榮傳統，專案主要邏輯分成三個資料夾 Models、Views、Controllers。也許專案剛啟動的時候按照這個思路去管理程式碼檔案還能接受，但是專案稍微發展大一點，這個結構就會非常的不利於專案的維護。 比如有一個業務 A，為了實現這個業務你寫入了 XModel、YView、CController。過了一段時間後發現業務 A 效果不好，需要對其進行下線。這個時候維護的人需要非常清楚的找到分散在三個資料夾裡的三個程式碼檔案將其刪除。否則專案裡有了無用的多餘程式碼。這麼說起來感覺也還好，實際業務中可能一個業務對應了很多個 View、Cell。執行下線任務 A 的開發者很可能不是之前負責的開發者。下線的可能是一個 3 年前的業務，當時負責開發的程式設計師已經離職了。這個時候維護的人是很難確切的把業務相關的程式碼都找到的，就算找到了也要花很多時間。尤其是這個專案裡 MVC 下一級的層級也沒怎麼區分，要在幾十個 Cell 裡找到一個檔案還是挺費勁的。
元件化
這個專案沒有對業務模組進行元件化劃分。所有的業務程式碼都堆在一個專案裡。專案增長的越大，維護成本就越高。新人的理解成本就越高。也不利於多人同時開發。