程序員為什麽加班太多？有可能是代碼寫得爛

加班是大家老生常談的話題了，國內互聯網公司加班現象更是嚴重，而互聯網公司中則要數程序猿加班最為厲害。很多人是在加班，但不代表很多人願意加班，可能剛入職場的小白倒是幹勁十足，成了工作狂，或者是熱愛工作，又想證明自己的人生價值不斷投身於事業中的人…

於是，眾猿們議論紛紛，好像在密謀什麽大事……

比如反抗：

@ooppstef：

一個是不知道怎麽反抗，離職到下一家加班的概率也大，BAT 大部分團隊都加班。另外，競爭大，很多時候自己也想提速做產品，加班也是自願的。

@15015613：

根本原因是缺少反抗的組織者。一個人反抗，完全是找死。聯合起來才有希望，想要聯合起來便要有組織者、帶頭人，代表工人利益的工會跑哪去了？

@suilongfei：

別較真，不然大家都沒飯吃。

也有人覺得加班是必要的，不然會被幹掉的：

@sagaxu：

如果 A 流水線工資是 B 流水線的 2 到 10 倍，B 流水線的人會不會願意免費加班換取 A 流水線的一個職位? 說到底還是供需決定的，互聯網是少數既不需要拼爹又沒有很高門檻的高薪行業。

@zartouch：

互聯網是工作量大節奏快，要高薪就要承受大工作量。你加班只是因為你工作做不完而已，拿多少錢做多少事，這麽簡單的事情不用我再強調了吧？

大部分人都是客觀吐槽：

@EleanorKusosaki：

根據我對我司的 JAVA 的觀察，我發現是這樣的。他們一般都是單身租房，回去也沒事幹，不如在公司裏面消磨一下時間，寫寫代碼吃吃飯看看書，還能賺個晚飯補（當然長此以後就更加找不到對象了）。然後，不然就是家庭不圓滿不想回家做家務…就熬到半夜再回去，不然就是做不完活。

@mytsing520：

你得證明確實是公司讓你加班，而不是你主動加班。公司讓你加班，按法律來說必須付給加班費；主動加班，事後公司認可的，也要付給加班費；如果純粹是為了處理完問題而主動加班，法律不認可其加班事實。

@coderluan：

1. 行業產出太難評價，不像流水線工人可以按件計費，所以加班就有錢，難免有人磨洋工，加班費就就不如績效好操作。

2. 這個行業其實人很多了，中國年輕人壓力又大，很多人都是主動選擇加班的工作的，畢竟工資肯定高一些，而就行業 1+1<2 的特點來說，公司肯定偏向於能加班的。

3. 環境確實有問題，但是中國問題多了去了，而大部分人只關心自己遇見的問題，所以任何問題就解決不了。

那麽回到一開始的問題：程序員為什麽加班太多？有可能是代碼寫得爛

那怎麽寫出好代碼，從而不加班呢？

請註意：這不是一篇證明誰導致程序員加班太多的論證文，也不想給大家灌雞湯，讓大家一夜之間都變成編程高手，但是至少說一些實實在在的經驗和方法。總之讓大家多看一點就多獲得一點實際的價值。

一、不要一上來就開始寫代碼

你可能性子急，也可能早已按耐不住躍躍欲試昨天剛學會的一個編程小技巧，我想要告訴你的是，不急，收起你那磨刀霍霍的表情，在你拿到需求準備寫出你第一行代碼之前還有更重要的事情要做。我想怎麽強調這件事情的重要性都不為過，在我以前寫的自己非常滿意的代碼經歷中，我都采用了這個方法，它能消滅原來可能會被測試提的 90% 的 Bug 單，甚至做到零缺陷，當然做到這點可能需要一個過程。

拿到需求之後你首先要問下自己對需求是不是已經充分理解了，得到肯定的回答之後，我們就可以開始了：

1) 先在你忙碌的工作中，找出你能完全掌控的一個小時時間段，這一個小時完全屬於你自己，保證這一個小時不會有任何打擾，或者任何能影響到你執行不下去這個方法的打擾。要記住這一個小時非常重要，比你後面要執行的所有活動的時間都重要，它絕對值得。

2) 在第一張白紙的上方寫下「該需求特性的正常流程和影響範圍」，然後在白紙下方逐條開始寫下該需求特性正常流程包含的內容，大概會使用到哪些庫函數，會提供出哪些接口，是否會影響版本升級，是否影響資源文件，是否影響原有的接口等等。

3) 在第二張白紙上方寫下「該需求特性所有的異常場景和本人以往經常會犯的一些錯誤點」，然後在白紙下方一條一條的開始往下寫。

4) 不斷重復第 2)、3) 步。

你可能會覺得這不就跟寫的需求澄清材料差不多嗎，我要告訴你的是這是兩回事，它不是一項質量專員要求你做的質量過程活動，這是你自己和自己之間的一次深層次對話，這不需要告訴任何人，不需要向其他領域輸出任何交付物，這是對自己要寫出優秀代碼的一次自我驅動。

一開始你可能會覺得很難，寫幾條就寫不出來了，或者閃過「這玩意兒是不是真的有用」的念頭，不用著急，起身去窗戶邊呼吸一口新鮮空氣或者去打杯水喝，總之不要中斷，除非辦公室著火了不要去幹讓這件事繼續不下去的事情。當你慢慢往下寫到第 20 或者第 30 條答案的時候，你可能突然會有一種「這麽隱晦的一個異常點都被我發現了，簡直太牛了!」的情感湧出，這個時候你會暗暗驚呼有點難以抑制自己的興奮，這說明你快要接近成功完成了，後面每寫出來的一條都會讓自己感動。記住，中間不要放棄，你堅持下去的決定會將這一個小時變成你整個需求實現當中最重要的一個小時。

二、先忘掉後面還有該死的質量活動

所有編碼之外的質量活動，都是基於公司對於你寫代碼水平的不信任產生的。也就是說公司花了大量的錢招來質量專員、網元測試、解決方案測試這些人都是因為你沒把代碼寫好造成的浪費。

常見一些開發人員，剛來的時候對質量專員安排的質量活動頗有微詞，「我以前公司做項目根本不需要做這些東西還不是一樣能把項目做完」，「這些質量活動，簡直就是對編碼時間的侵占」。說這些都沒問題，但是你一邊說著這些一邊寫完代碼後 Bug 就烏泱烏泱上來，是不是有點不要臉? 質量專員設計的這些活動，就是為了不讓你的爛代碼一瀉千裏的沖到客戶面前設計的一個個檢查站，當你對於「寫出好代碼」什麽事都沒做，只想著取消這些質量活動的話，就只能理解為耍流氓了。

那麽，做好質量活動就能「寫出好代碼」嗎? 答案是不能。質量活動只是質量專員的監管手段，它既不是目標甚至也不是方法，你寫代碼的目標不是要滿足質量活動標準，而是要追求零缺陷，也不會因為你 Wbit 測試做的好就能寫出好代碼。你要做的一個是「不要一上來就開始寫代碼」, 另外一個就是掌握盡量多的重構方法，重構思維方式，掌握重構並不一定是要對原來代碼的重構，而是下筆之前就知道好代碼該怎麽寫。

我讓大家忘記質量活動，不是讓大家不聽質量專員的話，而是大家在寫代碼的時候要心中存有敬畏，代碼寫完之後所有的活動都是你造成的浪費，你要為消除這些浪費而竭盡全力。

三、你要記住，你寫的代碼是給人看的

我之前聽一位同事講他上一家公司的一件聽來十分驚悚的故事，他原來公司的一位同事離職了，留下的是一堆十分復雜，看了會讓人神經錯亂的 C++代碼，他走了之後，發現整個項目組的人沒有一個人能接手得了他的模塊，項目經理不得不高價加請客吃飯的方式讓他過來給全項目組的人講兩天他的代碼。這個家夥大有「看吧，只有我才能搞定」的「衣錦還鄉」姿態。我好奇的是這個項目經理為什麽沒有盡早的開除他，簡直就應該報警啊。

好的代碼是讓人看來賞心悅目的，任何能力不夠或者炫技成分的增加人的閱讀障礙的行為都需要被改進，你能不能三兩句話就能說清楚你自己寫出來的代碼的脈絡，當然這同樣涉及到你要掌握盡量多的重構方法和重構思維方式。

另外還有一個自我評判的標準，就是你捫心自問一下，「你寫了這麽多代碼，你曾經為之動心過嗎?」你是否寫完之後會忍不住的反復閱讀自己寫完的代碼，並連連暗暗驚嘆代碼之美?

作為一名程序員，希望在你某天離開公司後回想起的若幹個開心時刻中，有一個會是因為你面對自己剛剛出爐了一份讓自己心動的代碼的那份感動，而不要成為上面提到的那個「離開後，公司才知道他有多麽重要」的家夥。

四、現在開始，刻意練習

你是否發現自己長期維持著「剛剛好能完成 story」的代碼水平，寫了好幾年代碼仍然會被測試人員追著屁股提單? 種種疑惑是因為代碼能力的提高跟你寫了多少年代碼沒有直接關系，你需要做的是刻意練習。

比如把我前面提到的方法反復練習，或者把你自己琢磨出來的方法分解成一項項的環節，刻意的去練習，從測試那裏得到反饋，然後不斷加以改進，慢慢你就會從一個整天被測試人員追著跑的人，變成發現自己很容易就能達到質量過程標準的人，再慢慢就會發現你寫出來的代碼測試人員越來越難發現問題，最後只要你狀態好點就能經常性的寫出零缺陷的代碼。

其實有些道理我們貌似都知道，但是我覺得離真正懂得還差了兩步，第一就是你需要親身去經歷、踐行這些道理和方法，第二就是你要能夠轉述並讓其他人也能夠明白。所以最好的學習方式就是親身經歷，然後寫下來分享給大家，這樣才能讓你真正懂得那些你原來認為懂得了其實未必懂得的道理。

【如何編寫有質量代碼】【轉】