代碼重構［iOS開發］

最近接手一個做了一年的老項目，拿到代碼後仔細一看，發現存在比較多的問題：

1.沒有使用svn、或 git 進行管理，所有更改都在本project上，其中問題顯而易見，需求在不斷添加或者修改的時候，很多都會被悄無聲息的被砍掉，沒有分支、版本的概念。

2.使用到了諸多優秀的第三方庫資源，但是沒有使用CocoaPods進行管理，這就存在一個第三方庫資源升級、再配置的問題；

3.業務與UI混雜，項目在設計的初期以及開發的過程中，沒有進行合理的規劃統籌，每個viewController中塞入其需要實現的業務，導致MVC中C一端極度龐大，隨便都是上千行代碼，維護代價太高；

4.隨便使用notification，倒不是說notification機制不好，用的恰當，事半功倍，但是當我開啟主介面看到viewDidLoad中註冊了多達二十多個notification時，實在無法直視，想要罵娘；

5.卻少封裝與模組化，正如第3點中提到，業務跟隨頁面走，可能是相同的業務員，在不同的頁面中卻多次出現，繁瑣，升級修改也很麻煩。

6.函數命名不明晰，很多業務處理方法，用到一些諸如nextXXX、doXXX、finishXXX的命名。詞不達意，不深入函數內部看具體操作，很難看懂這一步是要做什麼。

7.卻少文檔和注釋，由於第6點原因，一些頁面、函數不去看內部，無法知曉是幹嘛用的，還沒有必要的注釋和說明。

基於以上發現的問題，意識到在一個項目的設計、開發階段 整體的架構和架構的思想的重要性。沒有好的架構，只跟著需求走，東邊填一塊，西邊加一筆。等到項目比較複雜時，新的需求添加很麻煩，老得功能更新修改更是複雜。

接手了這個項目後，也開始思考如何在一個項目的結構的設計，這個雖然看過了一些相關的知識、也看多一些優秀的第三方庫檔案的結構，但是如何在自己項目開發中貫徹這些優秀的方法和思想才更重要。

一、一些基本思想

1.工作分塊細化：無論是怎樣複雜的商務程序，對其進行儘可能的分割細化，細化的過程也是對業務的每一步的理解，是對一個商務程序的量化，通過對業務的分塊細化，也能分析出一個業務工作量有多大。具體到每一個函數只做一件事情，貫徹 Do One Thing Only 的思想

流水線的工作模式是現代工業崛起的核心，而此工作模式也是基礎對工作的具體化、分步。同時對工作的細化分塊也可以對應到項目的WBS中，管理起來也變得明晰。

2.小功能注意封裝，大功能注意模組化：基於對工作進行了合理的分塊和細化後，要對業務進行合理的封裝和模組化，降低功能模組之間的耦合，可以實現對單個商務程序、功能點的測試。貫徹 高彙總、低耦合的思想。

電腦在流水線的組裝，有了模組化的主板、機箱、外設後，組裝也就變得簡單，可以進行單元化的測試和升級。

3.專案檔結構分層要明晰：還是分類別模組化的思想，應用在專案檔的管理中，根據項目具體情況或按照功能、或按照頁面進行分層管理，不要使一個檔案變得過於龐大，貫徹 大項目小檔案 的思想。

記得以前看UNIX設計思想有提到 大項目小檔案 這個思想，越是龐大的項目功能，其中的檔案越是要具體和足夠細化。

4.命名可讀化：對於檔案或者函數的命名最好能夠達到“看其名知其意“的效果，而不用進入到檔案或者函數中去看處理邏輯。除此之外也要添加必要恰當的注釋。保證模組化的功能的使用順暢。

二、實際工作

基於現在能夠理解和用的思想的指導下，對該項目進行了重構工作，前後耗時三周時間，今天算是完成了第一階段的重構。

1、結合項目設計文檔對原來項目進行重新拆分，商務程序進行獨立化，對業務和UI進行分離抽象。

2、使用cocoaPods、git管理項目，記錄工作內容，也是紀錄自己學習的過程。

3、業務功能分塊細化、模組化業務，對檔案進行拆分、重新命名，提高代碼利用率。

4、廢棄大量使用notification的邏輯，改用block、delegate等模式，使項目更加明晰、便於以後的升級。

5、建立項目的檔案系統，對模組化的商務程序產生對應的邏輯文檔。

三、對以後工作的指導意義

以後新開展一個項目時，要合理的設計、運用好項目的命名、架構、檔案管理結構、文檔4大系統。

在項目開發過程中，要不斷的停下來對過去的工作進行思考，新加一個功能的時候先思考，如何更好的接入到已有的邏輯中。螺旋式的工作進度中，讓自己對項目的管理的思想和方法更加成熟。