在軟件行業，經常看到有的公司管理讓一個人修補另一個人代碼裏的BUG。有時候有人寫了一段代碼，扔出來不管了，然後公司管理讓其他工程師來修復它。我想告訴你們，這種方法會很失敗。

首先，讓一個人修復另一個人的BUG，是不尊重工程師個人技術的表現。久而久之會降低工程師的工作積極性，以至於失去有價值的員工。代碼是人用心寫出來的作品，就像藝術家的作品一樣，它的質量牽掛著一個人的人格和尊嚴。如果一個人A寫了代碼，自己都不想修復裏面的BUG，那說明A自己都認為他自己的代碼是垃圾，不可救藥。如果讓另一個人B來修復A代碼裏的BUG，就相當於是讓B來收拾其他人丟下的垃圾。可想而知，B在公司的眼裏是什麽樣的地位，受到什麽樣的尊重。

其次，讓一個人修復另一個人的BUG，是效率非常低下的作法。每個人都有自己寫代碼的風格和技巧，代碼裏面包含了一個人的思維方式。人很難不經解釋理解別人的思想，所以不管這兩人的編程技術高下，都會比較難理解。不能理解別人的代碼，不能說明這人編程技術的任何方面。所以讓一個人修補另一個人的BUG，無論這人技術多麽高明，都會導致效率低下。有時候技術越是高的人，修補別人的BUG效率越是低，因為這人根本就寫不出來如此糟糕的代碼，所以他無法理解，覺得還不如推翻重寫一遍。

當我在大學裏做程序設計課程助教的時候，我發現如果學生的代碼出了問題，你基本是沒法簡單的幫他們修復的。我的水平顯然比學生的高出許多，然而我卻經常根本看不懂，也不想看他們的代碼，更不要說修復裏面的BUG。就像上面提到的，有些人自己根本不知道自己在寫什麽，做出一堆垃圾來。看這樣的代碼跟吃屎的感覺差不多。對於這樣的代碼，你只能跟他們說這是不正確的。至於為什麽不正確，你只能讓他們自己去改，或者建議他們推翻重寫。也許你能指出大致的方向和思路，然而深入到具體的細節卻是不可能的，而且不應該是你的職責。這就是我的教授告訴我的做法：如果代碼不能運行，直接打一個叉，不用解釋，不用推敲，等他們自己把程序改好，或者實在沒辦法，來office hours找你，向你解釋他們的思想。

如果你明白我在說什麽，從今天起就對自己的代碼負起責任來，不要再讓其它人修補自己的BUG，不要再修補其他人的BUG。如果有人離開公司，必須要有人修補他遺留下來的BUG，那麽說話應該特別特別的小心。你必須指出需要他幫忙的特殊原因，強調這件事本來不是他的錯，本來是不應該他來做的，但是有人走了，沒有辦法，並且誠懇的為此類事情的發生表示歉意。只有這樣，程序員才會心甘情願的在這種特殊關頭，修補另外一個人的BUG。

【轉】其他人的BUG