本文轉載自公眾號“讀芯術”(ID：AI_Discovery)

 想讓事情盡善盡美是很正常的心態。然而，當進行任務轉換時，我們有時會忘記一些重要的事情——代碼質量，以及作為一名程序員的成長。在我們犯下的眾多“罪孽”之中，因匆忙而造成的錯誤實在無可厚非。

[[344795]]

話雖如此，我們也必須尋找機會，深呼吸，放慢腳步。當覺得時間不夠時，要小心不要出現以下這些重大錯誤。

未讀取足夠代碼

你有沒有在電影里看到過這種畫面：一個程序員盯著屏幕看了好幾分鐘，卻一籌莫展。沒有電影這樣拍——電影常塑造這樣的情節：程序員飛速鍵入一些內容，然后問題迎刃而解。遺憾的是，真正的日常工作并非那么光鮮亮麗。

我們需要閱讀數不勝數的代碼。此外，我們還應該了解它的作用和原理。

來自互聯網的隨機代碼

代碼讀取不夠會導致很多情況。你上一次在網上查找答案，比如在堆棧溢出(Stack Overflow)上找到一個代碼片段，然后復制粘貼它，是什么時候?我可能就是這周。

從SO獲取的代碼有很大可能有效，但你是否了解它的作用、原理以及局限性?它足夠安全嗎?它如何應對邊緣情況和你的需求?

有時，你不得不粘貼代碼，并祈禱它能正常運行。時間有限，有些事情過于復雜，難以捉摸。但通常，你可以在15-30分鐘內搞懂代碼。對于放入項目中的代碼，你應該確信自己足夠了解，否則可能會危及項目的安全性和可維護性。

項目中的代碼

讀取自己項目中的代碼感覺如何?你被叫去修復的問題正好是不熟悉的一部分，不幸中的萬幸，你預感到并試圖立即修復它。修復起效了，你推進了這種變更，一切回到正軌。

這種錯誤后患無窮。如果你不熟悉基礎代碼而且沒有進行測試，那么進行修復時不造成任何破壞并能解決所有問題就成了天方夜譚。在試圖解決問題之前，你總需要弄清原委。只是隨意調試是沒有用的。可能會走運一兩次，但遲早會造成大麻煩。

庫中的代碼

啟動項目時默認要添加多少個庫?你確定它們是必需的并了解它們是如何實現的嗎?我并不是在為不使用代碼庫和框架做辯護。只要有可能，就應該使用經過驗證和良好測試的代碼。“重復發明車輪”很常見，但不過是多此一舉，且弊大于利。

了解你正在使用的工具有益無害。常用庫通常是優秀的軟件，研究它們的基礎代碼，你會受益良多。這會幫助你成為一個更熟練的開發人員，或者至少讓你意識到你并不需要某個特定的庫。不必分析使用過的每一個庫，但當你不斷重復使用某個庫時，你就有必要了解它是如何運作的。

讀取優質代碼能讓你成為更好的開發人員，并幫助你理解自己的產品。你或許認為自己沒有時間讀取代碼，事實并非如此。熟悉產品代碼有助于加快編碼速度，多讀取其他代碼有利于作為一名開發人員的成長。因此，從長遠來看，讀取代碼可以節省時間，而非浪費時間。

代碼未重構

你需要實現一個功能，但情況緊急，幸好你知道如何快速構建此功能。于是你投入其中，輸入一些含糊的代碼，一切似乎都很順利，問題也迎刃而解。是時候往前推進了。

大錯特錯!當你開始編碼卻不考慮其他選擇，只堅持要用第一版解決方案時，你的代碼是有缺陷的。它可能效率低下、不可讀或不可維護。最糟糕的時候，三種情況會同時出現，導致問題無法解決。

速戰速決很誘人，但一名出色開發員的標志是創建高質量的代碼并改進其所涉及的基礎代碼。若一個新項目中，所有人都只想盡快推出新功能，那么該項目注定會產生巨大的技術債務。隨著時間推移，項目會變得越來越難以維護，開發人員的工作效率也將停滯不前。

改進代碼是團隊中每個開發人員的責任。所以，實現新功能一定要舍得花時間。考慮到工作的副作用，以及對通用應用架構的適應，你應該始終讓基礎代碼保持比初始更好的狀態。久而久之，它不僅能加快開發速度，還能讓你成為一名更熟練的程序員。

代碼未測試

有多少次，你并未準備確保功能正常運作的測試就創建了功能?這種做法很常見——尤其是在需要快速進行的項目中。人人都覺得測試浪費了寶貴時間，所以他們不得不重啟進度，這永無止境。

事實上，對于任何生命周期較長或有待發展的項目，不論你的代碼有多么優秀，測試都至關重要。更糟糕的是，有人會對不同的代碼部分進行更改，這就會破壞你的功能。沒有測試，你就無法得知這些。正確的測試提供了安全性，它們讓你可以放心地在代碼中進行更改。

你可能覺得測試浪費時間浪費金錢，但事實恰恰相反，未來的自己和其他開發人員都將感謝你編寫了有用的測試。

欲速則不達，有些事看起來浪費時間，但不做后患無窮，認真做了反而能有收獲。