入職新公司已五天有余，看了公司項目的部分代碼，說下自己的想法。我不是大牛，也不是要說公司代碼不好。只是希望自己以后寫代碼的時候能注意下面這些小問題。
1. AppDelegate過于冗雜
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions；
程序啟動方法內過于雜亂，注冊友盟極光環信、是否進入引導頁等等有很多操作，一坨一坨的很長。
- 解決方法一
可以將相同功能代碼封裝在一個方法內,例如將關于友盟的初始化模塊都放在- (void)registerUM方法內，然后在需要初始化的時候調用這段代碼。這樣最起碼代碼看上去會整潔很多，看上去沒有那么散亂。 - 解決方法二
寫一個AppDelegate類的擴展，將方法一中的- (void)registerUM放到擴展中，然后在AppDelegate.m中調用，這樣會減少AppDelegate.m中代碼量。 - 解決方法三
寫一個AppDelegate類的擴展，用method swizzling，使得在調用系統方法之前先調用自己定義的方法。在自己的方法中初始化第三方平臺。這樣一點都不會增加AppDelegate.m代碼，但是要注意的是自己定義方法中也不能寫的雜亂無章。
2. 硬編碼太多
項目中需要根據用戶信息中的type來判斷用戶的類型比如是學生還是老師，后臺返回的type是字符串"student","teacher"這樣，不知道為什么不返回一個typeID，客戶端在判斷用戶的時候直接[userModel.type isEqualToString:@"student"];來判斷用戶的類型。因為項目中有很多場景都需要這樣的判斷，假如后臺有天想把返回的"student"改為"stu"，那怎么辦。
解決方法一
無論后臺的type返回的是字符串還是typeID,最后都在客戶端做一個映射，在model中定義一個枚舉，然后在type的setType方法中將根據后臺type的類型映射成枚舉中的一個值。這樣判斷用戶的時候就可以[userModel.etype == userTypeStudent"];判斷。這樣即使后臺修改了type的值，我們也只需要在model的setType方法中將對應的值修改下就行。解決方法二
如果執意用[userModel.type isEqualToString:@"student"];那最好也將“student”定義一個宏吧。這樣后臺做修改之后，也只需要修改下宏。
3. ViewController中的- (void)viewDidLoad
不說viewController瘦身，最起碼要不要做到控件的初始化，布局，和業務邏輯都寫隨意在- (void)viewDidLoad。會使方法內代碼行數過多，看了容易暈車。有點類似
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions；
中。
- 解決方法
參考問題一，可以將初始化控件、布局操作、業務邏輯都封裝成各自的方法然后調用相應方法即可，雖然沒有減少VC中的代碼量，但是最起碼沒有出現不同功能代碼相互摻雜，我中有你你中有我的情況。
4. END
這些問題基本都和技術牛不牛沒有多大關系，但是都是值得注意的一些小問題。最起碼要讓自己的代碼看起來整齊，易讀，易維護。最高境界就是要達到讓我們的代碼截圖到可以做手機壁紙的程度
??。
