從業(yè) 20 年的程序員，“盤”出來的五種編程經(jīng)驗
一個擁有 20 年編程經(jīng)驗的“熟手”，編程干貨有多少？本文作者是一名從業(yè) 20 年的程序員，他分享了自己這 20 年來學(xué)到的 5 種編程經(jīng)驗：重復(fù)的知識最糟糕、把代碼當(dāng)成一種債務(wù)、信任高級開發(fā)人員信任但要驗證、使用 TDD、用“證據(jù)”證明自己的代碼更好。下文是關(guān)于這 5 種經(jīng)驗的具體描述。
今年，我對DEV開發(fā)平臺越來越熟悉。眾多激憤的 Reddit 評論者和“不過如此”的鑒賞家們構(gòu)成了一片荒漠，在這片荒漠之中，DEV 已經(jīng)成為令人耳目一新且充滿積極力量的綠洲。
這個社區(qū)有著很有趣的一面，它似乎非常注重初學(xué)者。我經(jīng)常在這里看到行業(yè)新手寫的帖子。我所說的新手是指那些在訓(xùn)練營中尋找入門級工作，或者那些在不幸的“初級”程序員崗位上工作且有抱負(fù)的程序員。
我感覺這很有趣，新手通常會對這個行業(yè)充滿熱情，這種激情富有感染力。他們的激情也讓我認(rèn)識到自己在這個行業(yè)的定位——熟手（老人兒）。
在過去四、五十年里，行業(yè)對程序員的需求急劇增長，以至于程序員的數(shù)量總是每五年翻一番。因此，擁有 5 年經(jīng)驗的程序員占據(jù)著整個行業(yè)一半以上的職位。我在這個行業(yè)已經(jīng)快 20 年了。其中 10 年，我的主要職責(zé)是編寫代碼。另外10 年是管理者，指導(dǎo)新人、向組織咨詢?nèi)绾喂芾聿⑹┬写a庫評估實踐以及當(dāng)前從事的內(nèi)容營銷。
于是，我問自己，“如果我能把自己的經(jīng)歷進(jìn)行簡明扼要地總結(jié)（假設(shè)真的有人關(guān)心的話），我會向新手們提些什么建議呢？”
所以，就產(chǎn)生了這篇文章。以下是我認(rèn)為自己在 20 年編程生涯中最重要的經(jīng)驗和收獲。
1. 重復(fù)的知識最糟糕
“避免復(fù)制粘貼式編程！”
當(dāng)你在應(yīng)用程序中復(fù)制、粘貼代碼，然后調(diào)來調(diào)去的時候 (“復(fù)制、粘貼、調(diào)整”反模式)，如果沒有人打你的手，那么現(xiàn)在就考慮舉起“戒尺“吧。因為這種做法很糟糕，也很隨意。
假設(shè)，你有一個用得好好的 CalculateBill() 方法，但是產(chǎn)品經(jīng)理卻走過來說：“我們正在墨西哥接待新客戶，與你那個計費的方式有點不同。”因此，你復(fù)制了當(dāng)前的這個方法，也粘貼了它，將其重命名為 CalculateBillMexico()，并根據(jù)需要對其進(jìn)行調(diào)整。
所以在這種方式的操作下，產(chǎn)生了這些問題：
- 如果將來的變更需要對核心邏輯進(jìn)行調(diào)整，現(xiàn)在必須額外修改這兩個方法。
- 在做此類變更時，可能引入了兩個 bug 。
- 你現(xiàn)在已經(jīng)建立了一個“設(shè)計模式”，隨著在全球的繼續(xù)擴(kuò)展，你的代碼更新需要一個又一個新的、冗余的方法。
- 你的工作量將會急劇增加。
- 忘記修改需要修改的地方，從而引入 bug，這種情況的出現(xiàn)只是時間問題。
- 最終，所有這些方法都會有一定的差異，這些差異足以令你無法合理地將它們合并起來修復(fù)這種混亂，但是差異又沒有大到可以避免有人在更新一條計費規(guī)則時改上 20 次。
這是一個爛攤子。然而，復(fù)制粘貼只是表層問題。
復(fù)制粘貼只是開始
真正的問題是系統(tǒng)中的知識重復(fù)。
在你的系統(tǒng)中，知識的復(fù)制可以以多種方式出現(xiàn)，蹩腳的復(fù)制 - 粘貼是最明顯和最笨拙的?？纯雌渌R重復(fù)的例子：
- 一個 for 循環(huán)，在它的正上方有一個解釋開始、結(jié)束和遞增的代碼注釋。
- 為一個全局變量內(nèi)聯(lián)賦值，然后 (可能) 從配置文件中取一個值重新賦給它。
- 包含“PretaxTotal”、“Tax”和“Total”列的數(shù)據(jù)庫表
- 一個范圍很廣的 ERP 系統(tǒng)，它將客戶存儲在 CRM 模塊中，然后再存儲在計費模塊中。
有了以上這些，最好的情況是有適當(dāng)流程和系統(tǒng)來努力跟蹤副本，并確保及時更新。如果缺乏代碼注釋，可能團(tuán)隊的首席嘮叨官更新代碼時就會一直在你耳邊念叨：檢查注釋、檢查注釋······
或者，以ERP系統(tǒng)為例，這可能是一個嚴(yán)格的部門備忘錄，告訴銷售和會計，他們都需要發(fā)送正式的電子郵件，以確?？蛻粜畔⒈３滞健?/p>
記住，以上這些已經(jīng)是最好的情況。當(dāng)開始構(gòu)建復(fù)雜的邏輯以確保同步時，會出現(xiàn)更糟糕的情況。
也許你可以實現(xiàn)一個數(shù)據(jù)庫觸發(fā)器，在“total”列發(fā)生更改時確保 PretaxTotal + Tax 仍然等于 total?；蛘?，你可以編寫一些笨拙的狀態(tài)檢查邏輯，當(dāng)默認(rèn)的全局變量值與配置文件中的值不匹配時，記錄一個警告。
最糟糕的情況是數(shù)據(jù)不同步。那么，作為一名程序員，可能不用擔(dān)心它，因為你拿的那份工資所要承擔(dān)的工作不包括搞清楚為什么你們從來沒有給客戶開過發(fā)票，或者為什么多年來一直多收客戶的錢。
但是，面對藏身于系統(tǒng)各處的問題，根除和積極抵制可以幫你避免所有這些問題。
2. 代碼是一種債務(wù)
作為開發(fā)人員，我們要學(xué)會熱愛代碼。編寫代碼感覺很好，創(chuàng)造些什么出來也很令人興奮。
此外，我們尋找新的語言、范例、框架、堆棧、工具、api 和庫來學(xué)習(xí)。我們沉浸在自己的世界里，因為在這種狀態(tài)下，我們可以愉快地生產(chǎn)代碼。
一些極端的開發(fā)者甚至把每小時生成的代碼行數(shù)作為生產(chǎn)力的度量標(biāo)準(zhǔn)。即使沒有達(dá)到這個程度，也很容易認(rèn)為代碼越多越好。代碼是殺手級應(yīng)用程序和業(yè)務(wù)的 DNA，公司認(rèn)為它是有價值的知識產(chǎn)權(quán)。
但是，代碼完全就是一種債務(wù)。
少即是多
你知道有什么比“用 10 行代碼來編寫別人用 100 行代碼才能完成的事情”更好的嗎？那就是用 0 行代碼。
寫這么一行代碼:
- printf("Hello World!");
你認(rèn)為有多少事情會出錯？
- 這段代碼會在允許控制臺打印的環(huán)境中運(yùn)行嗎？
- 那段神奇的字符串以后不會成為問題嗎？
- 你不應(yīng)該記錄日志嗎？這是一條最佳實踐。
- 你有沒有想過這對安全的影響？
保守地說，這行代碼中有 10 個地方可能出錯。現(xiàn)在，我們加上第二行。
那么，你會覺得這將導(dǎo)致總共 20 件可能出錯的事情嗎？
我認(rèn)為幾乎得有 100 件。你可以叫我悲觀主義者，但我認(rèn)為潛在問題與代碼行之間的關(guān)系更接近組合而非線性的關(guān)系。
實際上，我做過幾年管理顧問，看過、分析并收集了大量代碼庫的統(tǒng)計數(shù)據(jù)如果算上在客戶那兒自動分析的代碼庫，我已經(jīng)收集了 1000 多個代碼庫的詳細(xì)統(tǒng)計信息。然后，為了尋找相關(guān)性我對這些數(shù)據(jù)進(jìn)行了回歸分析。
所以，你知道與不良代碼庫的相關(guān)性更強(qiáng)的是什么嗎？那就是代碼庫的大小。
幾乎關(guān)于代碼庫的所有壞事都與代碼庫的大小有很大的關(guān)系（以代碼的邏輯行來衡量）。
我愛代碼，我喜歡寫它、研究它、分析它，以及用它做東西。但毫無疑問的是，代碼是一個巨大的債務(wù)，我們應(yīng)該去努力用盡可能少的代碼來做每件事。
3. 高級開發(fā)人員：信任但驗證
在我 23 歲時做了第一份軟件工程工作，當(dāng)時我對高級開發(fā)人員懷有一種崇敬，我從他們身上學(xué)到了很多。如果你是這個行業(yè)的新手，你可能會像我一樣，認(rèn)為團(tuán)隊中資深開發(fā)人員的每一句話都是智慧的結(jié)晶。而且，如果你幸運(yùn)的話，他們中的很多人的確是這樣，特別是在一開始的時候。
但，并不是所有的高級開發(fā)人員都如此。
回想起來，有些人不是技術(shù)專長，而是在那兒很長一段時間無所事事，設(shè)法不被解雇，并靠混資歷晉升為“資深”或“高級”之類的頭銜。
這種現(xiàn)象非常普遍，幾年前我編造了一個詞來描述它，現(xiàn)在每個月都有數(shù)百條谷歌搜索。當(dāng)我時創(chuàng)造了“專家級初學(xué)者”這個術(shù)語，它引起了人們的強(qiáng)烈共鳴。
所以，當(dāng)你是新人的時候，要相信前輩的說法，尊重他們，但不要想當(dāng)然地認(rèn)為他們說的就是對的。自己得驗證一下，當(dāng)然了，最好不要當(dāng)著他們的面驗證。
4. TDD 真的行，它改變了游戲規(guī)則
當(dāng)涉及到任何編程，甚至只要是與技術(shù)相關(guān)的事情時，我們往往會帶有偏見的主觀選擇。
- IDE 與輕量級編輯器的討論？
- 蘋果、Windows 還是 Linux？
- 你怎么看 PHP？
- 制表符（tab）還是空格（space）？
拿出其中任何一個，就能看到那些持明確觀點的人的爭吵。因此，考慮到所有這些，我意識到自己正在陷入類似的境地，那就是“做 TDD 還是不做 ”。
我的目的不是說教，而是分享我自己的經(jīng)驗。
大約 10 年前，我是 TDD 懷疑論者。我并不是單元測試的懷疑論者，事實上，我從一開始就接受了它，并將其作為一種有用的實踐，但對TDD不太確定。
甚至，那時候的我決定寫一篇博客，來解釋為什么 TDD 沒那么好。
但我不想就這件事寫一篇站不住腳又蹩腳透頂?shù)脑u論文章。所以我決定做一個嚴(yán)格遵循 TDD 的小型客戶項目 (順便一提，固定價格)，這樣我就可以寫一篇文章，但這篇文章的前提是“我真的去花費幾周的時間做純粹的 TDD，并發(fā)現(xiàn)它不好的事實”。
實際上，整個過程可能是好幾天。我做每件事都需要花很長時間，做每件事都很麻煩，也很不自然。我一樁一樁地把它們記錄下來，以證明為什么TDD是一種糟糕的做事方式。
然而，我對這個范例很著迷，以至于在某一天花了4到5個小時編寫代碼，卻沒有實際運(yùn)行應(yīng)用程序來檢查更改是否有效。（通常，我會每隔 10 分鐘左右運(yùn)行一次應(yīng)用程序，以檢查更改是否真正有效。）
意識到自己已經(jīng)工作了幾個小時，我啟動了應(yīng)用程序，感覺必須要再調(diào)試幾個小時。畢竟，以前至少需要調(diào)試 30 多回。但是，一切都能正常運(yùn)轉(zhuǎn)，第一次沒有任何異常。我花了幾個小時編寫代碼，沒有查看自己的 GUI，也沒有在運(yùn)行時驗證任何東西，但所有的一切都運(yùn)轉(zhuǎn)正常。
于是，我學(xué)習(xí)了這種技術(shù)，掌握了它，還講授了相關(guān)課程，做了相關(guān)咨詢。除此之外，我調(diào)查了單元測試對代碼庫的影響，發(fā)現(xiàn)這些影響無疑都是好的。
5. 證據(jù)為王
到目前為止，在這篇文章中，我已經(jīng)提到了自己的代碼庫評估實踐，并討論了經(jīng)驗數(shù)據(jù)。所以，讓我們正式聊聊，在我目前職業(yè)生涯中收獲的最后一點經(jīng)驗：證據(jù)就是一切！
代碼評審可以作為一種教育性的賦能活動，或者稱他們可以處決你的靈魂。然而，代碼評審很可能會在啟發(fā)性的體驗和無意義的爭吵之間來回?fù)u擺。
你會聽到諸如“那不是一個好的設(shè)計”或“那沒有效率”之類的話，你可能也會說這些話。而且，你很可能在沒有任何證據(jù)的情況下聽到或說出這些話。
那么，怎樣去解決這個問題呢？
證據(jù)的重要性
如果在代碼評審過程中，或者在團(tuán)隊、組織內(nèi)協(xié)作時，有人對你橫加指責(zé)，那么證據(jù)就是最好的說明。如果試圖向管理層或領(lǐng)導(dǎo)層解釋任何事情，證據(jù)也是最好的說明。我的意思是，在代碼庫中找到有全局聲明和沒有全局聲明的模塊，然后將 JIRA 問題單的事故率或者其他數(shù)據(jù)作為參考依據(jù)。
你的團(tuán)隊中是否有人要求你使用與你選擇不同的庫或 API，因為它們具有“無憑無據(jù)”的良好性能？那么，你接受他所說的嗎？
如果不接受，那就去證明他說的是錯的。比如，進(jìn)行實際的時間測試。
讓你自己習(xí)慣于做實驗，而不是大聲地表達(dá)和重復(fù)觀點。用實證驗證想法，這種做法具有直接價值。
當(dāng)面對質(zhì)疑時，有時你會發(fā)現(xiàn)自己是對的，而有時會意識到自己是錯的。哪怕通過證明是錯的，也很有價值。
除此之外，你會開始用一種其他人無法匹敵的方式進(jìn)行辯論，從而樹立起自己的品牌，那就是勤奮和正確。這可以幫助你克服一些看似不可逾越的障礙，比如“我只是個初學(xué)者，而他是個專家”。其實，他不過是一個專家級初學(xué)者而已。
如果將眼光再放長遠(yuǎn)一點來看，這種操作，會讓你在事業(yè)上有更好的發(fā)展。能夠編寫代碼確保你會有一個回報豐厚的職業(yè)生涯，能夠編寫代碼并使用證據(jù)來為行動過程提供技術(shù)和業(yè)務(wù)用例，將確保你的事業(yè)蒸蒸日上。
以健康的方式使用 (或不使用) 這些
寫這篇文章的時候，我覺得自己富有哲理。事實上，如果你足夠努力地做過嘗試，我想你可以反駁這些觀點。
我并沒有把這些作為一成不變的編程法則或某種專業(yè)的行為準(zhǔn)則，我只是把它們作為職業(yè)生涯中自己學(xué)到的經(jīng)驗教訓(xùn)提供給大家，它們只是我的個人觀點，請大家謹(jǐn)慎選擇。
希望這些觀點能對你們有所幫助，使你們能夠根據(jù)自己的需要以健康的方式采用或者不采用它們。
作者介紹
Erik Dietrich，DaedTech LLC 的創(chuàng)始人、程序員、架構(gòu)師、IT 管理顧問、作者和技術(shù)人員。
