程式設計師修復乙個bug的心路歷程，太形象了

當別人想我們報乙個bug，直到我們把bug完整的修復好，整個過程是乙個怎樣的經歷？

下面用乙個電燈維修工的故事模擬一下，相信會引起很多開發者共鳴：

假如你是乙個電燈維修工程師。一天晚上，有人想你反饋了乙個bug：「18樓會議室的燈亮著，你要去把它熄滅」。bug的備註裡還寫到：這個bug很簡單，你只需要按一下開關就可以關掉了，你應該在5分鐘內修復這個不管。

你上到了18樓的會議室，燈的確是亮著，但是房間裡沒有這盞燈的開關。

怎麼辦？你準備安裝乙個開關。這個時候設計師會跟你說，它會破壞房間的美感。另外，牆壁是混凝土做的，你得有合適的工具和其他人的配合才能安裝。但此時此刻，你找不到這些工具和人員來幫你。

如果沒有這些輔助工具，安裝開關，保守估計要2天時間。但是他們希望你只花5分鐘就把燈關掉，因為他們害怕ceo哪天會經過18樓會議室，問為什麼燈是亮著的，怕被問責。

5分鐘過去了，你的手機響個不停，他們反覆問你為什麼燈還亮著，為什麼按一下開關就能關掉這麼簡單的事你要弄這麼久。

為了盡快解決問題，你實在沒辦法，所以，你設法進到了 18 樓走廊的天花板裡，找到了會議室燈的電線，一刀切斷，燈關掉了，問題解決了，你告訴了他們你的解決辦法。

你的手機也安靜了，但好景不長，他們又有了新的疑問：線被你切掉了，如果哪天我們想開啟會議室的燈，怎麼辦？因此，他們要求你把這盞燈的線牽引到地下室去，因為那裡有開關，等他們需要開燈的時候，就通知你去地下室幫他們開燈。

你**這個荒謬的解決方案。但是你的上司說：「是的，這個解決辦法不理想，但是現在是唯一的解決方案」。

這個時候你心裡罵了他們一句：sb！現在你要麼按照他們的「荒謬」要求來做，要麼辭職另謀高就，但你想了想，一旦到了新的工作環境，也難免會遇到這種荒謬的事情。

你咬咬牙，把18樓會議室的線牽引到了地下室，你發現已經有10幾條線是從其他地方牽引過來的，這種荒謬的做法，你不是第乙個做。你小心翼翼地把線牽引號，並盡人事地給左右地線做好了標記。

終於，你回到了你的辦公桌，把bug標記成：「已修復」。可剛過不就，測試員又重新開啟了bug，並備註說：「會議室還是亮著的」。

你回到 18 樓的會議室。燈是滅著的。你返回辦公桌前，關閉了 bug，註明你已經親自檢查過了。

測試員再次重新開啟了 bug：「房間還亮著」。再次親眼確認燈泡滅著後，你將情況匯報給了上司。他建議你去地下室檢查電線和開關。你**說你正直盯盯地看著燈，它就是滅著的。「我知道，但去檢查一下。這樣一來你就可以告訴測試員你確認了所有流程。」

你嘆了口氣，前往地下室檢查了電線和開關。它們不可能以任何你能理解的方式導電。你向測試員反饋，你檢查了電線和開關，它們不可能通電，你正看著燈泡，它是熄滅的。

「我不是指燈泡，」測試員說。「bug 裡描述的是房間裡的光。房間現在仍然不夠暗，你應該拉下窗簾。「你回應說窗簾的事不歸你管。測試員不相信你說的話，親自去詢問你的領導。

經過一番激烈的討論之後，他們終於同意將窗簾的問題提交給其他部分去解決，太好了，燈光的問題暫時到此為止了，bug可以順利地關閉掉了。

現在，ceo突然決定要去18樓會議室開會。你接到通知，要趕去地下室，開啟18樓會議室的燈。

你以最快的速度去到了地下室，連上電線，按下開啟按鈕。回到了辦公桌，此時你的手機有了26個未讀訊息：

「出問題了，燈還是熄滅的！」

「有個問題，燈沒有亮。」

「為什麼這麼久還沒有亮燈？」

而最新的一條訊息則是：「沒事了，燈是亮的」。

另外還有一點可以通過自身的學習來獲取一大進步。

究竟有哪些乾貨呢？先給你們乙個目錄：

免費領取資料途徑：公眾平台「程式設計資源庫"