程序員：如何接手垃圾代碼？

曾經有一段「垃圾代碼」放在個人面前，我沒有拒絕，等我真正開始接手的時候我才後悔莫及，程序員最痛苦的事莫過於此！固然，這些都是改編自周星星同窗的經典臺詞，不過相信讀者看完今天的討論內容，應該也會有同感，接手垃圾代碼實在是一件太痛苦、太折磨人的事情！

本期移動精英開發羣討論的話題就是「如何接手垃圾代碼？」主持人是國內某跨境電商平臺 iOS 開發的負責人曹理鵬，文章系國內 ITOM 管理平臺 OneAPM 整理：

曹理鵬：你們好，我叫曹理鵬，如今在一家跨境電商的公司作 iOS 開發，此前的確接手過「垃圾代碼」，首先簡單分享一下這個項目存在的問題（針對 iOS 開發）：

1.使用老式框架 ASI，而且沒有作任何封裝和抽取；
2.字典轉模型都是硬編的；
3.類名多數以拼音的形式；
4.裏面我再裏面一共看到了5我的的身影（只有一個看起來牛逼的），因此就有五我的的思想和代碼邏輯；
5.出現不少重複的小框架（好比下拉刷新，提示框等）；
6.幾乎沒有什麼註釋，有也是一些拼不一樣的名字的解釋；
7.最多代碼是一個類裏面有6000多行代碼；
8.文件的邏輯結構與物理結構幾乎不對應；
9.沒有使用 Cocoa Pods，全部框架都是拖進去的。

最近的時間都是在「填坑」，填了一個又一個，致使本身都快沒信心了，因此就有一個很強烈的想法，談談如何接手垃圾代碼的問題......

李小三：大家見過 把 doc 文檔放工程裏的嗎？大家見過一個 controller 裏有1000行的 UI 嗎？一個挺複雜的界面有不少視圖。我接手的代碼，一點註釋都沒有，本身連猜帶蒙把註釋加上了，簡直......（後續吐槽省略）

馬方華：這種狀況我之前搞過，不影響功能的狀況下，我會寫個編譯宏。正常的下跑老代碼。另外的慢慢把新代碼加進去。

沈欽偉：我是在保證項目能正常運行狀況下，慢慢改裏面的，等我新改的所有能用了，就把老功能遷移到個人新代碼上。不過，有些東西，這個老項目 Bug 是越改越多，動的時候須要當心翼翼。

麗娟：我之前也接手過外包代碼，我先把相關bug改好，再一點一點抽取代碼，有次一個頁面一樣的接口分別寫了四五遍。

蔣連成：個人作法是，首先不要過分優化，作到相關邏輯，把相關邏輯提取出來優化。暫時無關的邏輯先放着。從小到大一點點來，先把能夠複用的 view 什麼的，一點點提取出來封裝。比較忌諱的是一上來就想着所有優化，過分優化每每會「吃力不討好」。能用是最重要的，其次纔是好用！

馬方華：寫代碼的時候，我通常看下微信classdump後的頭文件。看他們怎麼寫。類是怎麼封裝的。而後再本身寫，本身寫的可能不是特別好。

神州租車：重構仍是要理清楚業務比較好，要否則改了也是一堆 bug。再者，我以爲一切仍是以本來業務爲核心內容，再去對應代碼比較好點吧。

曹理鵬：咱們通常都是一兩天就會進行一個小的回憶，統計修改好的和近期要處理的問題。不過，每次改完以後有種剛剛看到太陽又要天黑的感受！

午夜修鈴：重構，我理解是一個程序員的基因，是寫在骨子裏的。每一個項目所在的環境不同，因此代碼的質量也不一樣。通常的外包，對代碼質量要求很低，注重的是時間。因此寫的都比較差。這個是毋庸置疑的。不能用這個來評價一個程序的水平。再者，剛說的一個功能寫了屢次，主要問題不在重構，而在溝通。

程序員是一羣「偷懶」的人，累多了，纔會去想辦法偷懶，我們此次討論，重點不是接手與否，而是你碰到了後，如何處理？

阮濤：先跟着斷點走一遍，理解以前的邏輯纔好動手改啊。

騰訊微信：遇到這種代碼我通常是不會接手的，就算接手了也是新的功能用本身新的框架。

馬方華：少寫廣播。感受這樣改代碼也方便好多。

沈欽偉：其實好多項目是功能優先，時間越短越好。決策層看的不是你代碼寫的多麼漂亮，是功能有沒有實現，尤爲是外包項目！況且好多項目都是沒到2.0就死了。

王雲振：對於界面複雜的 Controller，是否是能夠考慮把界面一塊一塊的封裝成一個View。

曹理鵬：也就是 MVC 的思想去改！

蔣連成：通常狀況下，是將每次功能相關的邏輯優化，該提出來的提出來，該複用的複用。一個模塊一個模塊來。不熟悉的邏輯，儘可能不要動，能夠先改改結構。

好比將一些東西單獨封裝到 category 中，邏輯不動，只是位置移動。

午夜修鈴：我理解差一點的代碼，不僅是重構，就比如剛剛主持人說的，問題其實不少。要一條一條梳理。若是我遇到，第一步，多是先處理目錄結構，把目錄調整好。

Eric 胡：目前咱們公司用的是 MVP 模式。

曹理鵬：不知道是否有人，邊改邊抽到一個新的項目裏面，當新的項目成型了就廢棄老的，不知道這樣算不算？

蔣連成：測試怎麼辦？測新項目仍是老項目？發版是發新的仍是老的？首先，時間會很長，你須要兩頭兼顧。

麗娟：最好仍是一份代碼，兩份代碼太累了。

Eric 胡：好的設計模式感受對新人來講壓力太大。

曹理鵬：每一個人都說說遇到的問題吧，或者我的的經驗！

李小三：代碼儘可能要統一。

午夜修鈴：我遇到比較差的，或者是很彆扭的（不必定是差，只是很彆扭）

一、修改目錄，修改爲我認爲看着舒服的，通常這一步過去，就大概知道有多少是重複的了。同時找東西會方便些；
二、修改類的初始化方法，初始化方法改爲本身看着舒服的，或者是傳參明確的。這樣後面用的時候，我會比較順手；
三、按照功能整理類中的方法。主要是優化邏輯，性能上不考慮；
四、調優性能；
五、開始去除抽取方法和類，有第一步和第三步，基本上這裏去掉沒用的類就已經比較方方便了。

基本都是遵循從大到小，從總體到局部的方式。

王嶽明：我說的比較實際的啊，勿噴！垃圾代碼確定會有，特別對於大型項目，最重要的是穩定。接手垃圾代碼固然比較噁心，但須要從時間成本和人力成本上去考慮，只有資源充足的狀況下才去作重構優化，不然最好仍是以日常心對待。有代碼潔癖的同窗，新增代碼最好按代碼規範來寫，老代碼能改則改，實在維護不下去了則必須重構。

Eric 胡：個人第一個觀點就是，絕對不要出現硬編碼，全部的配置也不放在代碼裏。前期要肯定好框架，不要想着之後再重構。若是功能穩定，我會在他的設計思路上進行維護，新功能我會在本身的 library 裏去實現。

Waizau：之前是，有時間的纔會重構再繼續開發，否則實在會一邊寫本身的代碼一邊罵的。

李小三：接手，先別動，慢慢修改，以完成任務爲主。不是一朝一夕的事情

馬方華：垃圾代碼的框架通常很難改。一改就是兩三個 Bug。而後就被領導問話去了。而後談代碼質量。

陽華：咱們是先鋪點，把產品功能點先上去，等市場驗證後，再把原代碼重作。

Waizau：其實不該該按照代碼行數來肯定一個類是否是什麼的，一個一萬行代碼的類，你拆開十個類來寫？除了一些能夠重用的方法必須抽出以外，假如真遇到都不能重用的，還有必要拆開來寫嗎？

曹理鵬：關於爛代碼的那些事（上）

關於爛代碼的那些事（中）

窩窩：曾經接過一個架構很坑爹的項目，要迭代，只能心平氣和的多打log跟蹤熟悉。

Reic 胡：我遇到一個項目。用 MVP 模式開發，後來編程 VP 模式了，後來又編程 MVC 模式了，實在是......至於如何接手？我感受只能是不斷的 Debug ，打 Log ，看熟看懂。就好像看一我的同樣，一天兩天不熟悉，時間久了，感受那我的的思惟方式也慢慢掌握了。

而後，就是畫uml圖、思惟導圖還有流程圖 ，我是實在看不懂的就刪除吧！我感受垃圾代碼都沒什麼設計模式可言，畫圖就很清晰了。

管振偉：再垃圾的項目代碼，也不能開始就推倒重來。重構須要對需求的充分理解，還要足夠的測試用例保證。不然你可能要好久纔能有一個用來發布的版本，還有一堆 Bug。並且通常項目交付都有時間的約束。而後充分理解需求，理解原始代碼的意圖很關鍵。有條件最好能多和原始做者溝通。

馬方華：先改大頭。不然代碼愈來愈爛。一改就是大 Bug。並且不容易定位。

曹理鵬：若是爲了項目的長遠，或者咱們要在裏面呆久下去，光光改一些 Bug 或者需求並不夠！

羅飛：你們討論真熱烈，我分享一下個人觀點吧，拿到別人代碼，所先要看懂別人的代碼，本身要掌握一些分析代碼的方法，不要排除看別人代碼。這是我分析 PHP 程序的方法，相信移動端也能總結一些方法的。

本文系國內 ITOM 行業領軍企業OneAPM 工程師整理。咱們致力於幫助企業用戶提供全棧式的性能管理以及 IT 運維管理服務，經過一個探針就可以完成日誌分析、安全防禦、APM 基礎組件監控、集成報警以及大數據分析等功能。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客

本文轉自 OneAPM 官方博客