[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更改了手勢的代理, 用於實現全屏滑動返回的效果…

拒絕

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

相關文章