在設計IOSapp時為了代碼的擴充性可可維護性需要遵守的原則

標籤：code   c   a   資料   工作   管理   

　　作為軟體工程範疇的iosApp，為了保持代碼的可維護性和擴充性，必然要遵守軟體的基本特性，眾所周知高內聚低耦合的程式才能具備這樣的特性。

　　首先，不能依賴於storyboard和xib，原顯而易見。第一點是，在原始程式碼控制方面，在Team 專案中，一旦有人改變了一點內容storyboard就會顯示modify的樣子，所以讓人看起來很不安，其實帶著M的原因很可能就是其他團隊成員滑鼠手點擊了一下而已，最新的原始程式碼控制工具在Xcode中的整合基本上解決了這個問題，但是依然還是會產生嚴重的代碼衝突，這不是團隊人員想要見到的樣子，所以，很少有使用者體驗和功能強大的app是採用storyboard的形式的。

　　下面來聊一下如何能讓代碼更加的易於維護和易於擴充。

　　我們在工作中最重要的是什嗎？當然是進度。我們對於代碼的功能抽取和模組重構自然是沒法跟上進度的更新的，所以我們需要一個懂得軟體生命週期並且看中軟體未來的領導來帶領團隊。開始的時候我們可以為了產品的成型速度而放棄代碼的抽取甚至於為了產品能早點上線而寫出控制器很重的代碼，其實在很多公司中都是這樣的上千行的控制器隨處可見，國內某地圖應用產品的控制器竟然有2+w行，這其中的重複代碼和層的代碼自然是非常之多的。後期的維護真的很難進行下去。而這個時候作為團隊的主管，就需要為團隊的為了和公司的為了做出犧牲了，盡量敦促團隊成員規範的進行代碼的編寫，產品經理總是在崔，最為老大的你需要做的是在程式猿和產品之間進行斡旋，即不能忽略產品也不能完全犧牲猿們。斡旋的功夫大家自然都是懂得的，這裡討論的只是程式猿需要遵守的：

　　1.代碼必須進行層次劃分，為了趕工期可以產生重複的代碼，或者未抽取父類的很多的類，但是代碼必須是讓版本控制牢牢把控的。

　　2.剛剛拿到任務的人，除非是工作了許久的大牛，否則，基本都是在試水的，不可能直接完成某個模組的頂層類和方法的抽取，當然模型除外，因為產品設計階段基本已經完成了這個任務。可以先試著去完成功能，然後在進行代碼的頂層父類或者重複功能的抽取。

　　3.一定要遵守MVC的設計思路，不要出現在控制器中進行屬性賦值的操作，而是通過對象來進行資料的傳遞，作為橋樑的控制器，如果負擔過重的話必然會產生程式的不穩定性。

　　4.本文僅僅是作者自己的心得體會，只是想要記錄下來和大家分享。