在軟件行業，經?？吹接械墓竟芾碜屢粋€人修補另一個人代碼里的 BUG。有時候有人寫了一段代碼，扔出來不管了，然后公司管理讓其他工程師來修復它。我想告訴你們，這種方法會很失敗。

[[130373]]

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

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

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

如果你明白我在說什么，從今天起就對自己的代碼負起責任來，不要再讓其它人修補自己的 BUG，不要再修補其他人的 BUG。