大四剛到公司實習，開發任務很少，大部分工作就是改bug,優化代碼。聽聽各位大佬日常改代碼的經驗

當然是改代碼難，好比，一個是你自己從頭做一份蛋炒飯，另一個是煲仔飯要你改成蛋炒飯，你說哪個難？

如果你寫的是狗屎 那寫代碼難

如果別人寫的是狗屎 那改代碼難

感興趣的話可以關注一下我的專欄，會寫一些計算機方面的東西~

z?

zhuanlan.zhihu.com圖標

對新手來說從頭開始寫比較難，改別人的代碼通常只需要改很少的地方，或是把原來的部分代碼複製粘貼再修改，然後跑一跑測試一下結果就ok。至於你要修改的代碼以前寫得好不好、你複製以後重複度高不高，管不了那麼多，滿足功能最重要。

對老手來說自己從頭寫比較簡單，因為自己經驗豐富知道怎麼寫，而且對別人的代碼未必滿意。

一般來說，讀代碼改bug更容易一些，因為多數情況下都是比較簡單的bug，並且只需要讀懂相關的幾處代碼就可以改好bug了，只是局部要求。可能幾天就修復完一堆bug了。

例如 開源軟體 wifidog 源代碼大約一萬行，準備應用，測試有bug，例如內存泄露，有內存重複釋放，無法處理一些特殊情況，如設備網關地址正在初始化，獲得空地址的情況，上行介面地址未分配或正在分配中，上行介面掉線重新上線，介面地址變化了等等情況下有bug，修復完主要bug只花了2周時間，就達到了商用標準。

認真寫代碼需要對從頭規劃，需要對全部代碼框架和自己負責的模塊完全理解，一些 corner case ，看上去很普通的需求，要做好的話，也很考驗作者的功力。需要既兼顧全局，有大局觀，又能深入微觀，寫大量瑣碎的代碼塊，還要反覆重構，因為很難一次把所有代碼以最佳實踐的方式表達出來，大量代碼的重構不可避免，重構改善代碼的質量。開發項目往往以數月時間才能完成。

例如，最終由於 wifidog 有一些定製化開發要求，以及還有少量內存泄露未定位影響穩定性，創建和析構多線程開銷過大，去年決定從頭弄一個自研C++版本出來，大約花了幾個月時間，才開發測試完成一個功能更多，性能更優，沒有內存泄漏的版本。項目寫代碼開發很花時間。

另外，萬事都有特例，代碼原生產者的技術水平和當時開發任務安排緊不緊，公司開發流程是否正規等等，如果當年就是拼湊著上線，什麼規劃都沒有，沒有文檔，沒有注釋，各種bug層出不窮，當年的開發人員已經全部辭職跑路，那種典型的垃圾山的話，讀代碼改bug真的很難，因為你不知道對方的腦洞有多大，當時為什麼要用這麼奇怪的寫法，變數名沒有什麼規律，要連猜帶蒙這個變數是幹什麼用的，讀代碼要累死人的那種，也許重新開發更容易一些。

別說改別人的，就是改自己的都難啊，o(╥﹏╥)o

前段日子改一段代碼花了三週時間，偶發的ping不通鏈路壞掉，涉及的整個鏈路處理的代碼有個幾萬行，好多信號處理編解碼看也看不懂，也不想看，因為狀態機太複雜，函數太長，好多函數上千行，一堆查表的代碼都不知道咋算的。

我第一週週末大概框定了問題，但是我週五沒有很好的描述它記筆記就出去玩了，玩了兩天回來週一已經全忘了，在另外一個軌道上打了一大片log, 噁心了自己一個禮拜，這種問題單步工具沒有屁用，打log 幾十秒就能打幾G, 到週末我只好加班了，週日我在哪裡眯縫著眼一邊喝酒一邊看log忽然想起我一週前框定的範圍，我又試了幾下確認應該有個狀態機是不好的，我就回家了，週一白板上畫了下推了下改了三行代碼就完事了。

這種不是太難復現的不算難的了，有些仨月也改不過來，有些人乾脆就加個功能讓它崩了自己再重啟。

剛好有篇文章寫了類似的問題（讀代碼而非改代碼，不過原理是一樣的，改之前肯定要先理解清楚代碼，然後才能動手），摘錄一部分 姜太公：如何閱讀代碼

為什麼讀代碼很難

讀代碼並不比寫代碼簡單，閱讀代碼的困難源自以下幾個方面。

首先，實現一個功能，存在多種具體的實現方式。即使是同一個思路的演算法，最終產生的代碼也有多種表現形式，不同代碼的風格、變數的命名、if嵌套或者for/while的選擇都會影響最終呈現的代碼。閱讀代碼時，人腦充當了編譯器的角色，不過通常意義上的編譯，而是反向從代碼的表現去理解代碼的意圖。眼睛看著代碼，根據它在做什麼反向推導它要做什麼。更複雜的是，不僅要看靜態的代碼，還要在頭腦中構造一個運行時的狀態轉換。

舉個簡單的例子，看到下面這段代碼，你能分析出它在做什麼嗎

void do_somthing(){
x := A[(hi + lo) / 2]
i := lo - 1
j := hi + 1
loop forever
do
i := i + 1
while A[i] &< x do j := j - 1 while A[j] &> x
if i ≥ j then
return j
swap A[i] with A[j]
}

上面的代碼其實是快速排序的一次partition，很多人都熟悉，可能還比較容易猜得到它的目標。確定了一個目標，實現代碼有好有壞，但是給出一個能正常工作的代碼並不算很困難。例如實現一個排序功能，對大多數人來說可能都不是問題，但是從代碼去反推行為反而更困難，寫代碼是順著自己的思路，讀代碼是順著作者的思路。

其次，一段代碼的輸入並不只是其參數，輸出也不只是返回值。代碼執行過程還會依賴各種外部狀態：全局變數、進程外數據甚至網路上的數據。閱讀代碼時不僅要關注眼前的一段代碼，還要考慮各種外部數據，考慮這些數據的結構以及能夠對數據施加的各種操作，還有每種操作所導致的數據變化。代碼運行過程中也會修改外部狀態，閱讀代碼的過程中不僅要關注代碼中自身數據的狀態變化，還要考慮對外部數據的修改。

最後，實際的項目代碼通常不是上面快速排序這麼簡單單純，而是包含了複雜的概念和數據結構，眾多的模塊，各種各樣的介面，冗長複雜的數據轉換邏輯。每一段代碼並非獨立存在，而是作為一個更龐大整體的一部分。最要命的是代碼裏通常充斥著各種神奇補丁，以解決某個特定場景特定時間特定輸入數據時才會遇到的問題，除非你能從其他渠道（例如注釋或cvs log），否則想破腦袋也沒法理解為什麼這些代碼的意圖（別忘了讀代碼的目的就是分析意圖）。

當然，有些代碼由於作者能力問題，寫出來的代碼完全不具備可讀性，這種情況不在討論之列。

當然是改，每個項目每個人的設計思路不一樣啊。

取決於任務目標，例如：

任務1: 調整應用的字體大小

  • A 直接修改一個應用的字體大小
  • B 重寫做一個應用來滿足對於的字體大小

任務2: 業務需求變更，對幾年前的一個功能模塊重構

  • A 在原來很多人維護的模塊基礎上重構。
  • B 自己重新設計，重寫代碼。

看那坨更香

改代碼難，寫別人容易看懂的代碼更難

最容易的就是改bug了，新人都是先安排改bug。

改bug為啥說容易呢？因為你幾乎可以不懂任何業務，框架，對著測試用例把開發環境搭建起來複現bug就可以進行下一步工作了。無需培訓立即上崗。

通過改bug來看你水平，水平可以的轉正開發新功能，水平高的提前轉正（比如我，當然我提前轉正也跟會和領導勤反饋又聽話有關）。

水平不行的，就一直改bug吧。我們那有個女生進來幾年了，就沒開發過新功能。

不是難不難的問題，主要是自己寫代碼可控，改別人的代碼，甚至改自己很久之前寫的老代碼，不大可控。

改代碼難

改自己代碼都難-。- 有時大的思路錯了，寧願重寫都不想改

雖然他已經離開了公司，但程序裏處處都有他的身影。

自己寫代碼就是拉一坨屎，改別人的代碼就是把別人的屎喫下去再拉出自己的屎。

改別人代碼要看對方的代碼水平與注釋文檔

如果沒有注釋沒有文檔……我覺得改自己的畢竟容易

改代碼難

就像番劇一樣，第一部是最好畫的，前面的一般只管自己爽，留下無數坑，後面的就要來填了

我是菜雞新手，我覺得自己寫比改難幾個量級感覺要考慮的東西太多了

推薦閱讀：
相關文章