一個優質的項目應該具備什麼特色

個人 知識星球 裏有人問到 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 裏找到一個文件仍是挺費勁的。

組件化

這個項目沒有對業務模塊進行組件化劃分。全部的業務代碼都堆在一個項目裏。項目增加的越大，維護成本就越高。新人的理解成本就越高。也不利於多人同時開發。

建議的學習路徑

想經過學習優質的開源項目，提升本身的編程水平這個心情能夠理解。不過大多數時候學習一個真實的項目性價比是很低的。

一個真實的項目經常會有這樣的問題：

• 不少設計是針對具體業務展開的，若是你不瞭解業務場景，你就不能明白代碼爲何這麼寫。這樣就致使你須要先熟悉這個項目的業務，才能看的懂代碼。
• 實際開發中大機率會遇到一些 featrue 來不及開發了，先用成本的實現發佈一版再說。因此項目裏的代碼可能有些不錯，有些實現的不好。做爲項目而言是無所謂的，功能穩定就行，用戶使用的時候無論代碼實現的好很差。可是對於學習的開發者而言，花時間學習的是很爛的代碼，得不償失。
• 真實項目中的需求是持續迭代的。不少項目原本是按照需求 A 設計的，結果作着作着客戶要求再加一個需求 B。那麼原來代碼的設計沒考慮到這點需求，繼續在原來的代碼上實現就會很蛋疼。若是你們維護一個老的項目也會遇到這樣的場景，有個地方命名直接實現就行了，卻用了一個蹩腳的方式。實際上是由於原來的須要兼顧 另一塊功能，只是後來需求變了，再也不須要兼顧了。那麼最後看代碼的人就以爲爲何不按照直接的方式來實現。

所以即使有一個優質的項目，學習前的成本也是挺高的。

我認爲一個優質的項目分爲兩塊：良好的架構和優秀的實現。就像一個大的項目會拆分紅不少模塊同樣，想要提升本身的編程能力也要拆分紅不少小模塊去達成。好比你的以爲你的命名很差，代碼可讀性差，你就去找這方面相關的資料去針對性的學習。能夠看看《編寫可讀代碼的藝術》《Clean code》。若是你以爲本身模塊抽象能力很差，學習一下面向對象、設計模式之類的。若是自己這些具體模塊的好壞本身不瞭解，直接學習一個優質項目也是囫圇吞棗。假設有一個老外只喝過咖啡，沒喝過茶。而後你給他一堆好茶葉給他喝，最後讓他總結好的茶葉有什麼特色，他也講不出個因此然來。