AI 前線導讀：?一個擁有 20 年編程經驗的“熟手”，編程干貨有多少？本文作者是一名從業 20 年的程序員，他分享了自己這 20 年來學到的 5 種編程經驗：重復的知識最糟糕、把代碼當成一種債務、信任高級開發人員信任但要驗證、使用 TDD、用“證據”證明自己的代碼更好。下文是關于這 5 種經驗的具體描述。

更多優質內容請關注微信公眾號“AI 前線”（ID：ai-front）

今年，我對DEV開發平臺越來越熟悉。眾多激憤的 Reddit 評論者和“不過如此”的鑒賞家們構成了一片荒漠，在這片荒漠之中，DEV 已經成為令人耳目一新且充滿積極力量的綠洲。

這個社區有著很有趣的一面，它似乎非常注重初學者。我經常在這里看到行業新手寫的帖子。我所說的新手是指那些在訓練營中尋找入門級工作，或者那些在不幸的“初級”程序員崗位上工作且有抱負的程序員。

我感覺這很有趣，新手通常會對這個行業充滿熱情，這種激情富有感染力。他們的激情也讓我認識到自己在這個行業的定位——熟手（老人兒）。

在過去四、五十年里，行業對程序員的需求急劇增長，以至于程序員的數量總是每五年翻一番。因此，擁有 5 年經驗的程序員占據著整個行業一半以上的職位。我在這個行業已經快 20 年了。其中 10 年，我的主要職責是編寫代碼。另外10 年是管理者，指導新人、向組織咨詢如何管理并施行代碼庫評估實踐以及當前從事的內容營銷。

于是，我問自己，“如果我能把自己的經歷進行簡明扼要地總結（假設真的有人關心的話），我會向新手們提些什么建議呢？”

所以，就產生了這篇文章。以下是我認為自己在 20 年編程生涯中最重要的經驗和收獲。

1. 重復的知識最糟糕

“避免復制粘貼式編程！”

當你在應用程序中復制、粘貼代碼，然后調來調去的時候 (“復制、粘貼、調整”反模式)，如果沒有人打你的手，那么現在就考慮舉起“戒尺“吧。因為這種做法很糟糕，也很隨意。

假設，你有一個用得好好的 CalculateBill() 方法，但是產品經理卻走過來說：“我們正在墨西哥接待新客戶，與你那個計費的方式有點不同。”因此，你復制了當前的這個方法，也粘貼了它，將其重命名為 CalculateBillMexico()，并根據需要對其進行調整。

所以在這種方式的操作下，產生了這些問題：

如果將來的變更需要對核心邏輯進行調整，現在必須額外修改這兩個方法。

在做此類變更時，可能引入了兩個 bug 。

你現在已經建立了一個“設計模式”，隨著在全球的繼續擴展，你的代碼更新需要一個又一個新的、冗余的方法。

你的工作量將會急劇增加。

忘記修改需要修改的地方，從而引入 bug，這種情況的出現只是時間問題。

最終，所有這些方法都會有一定的差異，這些差異足以令你無法合理地將它們合并起來修復這種混亂，但是差異又沒有大到可以避免有人在更新一條計費規則時改上 20 次。

這是一個爛攤子。然而，復制粘貼只是表層問題。

復制粘貼只是開始

真正的問題是系統中的知識重復。

在你的系統中，知識的復制可以以多種方式出現，蹩腳的復制 - 粘貼是最明顯和最笨拙的。看看其他知識重復的例子：

• 一個 for 循環，在它的正上方有一個解釋開始、結束和遞增的代碼注釋。

• 為一個全局變量內聯賦值，然后 (可能) 從配置文件中取一個值重新賦給它。

• 包含“PretaxTotal”、“Tax”和“Total”列的數據庫表

• 一個范圍很廣的 ERP 系統，它將客戶存儲在 CRM 模塊中，然后再存儲在計費模塊中。

有了以上這些，最好的情況是有適當流程和系統來努力跟蹤副本，并確保及時更新。如果缺乏代碼注釋，可能團隊的首席嘮叨官更新代碼時就會一直在你耳邊念叨：檢查注釋、檢查注釋······

或者，以ERP系統為例，這可能是一個嚴格的部門備忘錄，告訴銷售和會計，他們都需要發送正式的電子郵件，以確保客戶信息保持同步。

記住，以上這些已經是最好的情況。當開始構建復雜的邏輯以確保同步時，會出現更糟糕的情況。

也許你可以實現一個數據庫觸發器，在“total”列發生更改時確保 PretaxTotal + Tax 仍然等于 total。或者，你可以編寫一些笨拙的狀態檢查邏輯，當默認的全局變量值與配置文件中的值不匹配時，記錄一個警告。

最糟糕的情況是數據不同步。那么，作為一名程序員，可能不用擔心它，因為你拿的那份工資所要承擔的工作不包括搞清楚為什么你們從來沒有給客戶開過發票，或者為什么多年來一直多收客戶的錢。

但是，面對藏身于系統各處的問題，根除和積極抵制可以幫你避免所有這些問題。

2. 代碼是一種債務

作為開發人員，我們要學會熱愛代碼。編寫代碼感覺很好，創造些什么出來也很令人興奮。

此外，我們尋找新的語言、范例、框架、堆棧、工具、api 和庫來學習。我們沉浸在自己的世界里，因為在這種狀態下，我們可以愉快地生產代碼。

?

一些極端的開發者甚至把每小時生成的代碼行數作為生產力的度量標準。即使沒有達到這個程度，也很容易認為代碼越多越好。代碼是殺手級應用程序和業務的 DNA，公司認為它是有價值的知識產權。

但是，代碼完全就是一種債務。

少即是多

你知道有什么比“用 10 行代碼來編寫別人用 100 行代碼才能完成的事情”更好的嗎？那就是用 0 行代碼。

寫這么一行代碼:

printf("Hello World!");

你認為有多少事情會出錯？

• 這段代碼會在允許控制臺打印的環境中運行嗎？

• 那段神奇的字符串以后不會成為問題嗎？

• 你不應該記錄日志嗎？這是一條最佳實踐。

• 你有沒有想過這對安全的影響？

保守地說，這行代碼中有 10 個地方可能出錯。現在，我們加上第二行。

那么，你會覺得這將導致總共 20 件可能出錯的事情嗎？

我認為幾乎得有 100 件。你可以叫我悲觀主義者，但我認為潛在問題與代碼行之間的關系更接近組合而非線性的關系。

?

實際上，我做過幾年管理顧問，看過、分析并收集了大量代碼庫的統計數據如果算上在客戶那兒自動分析的代碼庫，我已經收集了 1000 多個代碼庫的詳細統計信息。然后，為了尋找相關性我對這些數據進行了回歸分析。

所以，你知道與不良代碼庫的相關性更強的是什么嗎？那就是代碼庫的大小。

?

幾乎關于代碼庫的所有壞事都與代碼庫的大小有很大的關系（以代碼的邏輯行來衡量）。

我愛代碼，我喜歡寫它、研究它、分析它，以及用它做東西。但毫無疑問的是，代碼是一個巨大的債務，我們應該去努力用盡可能少的代碼來做每件事。

3. 高級開發人員：信任但驗證

在我 23 歲時做了第一份軟件工程工作，當時我對高級開發人員懷有一種崇敬，我從他們身上學到了很多。如果你是這個行業的新手，你可能會像我一樣，認為團隊中資深開發人員的每一句話都是智慧的結晶。而且，如果你幸運的話，他們中的很多人的確是這樣，特別是在一開始的時候。

但，并不是所有的高級開發人員都如此。

回想起來，有些人不是技術專長，而是在那兒很長一段時間無所事事，設法不被解雇，并靠混資歷晉升為“資深”或“高級”之類的頭銜。

這種現象非常普遍，幾年前我編造了一個詞來描述它，現在每個月都有數百條谷歌搜索。當我時創造了“專家級初學者”這個術語，它引起了人們的強烈共鳴。

所以，當你是新人的時候，要相信前輩的說法，尊重他們，但不要想當然地認為他們說的就是對的。自己得驗證一下，當然了，最好不要當著他們的面驗證。

4. TDD 真的行，它改變了游戲規則

當涉及到任何編程，甚至只要是與技術相關的事情時，我們往往會帶有偏見的主觀選擇。

• IDE 與輕量級編輯器的討論？

• 蘋果、Windows 還是 Linux？

• 你怎么看 PHP？

• 制表符（tab）還是空格（space）？

拿出其中任何一個，就能看到那些持明確觀點的人的爭吵。因此，考慮到所有這些，我意識到自己正在陷入類似的境地，那就是“做 TDD 還是不做 ”。

我的目的不是說教，而是分享我自己的經驗。

大約 10 年前，我是 TDD 懷疑論者。我并不是單元測試的懷疑論者，事實上，我從一開始就接受了它，并將其作為一種有用的實踐，但對TDD不太確定。

甚至，那時候的我決定寫一篇博客，來解釋為什么 TDD 沒那么好。

但我不想就這件事寫一篇站不住腳又蹩腳透頂的評論文章。所以我決定做一個嚴格遵循 TDD 的小型客戶項目 (順便一提，固定價格)，這樣我就可以寫一篇文章，但這篇文章的前提是“我真的去花費幾周的時間做純粹的 TDD，并發現它不好的事實”。

實際上，整個過程可能是好幾天。我做每件事都需要花很長時間，做每件事都很麻煩，也很不自然。我一樁一樁地把它們記錄下來，以證明為什么TDD是一種糟糕的做事方式。

然而，我對這個范例很著迷，以至于在某一天花了4到5個小時編寫代碼，卻沒有實際運行應用程序來檢查更改是否有效。（通常，我會每隔 10 分鐘左右運行一次應用程序，以檢查更改是否真正有效。）

意識到自己已經工作了幾個小時，我啟動了應用程序，感覺必須要再調試幾個小時。畢竟，以前至少需要調試 30 多回。但是，一切都能正常運轉，第一次沒有任何異常。我花了幾個小時編寫代碼，沒有查看自己的 GUI，也沒有在運行時驗證任何東西，但所有的一切都運轉正常。

于是，我學習了這種技術，掌握了它，還講授了相關課程，做了相關咨詢。除此之外，我調查了單元測試對代碼庫的影響，發現這些影響無疑都是好的。

5. 證據為王

到目前為止，在這篇文章中，我已經提到了自己的代碼庫評估實踐，并討論了經驗數據。所以，讓我們正式聊聊，在我目前職業生涯中收獲的最后一點經驗：證據就是一切！

代碼評審可以作為一種教育性的賦能活動，或者稱他們可以處決你的靈魂。然而，代碼評審很可能會在啟發性的體驗和無意義的爭吵之間來回搖擺。

你會聽到諸如“那不是一個好的設計”或“那沒有效率”之類的話，你可能也會說這些話。而且，你很可能在沒有任何證據的情況下聽到或說出這些話。

那么，怎樣去解決這個問題呢？

證據的重要性

如果在代碼評審過程中，或者在團隊、組織內協作時，有人對你橫加指責，那么證據就是最好的說明。如果試圖向管理層或領導層解釋任何事情，證據也是最好的說明。我的意思是，在代碼庫中找到有全局聲明和沒有全局聲明的模塊，然后將 JIRA 問題單的事故率或者其他數據作為參考依據。

?

你的團隊中是否有人要求你使用與你選擇不同的庫或 API，因為它們具有“無憑無據”的良好性能？那么，你接受他所說的嗎？

如果不接受，那就去證明他說的是錯的。比如，進行實際的時間測試。

讓你自己習慣于做實驗，而不是大聲地表達和重復觀點。用實證驗證想法，這種做法具有直接價值。

當面對質疑時，有時你會發現自己是對的，而有時會意識到自己是錯的。哪怕通過證明是錯的，也很有價值。

除此之外，你會開始用一種其他人無法匹敵的方式進行辯論，從而樹立起自己的品牌，那就是勤奮和正確。這可以幫助你克服一些看似不可逾越的障礙，比如“我只是個初學者，而他是個專家”。其實，他不過是一個專家級初學者而已。

如果將眼光再放長遠一點來看，這種操作，會讓你在事業上有更好的發展。能夠編寫代碼確保你會有一個回報豐厚的職業生涯，能夠編寫代碼并使用證據來為行動過程提供技術和業務用例，將確保你的事業蒸蒸日上。

以健康的方式使用 (或不使用) 這些

寫這篇文章的時候，我覺得自己富有哲理。事實上，如果你足夠努力地做過嘗試，我想你可以反駁這些觀點。

我并沒有把這些作為一成不變的編程法則或某種專業的行為準則，我只是把它們作為職業生涯中自己學到的經驗教訓提供給大家，它們只是我的個人觀點，請大家謹慎選擇。

希望這些觀點能對你們有所幫助，使你們能夠根據自己的需要以健康的方式采用或者不采用它們。

?作者介紹

Erik Dietrich，DaedTech LLC 的創始人、程序員、架構師、IT 管理顧問、作者和技術人員。

原文鏈接：

https://daedtech.com/5-things-ive-learned-in-20-years-of-programming

總結

以上是生活随笔為你收集整理的从业20年的程序员，“盘”出来的5种编程经验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。