[iOS] 接手舊專案，看到這樣的程式碼不要哭 ... 因為你已經在這裡見過

ZeroJ發表於2018-12-14
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更改了手勢的代理, 用於實現全屏滑動返回的效果...

拒絕

本來是用來吐槽最近見到的奇葩程式碼的, 不過寫著寫著就不想繼續吐槽了, 反正最終還是要繼續填坑, 不過, 希望你不會再寫出這麼詭異的程式碼出來了, 因為-----真的是會被罵的

相關文章