35 個毀掉你代碼的不良習慣！

時間 2019-11-20

標籤毀掉代碼不良習慣简体版

原文原文鏈接

引言

壞習慣很難改變，若是你不知道你的壞習慣正在影響工做，那就更難。若是你知道，但不在意——這是最糟糕的狀況。但好在你已經來這裏看了，不是嗎？程序員

做爲一個程序員，我看到不少很差的作法，不只僅與代碼相關，還包括團隊合做能力。我本身曾經就有很多這些壞習慣。這裏是我認爲最糟糕的 35 個壞習慣，它們涵蓋了四大類：組織代碼、團隊合做、編寫代碼以及測試和維護。！正則表達式

組織代碼

1.說「我稍後會改」推遲修復代碼這個習慣不只僅涉及到優先級的問題。跟蹤管理問題可能會是不錯的選擇，但你須要一種方法來跟蹤小問題。有一個快捷的方法，添加「TODO」註釋，它能保證你不錯過任何問題。算法

堅持一行代碼解決問題癡迷於編寫高效、優雅的代碼是程序員的共同特色。這就像解決一個謎題——你會發現組合函數和正則表達式能夠把20行代碼變成2至3行。不幸的是，這樣寫出來的代碼並不老是容易閱讀，而這一般是更應該重視的事情。先讓你的代碼可讀，而後再說技巧的事情。數據庫
無心義的優化咱們經常把工做重心放在另外一個錯誤的地方，就是優化。把網站減小几個字節的大小看起來是很不錯，但爲何不讓 gzip 來幹這個事情？需求不是更重要的事情嗎？把優化工做放在項目結束的時候，由於多數狀況下需求會變化，這會讓你以前花時間進行的優化工做浪費掉。編程

"過早優化是萬惡之源。" —Donald Knuth安全

告訴本身風格問題並非那麼重要若是說我從多年來觀察別人的代碼學到了什麼，那就是處理編碼風格的問題是開發者最可能推遲的事情。缺少經驗的程序員很難看到風格問題的好處，但隨着時間推移，這會愈來愈明顯，一旦有代碼質量出現問題，雪球效應就會讓項目變得一塌糊塗。應該嚴格要求按最佳實踐來工做，即便它們看起來微不足道。使用代碼檢查工具和靜態分析工具可讓你從風格問題中解脫出來關注更重要的事情。架構
把東西掃到地毯下(不被看見) 捕捉而後忽略異常，或者使用不報告錯誤的庫(好比 jQuery)，這些都是在把東西掃到地毯下的做法。若是那些錯誤中的某一個很是關鍵，那修復它將會是數倍的挑戰，由於你找不到線索，不知道從哪裏開始。避免這種事情最簡單的辦法是把這些被忽略的錯誤記錄到日誌中，這樣之後還能夠研究它們。編輯器
使用無心義的名稱命名是件難事，但它是確保變量名稱和函數名稱高質的簡單方法。若是名稱中含有其它代碼不能傳遞的信息，別的開發者閱讀你的代碼時就會以爲輕鬆。命名之因此如此重要，由於名稱可讓人對代碼所作的事情產生基本的概念。若是你須要深刻計算過程去發現代碼的工做，會須要不少時間，但好的名稱能夠幫助你很快理解代碼在幹什麼。函數
忽略被證明的最佳實踐代碼審查、測試驅動開發、質量保證、自動化部署——它們以及其它一些實踐都已經在無數項目證實了其價值所在，也正是如此，開發者們的博客在不斷的提到它們。《開發軟件：真正的工做是什麼，咱們爲何要相信它》這本書是關於最佳實踐很是不錯的參考。花點時間學習如何正確地作事情，你的開發過程就會在全部項目中獲得改善，其效果會讓你大吃一驚。工具

協做

太早放棄計劃不遵照計劃可讓你的項目變得不受控制。若是你的代碼受到批評你能夠說是由於計算不完整。不管如何，讓未完成的模塊結合起來一塊兒工做將會致使緊密耦合。這種複雜的狀況也會在項目領導角色發生變化時出現，若是新的領導會認爲他們的方式會比架構的一致性更重要的話。
堅持一個幾乎不會發生的計劃就像放棄計劃會致使問題同樣，堅持一個行不通的計劃也是如此。所以你應該在事件變得棘手的時候向團隊分享意見，並收集反饋和意見。有時候不一樣的視角會改變一切。
老是一我的在戰鬥你應該努力與團隊分享你的進步和想法。有時候你認爲本身在作正確的事情，其實並非，因此不斷的交流會很是有價值。這對和你一塊兒工做的人也會帶來好處。若是你與團隊一塊兒討論，並指導那些驗證不足常常被卡住的成員，他們的工做一般會有所改善。
拒絕寫很差的代碼每一個開發者都經歷過被最後期限逼迫着寫壞代碼的時候，其實沒什麼。你可能試圖警告客戶或者經理這會產生嚴重後果，但他們堅持原來的最後期限，因此如今只能繼續寫代碼。也許存在一個緊急的錯誤等不到你想出清晰的解決辦法。這也是爲何程序員多才多藝是很是重要的，由於他要既能寫並不優雅的代碼，也能寫好代碼。不過但願你能從新考慮這些代碼並償還技術債務。
責備別人在開發人員和其它技術人員之間，自負是一個很是廣泛的特徵，這已經不是什麼祕密了。對本身的錯誤負責是一種美德，它會讓你在同行中脫穎而出。不要懼怕認可你所犯的錯誤。只有你再也不懼怕認可錯誤，纔會輕鬆地專一於研究爲何會出錯，以及如何避免這種錯誤再次發生。若是你連錯誤都不能認可，何談學習？
不與團隊分享你學到的東西你做爲一個開發者的價值不只存在於你寫的代碼中，還存在於你在寫代碼的時候學到了什麼。分享你的經驗，寫下相關的評論，讓其餘人知道爲何事情是這樣的，並幫助他們瞭解項目中難以理解的新事務。
不及時向經理/客戶的反饋工匠精神最有價值的一點是儘量讓全部人在同一層面工做。這樣作並非由於管理者須要填寫電子表格。這也是爲了你本身：這會減輕你的不安全感，減小對項目生命週期和將來的不肯定性。
少用 Google 解決一個問題最快的辦法並非去解決它。若是有問題，上 Google。固然，固然你也能夠麻煩坐你旁邊的工程師，但他可能不多會給出像 Stack Overflow 上那樣詳細的解釋，更不用說你這樣作會打斷他的工做。
高估你的我的風格始終協調本身的工做風格和工做環境與團隊保持一致。理想狀況下，團隊中的每一個人都應該工做在相似的環境，聽從相同的代碼風格。用你本身的方式來作事情可能會更有意思，但同事可能會不習慣你的代碼風格。若是你的風格不一樣尋常，那別的開發者就很難接手你的工做。
爲代碼綁上我的的標籤若是某人評論你的代碼，不要認爲這是私事。你的代碼應該經得住考驗；也就是說，你應該能解決爲何這樣寫。若是代碼須要改進，那是由於代碼須要改進，而不是由於你。

編寫代碼

不知道如何優化良好而正確的優化策略須要經驗的積累。這產生了探索、分析和了解每一個系統的過程當中。讓本身知道這些事情，學習算法的複雜度、數據庫查詢評估、協議以及通常狀況下如何衡量性能。
使用錯誤的工具來工做你所知有限，但讓你保持學習的緣由是新問題會引出不一樣的上下文，須要不一樣的工具——適用於當前任務的工做。以開放的心態面對新的庫和語言。不要老是根據自已經知道的事情來作決定。
不想分散精力去掌握工具和 IDE 在使用工具的過程當中不斷學習新的熱鍵、快捷方式或參數，能夠提升你編碼的速度和認知。這與使用熱鍵來節約幾秒種時間無關，它會下降你上下文切換的頻率。你花在每一個小動做上的時間越多，花在考慮問題(爲何這麼作，接下來該幹什麼)上的時間就越少。掌握捷徑會讓你恍然大悟。
忽略錯誤消息在沒有閱讀錯誤消息以前，不要假設你知道代碼有什麼問題，也不要假設你會很快發現問題所在。掌握更多關於問題的信息總不是壞事，長遠來看，花時間收集這些信息會更節約時間。
誇大你的開發工具包有時候你首選的編輯器或命令行工具並不是解決手頭工做最好的工具。Visual Studio 是個很是不錯的 IDE，Sublime 則很是適用於動態語言，Eclipse 與 Java 更配，等等。你可能比較喜歡 Vim 或者 Emacs，但並不表示它們適用於每項工做。
在代碼中直接使用值而不使用配置思考變化以及如何處理變化是件長期的事情。若是你不把隨時變更的碎片從工做中剝離出來，技術債務就會以驚人的速度增加。應該在適當的地方使用常量和配置文件。
老是從新發明輪子不要寫你不須要的代碼。也許別人已經花了大量的時間在你遇到的問題上，他或者她可能已經有一個經過測試的解決方案，你能夠重用這些方案，少給本身找麻煩。
盲目複製/代碼你在重用一段代碼前應該搞懂它。有時候你不能在第一次看代碼立刻就注意到它乾的全部事情。你應該花點時間仔細閱讀代碼同時深刻研究要解決的問題。
不花時間去研究事務是如何工做的經過思考事務如何工做，以及它們潛在的問題，抓住機會擴大本身的知識面。你如今可能節約了時間，免受干擾，但長遠來看，從項目中學到的東西會比如今作的更重要。
對本身的代碼過於自信只由於是你本身寫的東西，就是一級棒，這種假設很是危險。學習更多關於編程的知識，就像新的工做任務那樣，從中獲取經驗。因此，看看你之前寫的代碼，反思，並得到進步。
不權衡每一個設計，解決方案，或庫每一個產品都存在優勢，你只能經過使用和分析來進行了解。看一個庫和幾個用法示例不會讓你掌握它，也不是說任何狀況下它均可以完善適用於你的項目。辯證的看待你所使用的每一個事物。
卡住時不尋求幫助保持簡短的反饋循環並如你所想的那麼痛苦。尋找幫助並不表明你無能。人們會看到你的獨立，認可無知能夠驅動學習，這是美德。

測試和維護

寫能夠經過的測試寫你明知能夠經過的測試是有必要的。它們會在項目重構或從新組織的時候保證其質量。但另外一方面，你也必須寫明知不能經過的測試。它們能夠推動項目並跟蹤問題。
不顧關鍵用例的性能測試在項目開發的中間節點建設一個自動化的性能設置，這樣在項目逐步擴大的時候才能確保沒有性能問題。
不檢查構建工做構建經過但構建結果卻不能工做這種狀況不多發生，但它確實會發生。並且，你拖延着不去調查這個問題的話，時間越長，就越難以修復。構建以後進行快速測試是個很重要的習慣。
最後推送大量改動或推送大量改動以後就離開可能這是由於你過分自信，直到屢次引火上身以後才學會不這樣作。請如今就接受個人建議，當構建失敗的時候你就在旁邊。
與本身的代碼斷開聯繫對本身寫的代碼提供支持。你是最瞭解這個代碼並且最可能爲別人提供相關幫助的人。你應該努力使本身的代碼在多年後仍然能被本身或者別人看懂。
忽略非功能性需求發佈的時候一般很容易忘記一些重要的領域，好比性能和安全性。應該有這一個清單記錄着這些事情。你確定不但願由於在制定最後期限的時候忘了這些非功能性需求而破壞你的聚會。