程序員寫出爛代碼

A. 你們是怎麼看待那些動不動就說別人代碼很亂的程序員

可以把這個作為互相交流的契機，既然他覺得亂，你就跟了解清楚為什麼覺得亂，怎麼才能不亂，說不定他說的有道理，你就能學到東西了，如果他說的不對，就用疑問的方式委婉地提醒他一下，如果他還是那樣，就隨他去了，他的觀點不重要，又不會影響到什麼的話，聽聽就好。

B. 有哪些新手程序員該知道的工作小技巧

1.積極大膽的谷歌。你得知道如何有效的組織搜索關鍵字，查閱別人寫的代碼，然後合理地用在代碼里，從而解決問題。

2.擁抱變化，堅持不懈。老手程序員在接觸新技術時，能欣然接受像個初學者一樣處處受挫，並總能在完成工作的同時自學成才。

3.承認細節的重要性。例如變數和函數的命名、CSS屬性的命名、該用哈希還是數組，以及其他看起來微不足道，但可能對項目有深遠影響的事情。

4.承認大多數的「重要決定」其實並沒有那麼重要。一般的開發者經濟常在技術選型等「重大問題」上陷入唇槍舌戰，而程序員老鳥們會避免浪費時間在罵戰中。這一點上，它們就像禪宗大師一樣。

5.選擇合適的工具解決問題。網上有無數的開源庫、工具和框架，讓人眼花繚亂。而老手們清楚地知道針對怎樣的問題，應該用怎麼樣的工具。

6.明白代碼「不值錢」（該刪就刪）。你必須習慣於刪掉幾百行代碼來重寫程序的某一部分，毫不留情。

7.在評估技術的時候要全面。例如，我一直在鼓吹Elixir。它語法優美，社區完善，有很大的潛力。但Elixir誕生的時間太短，所以如果要構建復雜的功能，可能會難以找到能幫你提高效率的開源工具。因此，在評估要不要選擇使用一項技術時，你得把所有這些因素都考慮在內。

23.知道什麼時候開始回饋。到了某個時候你需要將你的技能和經驗傳授給年輕的開發人員，就像你的導師當時教授你一樣。

24. 能寫爛代碼。有時候可以當一當「膠帶式程序員」。關鍵是隨著時間推移，你需要弄清楚什麼時候可以走捷徑，什麼時候必須走捷徑。這其實是最難掌握的技能之一。

25. 禮貌地告訴別人你工作到很晚。如果你是辦公室里最後一個，可以發一封簡短的匯報郵件。別人一般會注意到郵件上的時間戳的。

26. 像一個領導者(Leader)一樣做事，而不是老闆(Boss)。老闆是讓別人為他工作的人，領導者是人們追隨的人。做個領導者。

27. 去打打桌上足球。從長期來看，同其他開發者（或不同崗位上的同事）建立聯系比在緊巴巴的期限里交付一個功能更有價值。

28. 在壓力下學習。你需要知道如何應對像系統宕機而你要負責將它復原的情況，即使一開始你完全沒有頭緒。

C. 如何看待程序員日均寫7行代碼被開除，大家對此事件有什麼想說的呢

不是我不明白，這世界變化快。俺當年入職時，一些公司的確會問代碼量。當時的標准大約是每周40到400行代碼，可以少，但不能多——換句話說，平均來說，每周多於400行代碼的可能得不到工作機會。因為你的代碼質量和工作態度讓人家心裡發毛。當然，也沒人太較真。功能點完成了、代碼質量可以（bug少、代碼邏輯清晰、文檔齊全），多點少點無所謂。

先後在多家公司擔任技術專家；平均來說，每周代碼量也就200行上下。當然，也搞過一次一天寫了2000行代碼的壯舉，結果是之後一個多月腦袋嗡嗡響，眼花，惡心。這個東西我事先花了一周多做設計、寫文檔，然後第二周的某天一氣呵成，寫完bug；然後累傷了，一個多月沒法工作。換句話說，相當於還是花了6周；平均下來，仍然是每周300來行代碼。

公司在與李某某簽訂勞動合同時並沒有約定一定要進行深度學習識別演算法代碼編寫，3D點雲演算法和多攝像頭聯合演算法代碼編寫的具體工作內容，所以沒有指明非要編寫這些代碼；拿什麼同級別同行業的平均每日編寫代碼的統計數據來作為考核的依據，沒有法律根據，任務不同，編寫難度不同，不能以編寫條數作為考核的依據；

至於工作內容，作為程序員並一定非要整天的在編寫代碼，也有可能在設計新的方案，或是對數據進行統計分析和總結等，不能以什麼編碼工作沒有做，就認為李某某沒有做出「成績」；作為剛來才兩個多月的程序員，前期的准備和熟悉是需要一個過程的，隨著對公司的熟悉和項目的了解，編寫代碼的速度必然會提高，而不能在剛來兩個月就以其他老員工的標准來進行考核；在發出解聘通知書後，馬上將其辦公電腦進行收回，這是嚴重的不尊重人，這屬於單方面強制辭退，沒有給李某某一點申辯的餘地。以上，公司理應對李某某進行賠償。

D. 你的代碼出bug了，程序員聽到這個時的表現太真實了

這個大撒比寫出這么個爛代碼，幸虧有哥這樣神一樣的存在才發現，哥真是救世主。

這個程序運行很久了是不是真有bug啊，是不是你弄錯了啊，可以重現么，什麼？可以重現，有尼瑪問題也不大，要不用戶早投訴了，瞧你那驚慌失措的樣子，真想吐你一臉狗屎。

這個bug隱藏的很深啊，還好哥犀利犀利，沒有被領導發現，今晚加個菜。

這個程序剛上線還處於調試階段，有bug很正常，誰的程序沒bug，連操作系統都有bug。

哥就是犀利，自己開發自己測試，看測試那幫撒比什麼也不會干，這么明顯的bug都測不出來，真是一群廢物。

1、「是刪除它還是修改它呢？好糾結 ！」

2、網上一定有解決辦法。

3、是誰動了我的代碼？

4、完全不知道這些代碼是神馬東東。

5、哦，為什麼我都沒寫注釋呢？

6、算了，廢了他，我還是從頭開始吧！

程序員自身可以在程序生成的每個階段做這些工作： 仔細的設計、編寫代碼時、單元測試(重要)、功能測試。

E. 作為一個程序員，面對別人寫的稀爛的代碼，怎麼辦

在查閱代碼時，經常會發現一些寫的不合理的代碼。
面對這些代碼，首先需要確認修正這些代碼的影響范圍。

最理想的處置是對代碼進行重構，從根本解決代碼的混亂問題。
但是大多數情況，我們沒有時間進行重構，或者無法確保重構之後的代碼不會出現問題。
建議先解決最棘手的問題，然後慢慢對代碼進行分析，重構。

F. 歷史上有哪些因為程序員寫出的bug而造成的事故

1. 火箭爆炸，原因：類型強轉（64b浮點->16b整數）導致異常
2. 火箭爆炸，原因：Fortran代碼筆誤（少一個減號）
3. 火星車故障，原因：vxWorks優先順序逆轉 -
4. 火星探測器墜毀，原因：用錯計量單位（磅與牛）
程序員導致的事故挺多，這些是嚴重點的。還有游戲更新把用戶電腦上文件刪光的...

G. 編程老手的哪些特點，是值得新手程序員學習

1. 活躍斗膽地谷歌。你得知道怎樣有用地安排查找要害字，查閱他人寫的代碼，然後合理地用在代碼里，然後處理疑問。
2. 擁抱改動，持之以恆。內行程序員在觸摸新技能時，能欣然承受像個初專家相同處處受挫，並總能在完結作業的一起自學成才。
3. 供認細節的首要性。例如變數和函數的命名、CSS 特點的命名、該用哈希仍是用數組，以及別的看起來微缺乏道，但也許對項目有深遠影響的作業。
4. 供認大大都的 「首要抉擇」 本來並沒有那麼首要。通常的開發者經常在技能選型等 「嚴峻疑問」 上墮入唇槍舌戰，而程序員老鳥們會防止糟蹋時刻在罵戰中。這一點上，他們就像禪宗大師相同（zen-like）。
5. 挑選適宜的東西處理疑問。網上有很多的開源庫、東西和結構，讓人目不暇接。而內行們了解地知道關於怎樣的疑問，應當用啥樣的東西。
6. 了解代碼「不值錢」（該刪就刪）。你有必要習氣於刪掉幾百行代碼來重寫程序的某一有些，毫不留情。
7. 在評價技能的時分要悉數。例如，我一向在宣傳 Elixir。它語法美麗，社區完善，有很大的潛力。但 Elixir 誕生的時刻太短，所以假如要構建雜亂的功用，也許會難以找到能幫你行進功率的開源東西。因而，在評價要不要挑選運用一項技能時，你得把一切這些要素都考慮在內。
8. 學會說 「我不知道」。沒有比回絕供認自個不知道更能糟蹋一個開發者的時刻了。
9. 細心剖析過錯信息里的條理。傳統教育通知咱們：失利是壞事。報錯信息這種東西也經常被跟失利聯絡起來，但是優異程序員了解，這些過錯音訊里本來隱藏著能將你指向終究准確處理計劃的條理。
10. 了解過早優化和必要的 「炫技式」 優化的區別。內行們了解在啥時分需求寫一些看上去沒那麼好懂，但會讓程序運轉更快的代碼。
11. 每自個都會犯錯，為自個的過錯擔任。而格外在團隊里，把職責推來推去沒有任何含義，由於過錯的發作通常不只僅一方的要素構成的。
12. 變成你所用的開發東西的重度用戶。假如長時刻在某個開發環境下有恰當份額的開發作業，那你應當去把握運用它的細節。
13. 學會用 Vim（最少會一點）。 你最少應當在這個修改器里學會牽強地移動和翻頁。
14. 不要接生疏技能范疇的私活。自個做自在作業項目，其間很大一有些應戰即是評價項目時刻。不要計劃自個未知范疇的作業，那會讓你處於想當為難的地步。
15. 不要數你幹活花了幾個小時。技能大牛會把時刻花在有深度的作業上，並且他們了解花了多少時刻徹底不首要。
16. 學會安然承受批評。當你的代碼由於各種要素支離破碎時，你需求培育用理性和邏輯的辦法來應對（而不是心境化處理）。
17. 同有更多閱歷的人結對編程。沒有比這個更高效的編程學習辦法了。
18.必定要先自個做一遍代碼檢查。當你在 GitHub 上建議一個 pull request 之前，先把代碼當成他人寫的，自個先檢查一遍。
19. 認識到做自在作業的難點不是寫代碼，而是別的的一切作業。出售、推行、客戶支撐，質量確保以及產品處理，一切這些都會花費很多時刻。
20. 發現並處理更大的疑問。優異的程序員不拘泥於眼前的疑問，而是了解怎樣用更久遠的辦法徹底的處理這一類疑問。
21. 深化了解一些大型開源項意圖基地能讓你開發時如虎添翼。假如你知道怎樣給你的項目打山公補丁 (Monkey Patch), 那麼你將無所不能。
22. 越過大都的會議。你的公司雇你是來寫代碼的，而不是談代碼的。當會議多到失控的時分，不去參與也沒有任何疑問。並且一旦你開端這么做，他人會更愛惜你的時刻。
23. 知道啥時分開端回饋。 到了某個時分你需求將你的技能和閱歷傳授給年青的開發人員，就像你的導師其時教授你相同。
24. 能寫爛代碼。有時分可以當一當 「膠帶式程序員」。要害是跟著時刻推移，你需求弄了解啥時分可以走捷徑，啥時分有必要走捷徑。這本來是最難把握的技能之一。
25. 禮貌地通知他人你作業到很晚。假如你是作業室里終究一個，可以發一封簡略的報告郵件。他人通常會留心到郵件上的時刻戳的。
26. 像一個領導者 (Leader) 相同幹事，而不是老闆 (Boss)。老闆是讓他人為他作業的人，領導者是我們跟隨的人。做個領導者。
27. 去打打桌上足球。從長時刻來看，同別的開發者（或不相同崗位上的搭檔）樹立聯絡會比在緊巴巴的期限里交給一個功用更有價值。
28. 在壓力下學習。你需求知道怎樣應對像體系宕機而你要擔任將它恢復的狀況，即便一開端你徹底沒有條理。
29. 「Move fast and break things」 別讓完美主義阻撓你幹事。過錯通常是最好的學習時機。所以別把犯錯當作失利，而應當把它們當作值得學習的閱歷，並意識到：恰是不斷戰勝和打破這些過錯，作為一個程序員，你才幹不斷生長起來。

H. 為什麼有的程序員的代碼結構混亂

程序員都有一顆工程師的心，所以當他們到一片新的場地想做的第一件事就是，將舊的一切推倒重來。是的，他們決不會滿足於簡單的增量勞動。

或許這種微妙的心理定位可以解釋：為什麼程序員進入新項目組後寧願丟掉舊代碼重新寫，也不願意修修補補。他們認為舊代碼簡直一團糟。

但是，事實上真是這樣嗎？你之所以認為舊代碼一團糟，其實是由編程的一個基本定律決定的，那就是：寫代碼容易，讀代碼難。

為什麼你覺得舊代碼異常混亂？因為讀代碼更難。

這大概就是代碼Reuse難以實現的原因。 這就是你組里的每個人都喜歡用不同的功能將分割的字元串轉換成一個數組。比起猜測舊的功能是怎樣實現的，重新寫一個自己的功能要簡單和有趣多了。

作為這個公理的推論，你可以問問身邊的程序員他們正在奮戰的代碼怎麼樣？「簡直是一塌糊塗！」他們肯定會這樣說。「我簡直想推倒重來！」

為什麼認為代碼這么糟糕呢？「額，看看這個功能，竟然有兩頁長！完全不知道這些東西為什麼在這里！完全不知道這些API是干什麼的。」他們會這樣回答你。

漫畫：讀別人代碼是一種怎樣的體驗？

曾經，Borland的創始人 Philippe Kahn當初就是向記者們吹噓：Quattro Pro會比Microsoft Excel要好用得多，因為它是從頭開始編寫的，全部都是新的源代碼！

但是，認為新代碼比舊代碼好簡直就是荒謬。舊代碼是已經運行過的，測試過的。無數的bug在被發現前都上線運行過，發現之後程序員們可能在花了好些日子才修復了這些bug。這種修復可能是一行代碼，也可能是幾個字元，無數的時間和精力都花在了這些bug修復上。

當你決定拋棄這些舊代碼從零開始的時候，你也丟掉全部前任努力的結果。

新代碼一定比舊代買好？NO，重寫可能會帶來更大的風險。

對技術領導者來說，重寫項目的代碼也是一個異常艱難的決定。因為從公司層面說，重現代碼甚至會威脅產品的市場競爭力。一旦決定重寫代碼，那麼與競品相比，你可能落後了2~3年——在軟體行業，這時間可夠長的。

你理想中的新代碼會帶來產品功能的提升▼

但事實上，即便重寫的新代碼可以實現舊代碼的所有功能和需求，但是為產品帶來的市場競爭力只有邊際提升。因為重寫用的新技術、新語言、新框架並沒有給產品帶來質的飛躍。

更不用說在重寫的漫長過程中可能會遇到一些意外情況，比如：

1、缺錢：資金鏈的斷裂▼

2、缺人：核心程序員離職

最終導致效果不佳：達不到原產品應有的所有功能和需求，白白浪費了時間和金錢，也丟掉了市場競爭力。▼

所以重寫代碼意味著，你在把自己置身於非常危險的境地，可能幾年後你也寫不出比以前更好的代碼。你只是花了一大筆錢把已經存在的代碼又寫了一遍。

當你覺得眼前的舊代碼很爛時，該怎麼辦？

你覺得舊代碼寫的很爛，那又怎樣呢？它們已經上線，已經在實際運行中經受住了考驗。所以當你發現前任留下的代碼亂七八糟的時候，不妨冷靜下來，從以下三個方面入手理解代碼、改善代碼：

1、代碼的結構有問題

如果一段網路代碼突然彈出了自己的對話框，應該是UI代碼需要被處理。這些問題可以被解決掉，你要一次次小心地移動代碼，重構，改變介面。還需要一位細心的工程師立馬仔細地檢查這些改變是否有問題，從而不打擾到其他人。事實上，甚至比較大的結構變化也可以不扔掉代碼來完成。

大牛程序員Joel Spolsky回憶說，曾經在某個項目中，他和他的團隊花了好幾個月重新架構在一點上：把代碼動來動去、清理、創建有意義的基類，並創建了模塊之間的完美介面。但是他們始終非常小心翼翼，並沒有產生新的bug、也沒有丟掉任何舊代碼。

2、代碼的效率不高

曾經，Netscape的渲染代碼被傳非常緩慢。但事實上，這只會影響該項目的一小部分，這部分是你可以優化甚至重寫的。你完全不必重寫全部代碼。優化速度的1％工作量，會讓你獲得99％的爆炸性提高。

3、代碼寫得很醜

有些代碼真的寫的很醜，比如Joel曾參與一個項目，開始用下劃線做開始的成員變數約定，但後來改用更標準的「M_」。所以一半的功能用「_」開始，一半用「M」開始，這看起來真的很醜陋。但這個問題5分鍾就能解決，而不用從頭開始寫全部的代碼。

最後，你要記住，從頭開始再寫一遍並不意味著你會寫出比以前更好的代碼。因為你沒有參與到上一個版本的創建，所以你其實根本就不算有經驗。一旦你准備推倒重寫，你可能會再犯一遍版本一犯過的錯，甚至會產生更多的新問題。

一個總結：

面對糟糕的舊代碼，Keep Calm & Carry On !

在大型商業項目中，推倒重來是非常危險的行為。當然，如果你是在做實驗，想到新演算法可以隨時重寫。