[iOS] 接手舊項目，看到這樣的代碼不要哭 ... 由於你已經在這裏見過

作iOS開發, 不免會接手別人碰過的代碼, 以前作過一些外包項目, 是別人已經完成了前期的功能, 而後到我這裏就須要接着以前的任務繼續開發, 相信不少在上班的朋友也同樣, 老是會接着寫別人的代碼, 而後每次, 我相信你確定會和我同樣, 看着看着, 心中一萬條草泥馬~~~飄過, 而後不得不默默的填坑. 固然你寫的代碼一樣的之後可能會被其餘人看到, 因此我每次看到如下幾種相似的代碼, 一定會痛罵一番, 若是你但願你寫的代碼之後少被人罵, 至少不要寫出下面的代碼吧... 前方高能~~~

• 項目中處處引用第三方庫-- 好比 AFN 咱們在項目中, 確定不可避免的會使用到第三方庫. 第三方的開源貢獻者爲咱們作了不少的工做了, 感謝他們吧. 可是使用第三方庫帶來的另一點小的隱患就是, 可能隨着項目的開發咱們會遇到更換第三方庫的需求, 那麼若是你以前整個項目處處都依賴(引入第三方庫)第三方庫的話, 對於更換第三方庫的代價就是巨大的. 最多見的是項目中的網絡請求使用AFN來完成, 你說使用這個第三方庫來完成網絡請求確定是比較正確的選擇吧, 可是...... 網絡請求基本上就 發送,GET,POST請求, 下載文件, 上傳文件 這麼四個常見的需求, 你使用AFN難道就不能本身封裝幾個接口出來, 而後項目中的網絡請求都使用本身封裝的這幾個接口, 之後在更換網絡請求庫的時候直接更改這幾個接口不就行了, 而不須要再全部項目中用到網絡請求的地方都挨着挨着改一遍(基本是沒辦法改的, 不是到如今爲止不少項目還使用着ASIHTTPRequest麼),我見過整個項目使用swift來開發的, 而後網絡請求庫使用的是AFN, 項目中全部的網絡請求都是直接使用AFN的接口來完成的, 結果後來項目決定須要更換爲Alamofire, 而後... 你懂的

@interface ZJHttpTool : NSObject
/**
 *  發送一個GET請求
 *
 *  @param url     請求路徑
 *  @param params  請求參數
 *  @param success 請求成功後的回調（請將請求成功後想作的事情寫到這個block中）
 *  @param failure 請求失敗後的回調（請將請求失敗後想作的事情寫到這個block中）
 */
+ (void)get:(NSString *)url params:(NSDictionary *)params success:(void (^)(id responseObj))success failure:(void (^)(NSError *error))failure;
+ (void)post:(NSString *)url params:(NSDictionary *)params success:(void (^)(id responseObj))success failure:(void (^)(NSError *error))failure;
...
@end複製代碼

• 命名規範 據說過OC中類命名要加前綴嗎? 嗯隨手一寫, 習慣了本身每一個項目中都定義一個全局的常量文件 命名爲constant.h吧... 能不能加個類前綴, 雖然這種對項目中總體的影響不大(衝突了會報錯, 你總會修改了吧), 可是這種不符合規則的類命名真的讓人很不爽 據說過變量名使用英文變量命名嗎? 你說這個計算機的世界是英語的世界都是事實, 你們都提倡變量命名使用英文來命名. 因此那些使用拼音來命名的愛國者是怎麼想的, 見過一大堆的youxiangzhanghao, banjibianhao, xingmin, xingbie ..., 你說這些常見的名詞的英文你寫個拼音真是讓人沒法直視啊, 只能讓我開罵---必定是個英語弱爆了的傻X寫的代碼... 好吧還有一種人是這樣的, 真是嚴格遵照命名規範, 因而項目中的變量名都使用英文的, 不過啊不過啊, 對於我這種六級飄過的學渣而言, 看大家這些大神高級的命名全靠詞典啊, (電腦常備有道沒有錯) anticoagulant (抗凝劑), tranquilizer(鎮定劑)... 總之一堆一堆的藥名和專業名詞 這些東西簡直不能忍啊, 看代碼就是查字典去了, 這裏我但願用拼音, 哪怕別人罵我是用拼音的傻逼...
• 代碼量多到難以閱讀的class文件 這個真的是遇到的很是很是多的了, 一個controller打開, 見過最多的接近4000行, 個人天, 這讓人怎麼活, 最坑爹的是, 橫下心去看看---- 一個viewDidLoad裏面2000多行代碼...... 只看到大括號開頭啊 還有人項目中將使用到的常量放在一個文件中來管理是個好習慣, 可是, 你這一個文件中放了幾千個常量... 真的是欲哭無淚啊...
• 處處都是通知 iOS開發中, 通知真的很好用啊, 跨界面傳值, 同時能夠傳值給多個對象. 可是, 也不帶這樣來使用的啊, 全部的頁面反向傳值, 感受通知最方便了, 一個post就發佈一條通知, 而後項目中處處註冊通知來監聽, 不知道這些人是怎麼作到的正確的移除通知監聽者... 更無語的是, 發佈的通知的命名那都是隨手一寫... 通知雖然好用, 但要注意使用的場所啊
• 處處都是神奇數字 項目中見過處處都是的, 最多見的是在設置frame的時候, 也許正如註釋的那樣, 全部的數字都是這位開發者, 寫代碼的時候感受這些數字比較合理

  // 高度爲44看上去更合適
    self.searchBar.frame = CGRectMake(0, 22, 320, 44);複製代碼

• 處處都是代理 上面剛說了有人處處使用通知的, 這裏也有人處處使用代理的, 凡是須要反向傳值或者響應某些操做的, 統統先寫一個協議, 而後實現一個代理, 我有見過一個頭文件上面遵照十多個協議的, 而後這些協議裏面基本上只有一個代理方法, 還有一種更可惡的是, 一個協議包含不少不少的代理方法, 所有標記爲optional ..., 而後在須要的地方直接調用

像這種, 在controller中遵照了許多個協議, 不少方法都不知道是那些協議裏面的, 至少你也要加個註釋什麼的吧 ... 
- (void)saveBtnDidTouched {
    // 代理一...
}
- (void)sexDidChanged {
    //代理二...
}
- (void)downloadDidFinished  {
    //代理三...
}複製代碼

• 隨便引用第三方庫-- 而後本身修改其中的一些地方, 這個時候你還敢不敢pod update
• 關於跨頁面傳值 見過有人的項目中全部的跨頁面反向傳值, 所有使用單例來傳遞, 而後許多個地方都在修改和獲取這個單例對象的一樣的屬性, 當你接手這樣代碼的時候, 哭吧... 你根本不知道這個值在那些地方會被修改. 另外有一種噁心的傳值, 這種人也是無語了, 須要的跨頁面傳值通通寫入本地文件中, 而後在其餘頁面直接讀取文件中的值... 天才啊
• 一個class實現不少個頁面的功能 有些人代碼複用的觀念真的是太強了, 不想多寫一點代碼, 因而, 一個自定義的UITableViewCell裏面各類判斷, 來實現不少的控件的隱藏和位置調整... 明明看上去不是很像的各類cell, 硬是被他放到了同一個cell文件裏面來管理...
• 盡全力使用黑魔法處處+load 這種人, 不知道是爲了顯示本身多有學問仍是什麼, 項目中一有機會, 直接寫個系統類的擴展, 而後重寫+load方法, 繼續高能, 使用黑魔法交換系統的方法... 當你發現本身明明是繼承自系統的控件來寫的代碼, 爲何爲何, 效果非常古怪, 而後你就開始懷疑人生了. 我曾經在一個項目中使用UINavigationController的時候, 由於自定義了返回按鈕, 而後側滑手勢失效了, 因而像之前那樣解決, 更改手勢的代理(具體方法百度吧),發現無論怎樣都不會向之前那樣有效, 最終很長時間的檢查才發現, 在之前的某個文件中有人使用runtime更改了手勢的代理, 用於實現全屏滑動返回的效果...

原本是用來吐槽最近見到的奇葩代碼的, 不過寫着寫着就不想繼續吐槽了, 反正最終仍是要繼續填坑, 不過, 但願你不會再寫出這麼詭異的代碼出來了, 由於-----真的是會被罵的