Erik Dietrich：二十年的编程，教会我的五件事！
CSDN翻譯
讀完需要
11
分鐘速讀僅需 4 分鐘
無論你是剛入編程的小白，還是已經浸潤編程數年的資深人員。相信這篇文章都會給你帶來不一樣的啟發，前人的經驗永遠是我們最容易看到的捷徑。
作者 | Erik Dietrich
譯者 |彎月，責編 | maozz
出品 | CSDN（ID：CSDNnews）
以下為譯文：
今年，我對 DEV 社區平臺 https://dev.to/有了很大的了解。在 Reddit 眾多怒氣沖沖的評論家以及急于否定他人的鑒賞家中，這個平臺積極的正能量宛如一片綠洲，讓人眼前一亮，并為我們帶來了更廣闊的軟件世界。這個社區非常有趣的一面是，社區中似乎有很多初學者。我經常看到新手撰寫的帖子以及面向新手的帖子。所謂“新手”，指的是那些渴望成為程序員的人，他們或者在參加培訓班，或者在尋找入門級的工作，或者只是不幸被定義為“初級”的角色。我覺得這很有趣。相對而言，新手對該行業充滿更多熱情和興奮。而這種興奮是富有感染力。然而，同時也讓我感受到我在這個行業中屬于前輩了。
我想起了 Bob Martin 曾在播客或演講中說過的一段話。在過去的 4-5 年中，程序員的需求急劇增長，以至于程序員的數量每隔 5 年就會翻一番。結果是，擁有 5 年經驗的程序員在這個行業的任職時間甚至超過了該行業的一半。
1
? ?
行業的前輩
如今，我已在這個行業中度過了 20 個春秋。其中的 10 年時間里，我的主要工作都是編寫代碼。而另外 10 年都在管理程序員、指導他們，就如何管理程序員向組織提供咨詢，運行代碼庫評估實踐，而如今的我在從事內容營銷。但是，無論身處以上哪個職位，我都在或多或少地編寫代碼。根據上述有關程序員增長速度的估算，我比這個行業中 94%的人都年長。所以，總結起來說，我是一個與編程新手廝混在一起的編程愛好者。于是，我不禁在想：“如果我可以將這段經歷總結成一些簡短的建議，再假設有人感興趣，那么我會對他們說什么呢？”
以上就是這篇文章的背景。下面讓我來談一談 20 年編程生涯為我帶來的重大教訓和收獲。
2
? ?
最糟糕的莫過于知識重復
“避免復制粘貼的編程！”如果你在編寫應用程序時，總是靠復制、粘貼和修改代碼，如果還沒有人因此而拿戒尺打你的手心，那么現在你自己動手吧。你應該停止這種做法。立刻，馬上！這是一種可怕又偷懶的做法。
想象一下，你有一個完美的 CalculateBill()方法，但是產品經理猶豫著說：“我們有一部分客戶來自墨西哥，那邊的賬單計算方式不一樣。”于是，你復制了這個方法，重新命名為 CalculateBillMexico()，并根據需要做出調整。這種方法的問題在于：
如果將來核心的邏輯需要調整，那么你就必須付出額外的勞動，因為你需要修改兩個方法。
一旦發生變更，你的代碼出 bug 的機會也會加倍。
如今你已經建立了一個“設計模式”，隨著全球擴張的繼續，你的代碼還會因為第三個國家而衍生出第三個冗余的方法。
隨著工作的進展，你的工作量將急劇增加。
在修改代碼時，你遲早會因為忘記修改所有的方法而產出新 bug。
最終，所有這些方法之間都會產生很大的差異，以至于你無法合理地將這些方法合并回去，并從根本上解決問題；即便沒有如此大的差異，每當更新賬單的計算方式時，你就需要進行 20 次的更改。是不是一塌糊涂？而這只是“復制-粘貼”的表面問題。
3
? ?
復制粘貼只是一個開端
真正的問題在于系統中的知識重復。系統中的知識重復可以以多種方式發生，而無腦地復制粘貼只是最明顯和最愚蠢的方式。知識重復的其他形式還包括：for 循環上方的代碼注釋解釋循環的開始、結束和增量。全局變量在程序里賦了一個值，然后從配置文件中重新賦了另一個值。數據庫表中同時包含“稅前總額”、“稅款”以及“總金額”三列。范圍很廣的 ERP 系統，CRM 模塊中存儲了客戶信息，然后在賬單模塊中又存儲了一次。對于以上所有這些情況來說，最好的打算也不過是通過恰當的流程和系統來認真地跟蹤重復并確保同步更新。至于一無是處的代碼注釋，團隊的領導會警告你每次更新代碼時，都別忘了檢查注釋。還有上述的 ERP 系統，銷售和會計兩個部門都需要嚴格地制定備忘錄，并通過發送正式電子郵件確保客戶信息保持同步。
而且，請記住，這些還只是最好的打算。當你為了確保同步開始構建復雜的邏輯（那么你就必須進行維護——請參照下一節）時，情況就會每況愈下。也許你只需要實現一個數據庫觸發器，就可以在“總金額”列發生變化時確保“稅前金額”+“稅款”=“總金額”。或者，你也可以編寫尷尬的狀態檢查邏輯，當默認的全局變量值與配置文件分配的值不匹配時，記錄警告。糟糕時候，上述情況會造成數據不同步。然而，作為程序員，你可能不必擔心，因為你的工作也包括弄清楚為什么多年來從未給某個客戶開過發票或多收了客戶很多錢。然而，根除系統中出現的知識重復問題并積極抵制，就可以避免所有這些情況。
4
? ?
代碼是負債
作為開發人員，我們喜歡寫代碼。寫代碼的感覺非常好，而且構建軟件令人興奮。此外，我們還需要學習新的語言、范例、框架、技術棧、工具、API 和庫。我們沉浸在自己的內心世界，享受快樂地編寫代碼的狀態。
然而，沉浸在代碼世界而不自知的不止我們。被誤導的禿頭老板甚至用每小時生成的代碼行數作為生產力的度量指標。但是即便你沒有那么愚蠢，也很容易認為代碼自然是越多越好。事實上，代碼是應用程序和業務的殺手，而各個公司卻把它當成有價值的知識產權。還是忘記這些無稽之談吧。我能理解為什么我們將代碼視為資產。但是實際上代碼完全是負債。
5
? ?
少即是多
你知道有人可以用 10 行代碼實現別人要 100 行代碼才能實現的功能嗎？那么你知道比 10 行代碼更好的是什么嗎？那就是 0 行代碼。
比如，我們寫了一行代碼：
printf(“Hello?World!”);你知道這中間可能會出多少錯嗎？
這行代碼是否只能在允許控制臺輸出的環境中運行？
這個神奇的字符串將來不會成問題嗎？
你不應該記錄日志嗎？畢竟日志才是最佳實踐。
你考慮過這行代碼中的安全隱患嗎？保守地說，這行代碼可能會出 10 個錯誤。
那么現在，讓我們增加到 2 行代碼。你是否覺得 2 行代碼可能會出 20 個錯誤？我認為 2 行出的錯誤可能會超過 100 個。
你可能覺得我過于悲觀，但是我認為潛在的問題與代碼行數之間的關系更接近排列組合的個數，而非線性關系。
我有多年專業管理顧問的經驗。我做過數據驅動代碼庫的評估，并幫助 IT 領導者制定有關代碼庫的戰略決策。因此，我有機會查看、分析和收集大量代碼庫的統計信息。如果算上我利用自動化分析過的客戶端代碼庫之上的代碼庫的話，那么我總共收集了 1000 多個代碼庫的詳細統計信息。在獲取這些數據后，我進行了回歸分析，以尋找相關性。你知道對代碼庫造成負面影響最大的因素是什么嗎？代碼庫的大小。
幾乎所有與代碼庫有關的問題都與代碼庫的大小（以邏輯代碼行來衡量）有著顯著的關系。我喜歡代碼。我喜歡編寫代碼、研究代碼、分析代碼，并通過代碼來構建事物。但是請不要誤解，代碼是一個巨大的負債。我們始終應該努力用盡可能少的代碼來完成所有工作。
6
? ?
高級開發人員：信任，但要自行驗證
23 歲時，我開始了第一份軟件工程師的工作，我非常敬佩公司里的高級開發人員。Paul、Raymond、Chris、Ken，他們都有 20 年的經驗，我至今仍然記得每一個人，而他們熟練使用多種編程語言的能力也讓我看傻了眼。我從他們那里學到了很多東西。
我之所以提到這些，是因為我想過渡到接下來要說的話。如果你是這個行業的新手，那么可能就會像我一樣，認為團隊里高級開發人員的每句話都是金玉良言。而且如果你幸運的話，很多高級開發人員確實是不可多得的人才。然而，并非所有高級開發人員的水平都相同。回想起來，我上面提到的同事都是優秀的程序員，我從他們那里學到了很多東西。但是，我也明白在我的職業生涯中，最初的經歷都很幸運。很多公司擁有很多出色的高級開發人員，但也有很多公司擁有的高級開發人員較少，或者他們的高級開發人員在技術上并不過關，但是這些高級開發人員仍然任職很久，遲遲沒有被解雇，甚至可能得到晉升，頂著“高級”或“首席”的頭銜。這種現象非常普遍，甚至有人稱之為“專家級初學者”。
我說這些是為了警告你，有很多高級開發只是表面上裝出來的，實際上并不稱職。因此，在你是新手時，沒有確鑿的證據就不應該質疑他們，但不要輕易假設他們告訴你的是對還是錯。你需要自行驗證（最好不要當著他們的面）。
7
? ?
TDD（測試驅動開發）不僅有效，而且還可以積極地改變編程的方式
在涉及任何與編程或技術相關的問題時，身處該行業的我們都會帶有偏見。IDE 與輕量級編輯器之爭？
蘋果、Windows 還是 Linux？
你如何看待 PHP？
制表符還是空格？
只要提到以上任何一個建議，就會看到持有強烈見解的人們吵得沸反盈天。因此，考慮到所有這些因素，我意識到我自己也陷入了類似的境界：“順 TDD 者是生存還是毀滅”。我的目的不是給你洗腦，而是分享我的經驗。
大約在 10 年前，我對 TDD 持懷疑態度。請注意，我不是一個單元測試懷疑論者，剛開始的時候我就同意這是一種很有幫助的做法。但是對于 TDD？我不太確定。我決定寫一篇博客，介紹為什么 TDD 并不是那么出色。但是，我不想就此事寫一篇文章表達站不住腳的廉價觀點。因此，我決定嚴格按照 TDD 建立一個小型客戶項目，然后我就可以在文章中寫：“我花了幾周的時間來驗證 TDD，結果卻并不美麗。”然而，命運總是充滿了意外驚喜。
8
? ?
對 TDD 的幡然醒悟
那天真是尷尬又怪異。確切來說是好幾天。整個過程非常漫長，我所做的一切都非常笨拙且不自然。我記錄了一條又一條筆記，作為證明 TDD 很糟糕的證據。然而，后來發生了一件有趣的事情。我對這種笨拙的范例非常著迷，每天我都花 4-5 個小時編寫代碼，但中間并沒有停下來實際運行應用程序，檢查我的更改是否有效。換做往常，每隔 10 分鐘我就會運行一次應用程序，檢查程序是否正確，看看我的更改是否確實有效。在發現自己已經寫了幾個小時的代碼后，我啟動了應用程序，嘆了口氣，以為接下來就是長達幾個小時的調試。畢竟，我推遲了將近 30 個周期。然而，神奇的事情發生了，一切都能正常工作。
第一次運行，一切都很完美，竟然沒有出現一個異常，也沒有發生任何意料之外的事情。我花了幾個小時編寫代碼，中途并沒有檢查 GUI，也沒有在運行時驗證，但一切都能正常工作。最終，我寫了一篇與預想截然相反的關于 TDD 的文章。從此我就踏上了這條不歸之路。我學習了這項技術，掌握了這項技術，教授了有關該技術的課程，并對開發人員進行了指導。但此外之外，我還檢查了單元測試對代碼庫的影響，發現這些影響無疑都是正面的。所以，你也可以嘗試學習 TDD，你絕不會后悔。
9
? ?
證據才是王道
到目前為止，在這篇文章中，我提到了有關代碼庫的評估實踐，還討論了經驗數據。最后讓我再介紹一下職業生涯的最后一課。證據就是一切。代碼審查可以作為一種有教育意義的授權活動。同時，代碼審查也可以抹殺一個人的靈魂。不過，通常代碼審查都在啟發性體驗和毫無意義的爭吵之間來回搖擺。你可能會聽到“設計不佳”或“效率不高”之類的反饋。你也可能會說這些話。而且，你極有可能會在沒有任何證據的情況下聽到或說出這樣的話。你需要改正這一點。
10
? ?
證據的重要性
如果有人在代碼審查或其他形式的團隊或組織協作中，以惡劣的態度對待你，那么你就應該拿起證據的武器。如果你想就某件事情向管理層或領導層提出任何想法，那么也應該拿出證據。證據可以幫你贏得辯論、組織、領導角色和職業發展。你不同意團隊廣泛使用全局變量的做法？不要做無謂之爭，你需要證明。我所說的“證據”并不是指尋找類似于“全局變量的弊端”等文章，或拿權威人士嚇唬人。我的意思是查找代碼庫中沒有全局狀態的模塊，并對照這些模塊與 JIRA 問題票的發生率。
你們團隊中是否有人要求你不要使用你選擇的庫或 API，只是因為某種模棱兩可的性能問題？你會服氣嗎？
那就證明這個人錯了。實際動手試試看。你需要習慣于動手實驗，而不是大聲表達自己的觀點或加倍考慮。這可以直接驗證你自己的想法。有時，你會意識到自己的懷疑是對的。而有時，你會意識到自己錯了，這都很有價值。但更重要的是，你可以提出別人無法反駁的論點，并樹立勤奮和正確的好名聲。這種做法還可以幫助你克服看似無法克服的困難，例如“我只是個新人，而他是高級工程師（專家級初學者）”。更進一步，這還可以為你的職業發展奠定基礎。編寫代碼的能力可以讓你收獲一份收入豐厚的職業。能夠編寫代碼并通過證據提供技術和業務上的決策可以確保你的職業生涯迅速取得成功。
11
? ?
你是否愿意聽取以上意見？
我感覺這篇文章富有哲理。實際上，我是在芝加哥飛往休斯敦的飛機上寫下了這篇文章，當時的我端著一杯酒，又無法使用 wifi。在百無聊賴中，我只能與空姐交談，然后就回憶起了我的職業生涯。我認為如果你足夠努力，就可以就這些觀點進行辯論。但是，我不打算將這些作為一成不變的編程法則或某種專業行為的準則。我會把這些我在職業生涯中所學到的教訓作為課程，并附上警告事項，因為這些只是我個人的觀點。最后，希望這些意見對你有所幫助。你可以自行決定是否聽取這些意見。
原文：https://daedtech.com/5-things-ive-learned-in-20-years-of-programming/
本文為 CSDN 翻譯，轉載請注明來源出處。
擴展閱讀
? ?
架構師成長系列
支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路 2020-09-21
Mobvista首席架構師蔡超：工作感悟之失敗與成功，我的8點總結2020-09-20
奈學教育CEO孫玄：成為一個有情懷的工程師，我的12點思考2020-09-19
架構師，是否需要寫代碼？2020-09-18
Netstars CTO陳斌：架構師的成長之路2020-09-17
阿里技術專家麒燁：修煉測試基本功2020-09-16
愛奇藝數據中臺負責人馬金韜：數據中臺建設與應用2020-09-14
數之聯CTO方育柯：技術的意義在于成就他人2020-09-13
東方證券首席架構師樊建：企業微服務架構轉型實踐2020-09-12
紅帽資深解決方案架構師魏新宇：云原生應用構建之路2020-09-10
蘇寧智能 BU大數據中心數據治理團隊負責人韋真：數據治理“三字經”，超實用！2020-09-09
螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護隱私的共享智能？2020-09-08
阿里高級技術專家簫逸：如何畫好一張架構圖？2020-09-07
阿里巴巴閑魚架構負責人王樹彬：萬億交易規模技術架構實踐2020-09-05
58轉轉技術總監駱俊武：監控系統選型？必讀本篇！2020-09-04
螞蟻集團高級架構師郭援非：分布式數據庫是金融機構數字化轉型的最佳路徑2020-09-03
工行高級經理林承軍：工行基于 MySQL 構建分布式架構的轉型之路2020-09-02
平安銀行吳建峰：RocketMQ 在銀行的應用和實踐2020-09-01
阿里高級技術專家張建飛：應用架構分離業務邏輯和技術細節之道2020-08-31
? ?END ? ?? #接力技術，鏈接價值# 點分享點點贊點在看 新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！總結
以上是生活随笔為你收集整理的Erik Dietrich：二十年的编程，教会我的五件事！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： NYOJ 214 单调递增子序列(二)
- 下一篇： NYOJ 236 心急的C小加