這個社群有著很有趣的一面，它似乎非常注重初學者。我經常在這裡看到行業新手寫的帖子。我所說的新手是指那些在訓練營中尋找入門級工作，或者那些在不幸的「初級」程式設計師崗位上工作且有抱負的程式設計師。
我感覺這很有趣，新手通常會對這個行業充滿熱情，這種激情富有感染力。他們的激情也讓我認識到自己在這個行業的定位——熟手（老人兒）。
在過去四、五十年裡，行業對程式設計師的需求急劇增長，以至於程式設計師的數量總是每五年翻一番。因此，擁有 5 年經驗的程式設計師佔據著整個行業一半以上的職位。我在這個行業已經快 20 年了。其中 10 年，我的主要職責是編寫**。另外10 年是管理者，指導新人、向組織諮詢如何管理並施行**庫評估實踐以及當前從事的內容營銷。
於是，我問自己，「如果我能把自己的經歷進行簡明扼要地總結（假設真的有人關心的話），我會向新手們提些什麼建議呢？」
「避免複製貼上式程式設計！」
當你在應用程式中複製、貼上**，然後調來調去的時候 (「複製、貼上、調整」反模式)，如果沒有人打你的手，那麼現在就考慮舉起「戒尺「吧。因為這種做法很糟糕，也很隨意。
假設，你有乙個用得好好的 calculatebill() 方法，但是產品經理卻走過來說：「我們正在墨西哥接待新客戶，與你那個計費的方式有點不同。」因此，你複製了當前的這個方法，也貼上了它，將其重新命名為 calculatebillmexico()，並根據需要對其進行調整。
所以在這種方式的操作下，產生了這些問題：
如果將來的變更需要對核心邏輯進行調整，現在必須額外修改這兩個方法。
在做此類變更時，可能引入了兩個 bug 。
你現在已經建立了乙個「設計模式」，隨著在全球的繼續擴充套件，你的**更新需要乙個又乙個新的、冗餘的方法。
你的工作量將會急劇增加。
忘記修改需要修改的地方，從而引入 bug，這種情況的出現只是時間問題。
最終，所有這些方法都會有一定的差異，這些差異足以令你無法合理地將它們合併起來修復這種混亂，但是差異又沒有大到可以避免有人在更新一條計費規則時改上 20 次。
這是乙個爛攤子。然而，複製貼上只是表層問題。
真正的問題是系統中的知識重複。
在你的系統中，知識的複製可以以多種方式出現，蹩腳的複製 - 貼上是最明顯和最笨拙的。看看其他知識重複的例子：
有了以上這些，最好的情況是有適當流程和系統來努力跟蹤副本，並確保及時更新。如果缺乏**注釋，可能團隊的首席嘮叨官更新**時就會一直在你耳邊念叨：檢查注釋、檢查注釋······
或者，以erp系統為例，這可能是乙個嚴格的部門備忘錄，告訴銷售和會計，他們都需要傳送正式的電子郵件，以確保客戶資訊保持同步。
記住，以上這些已經是最好的情況。當開始構建複雜的邏輯以確保同步時，會出現更糟糕的情況。
也許你可以實現乙個資料庫觸發器，在「total」列發生更改時確保 pretaxtotal + tax 仍然等於 total。或者，你可以編寫一些笨拙的狀態檢查邏輯，當預設的全域性變數值與配置檔案中的值不匹配時，記錄乙個警告。
最糟糕的情況是資料不同步。那麼，作為一名程式設計師，可能不用擔心它，因為你拿的那份工資所要承擔的工作不包括搞清楚為什麼你們從來沒有給客戶開過發票，或者為什麼多年來一直多收客戶的錢。
但是，面對藏身於系統各處的問題，**和積極抵制可以幫你避免所有這些問題。
作為開發人員，我們要學會熱愛**。編寫**感覺很好，創造些什麼出來也很令人興奮。
此外，我們尋找新的語言、範例、框架、堆疊、工具、api 和庫來學習。我們沉浸在自己的世界裡，因為在這種狀態下，我們可以愉快地生產**。
一些極端的開發者甚至把每小時生成的**行數作為生產力的度量標準。即使沒有達到這個程度，也很容易認為**越多越好。**是殺手級應用程式和業務的 dna，公司認為它是有價值的智財權。
但是，**完全就是一種債務。
你知道有什麼比「用 10 行**來編寫別人用 100 行**才能完成的事情」更好的嗎？那就是用 0 行**。
寫這麼一行**:
printf("hello world!");保守地說，這行**中有 10 個地方可能出錯。現在，我們加上第二行。
那麼，你會覺得這將導致總共 20 件可能出錯的事情嗎？
我認為幾乎得有 100 件。你可以叫我悲觀主義者，但我認為潛在問題與**行之間的關係更接近組合而非線性的關係。
實際上，我做過幾年管理顧問，看過、分析並收集了大量**庫的統計資料如果算上在客戶那兒自動分析的**庫，我已經收集了 1000 多個**庫的詳細統計資訊。然後，為了尋找相關性我對這些資料進行了回歸分析。
所以，你知道與不良**庫的相關性更強的是什麼嗎？那就是**庫的大小。
幾乎關於**庫的所有壞事都與**庫的大小有很大的關係（以**的邏輯行來衡量）。
我愛**，我喜歡寫它、研究它、分析它，以及用它做東西。但毫無疑問的是，**是乙個巨大的債務，我們應該去努力用盡可能少的**來做每件事。
在我 23 歲時做了第乙份軟體工程工作，當時我對高階開發人員懷有一種崇敬，我從他們身上學到了很多。如果你是這個行業的新手，你可能會像我一樣，認為團隊中資深開發人員的每一句話都是智慧型的結晶。而且，如果你幸運的話，他們中的很多人的確是這樣，特別是在一開始的時候。
但，並不是所有的高階開發人員都如此。
回想起來，有些人不是技術專長，而是在那兒很長一段時間無所事事，設法不被解雇，並靠混資歷晉公升為「資深」或「高階」之類的頭銜。
這種現象非常普遍，幾年前我編造了乙個詞來描述它，現在每個月都有數百條谷歌搜尋。當我時創造了「專家級初學者」這個術語，它引起了人們的強烈共鳴。
所以，當你是新人的時候，要相信前輩的說法，尊重他們，但不要想當然地認為他們說的就是對的。自己得驗證一下，當然了，最好不要當著他們的面驗證。
當涉及到任何程式設計，甚至只要是與技術相關的事情時，我們往往會帶有偏見的主觀選擇。
拿出其中任何乙個，就能看到那些持明確觀點的人的爭吵。因此，考慮到所有這些，我意識到自己正在陷入類似的境地，那就是「做 tdd 還是不做 」。
我的目的不是說教，而是分享我自己的經驗。
大約 10 年前，我是 tdd 懷疑論者。我並不是單元測試的懷疑論者，事實上，我從一開始就接受了它，並將其作為一種有用的實踐，但對tdd不太確定。
甚至，那時候的我決定寫一篇部落格，來解釋為什麼 tdd 沒那麼好。
實際上，整個過程可能是好幾天。我做每件事都需要花很長時間，做每件事都很麻煩，也很不自然。我一樁一樁地把它們記錄下來，以證明為什麼tdd是一種糟糕的做事方式。
然而，我對這個範例很著迷，以至於在某一天花了4到5個小時編寫**，卻沒有實際執行應用程式來檢查更改是否有效。（通常，我會每隔 10 分鐘左右執行一次應用程式，以檢查更改是否真正有效。）
意識到自己已經工作了幾個小時，我啟動了應用程式，感覺必須要再除錯幾個小時。畢竟，以前至少需要除錯 30 多回。但是，一切都能正常運轉，第一次沒有任何異常。我花了幾個小時編寫**，沒有檢視自己的 gui，也沒有在執行時驗證任何東西，但所有的一切都運轉正常。
於是，我學習了這種技術，掌握了它，還講授了相關課程，做了相關諮詢。除此之外，我調查了單元測試對**庫的影響，發現這些影響無疑都是好的。
**評審可以作為一種教育性的賦能活動，或者稱他們可以處決你的靈魂。然而，**評審很可能會在啟發性的體驗和無意義的爭吵之間來回搖擺。
你會聽到諸如「那不是乙個好的設計」或「那沒有效率」之類的話，你可能也會說這些話。而且，你很可能在沒有任何證據的情況下聽到或說出這些話。
那麼，怎樣去解決這個問題呢？
如果在**評審過程中，或者在團隊、組織內協作時，有人對你橫加指責，那麼證據就是最好的說明。如果試圖向管理層或領導層解釋任何事情，證據也是最好的說明。我的意思是，在**庫中找到有全域性宣告和沒有全域性宣告的模組，然後將 jira 問題單的事故率或者其他資料作為參考依據。
你的團隊中是否有人要求你使用與你選擇不同的庫或 api，因為它們具有「無憑無據」的良好效能？那麼，你接受他所說的嗎？
如果不接受，那就去證明他說的是錯的。比如，進行實際的時間測試。
讓你自己習慣於做實驗，而不是大聲地表達和重複觀點。用實證驗證想法，這種做法具有直接價值。
當面對質疑時，有時你會發現自己是對的，而有時會意識到自己是錯的。哪怕通過證明是錯的，也很有價值。
除此之外，你會開始用一種其他人無法匹敵的方式進行辯論，從而樹立起自己的品牌，那就是勤奮和正確。這可以幫助你克服一些看似不可逾越的障礙，比如「我只是個初學者，而他是個專家」。其實，他不過是乙個專家級初學者而已。
如果將眼光再放長遠一點來看，這種操作，會讓你在事業上有更好的發展。能夠編寫**確保你會有乙個回報豐厚的職業生涯，能夠編寫**並使用證據來為行動過程提供技術和業務用例，將確保你的事業蒸蒸日上。
以健康的方式使用 (或不使用) 這些
寫這篇文章的時候，我覺得自己富有哲理。事實上，如果你足夠努力地做過嘗試，我想你可以反駁這些觀點。
我並沒有把這些作為一成不變的程式設計法則或某種專業的行為準則，我只是把它們作為職業生涯中自己學到的經驗教訓提供給大家，它們只是我的個人觀點，請大家謹慎選擇。
希望這些觀點能對你們有所幫助，使你們能夠根據自己的需要以健康的方式採用或者不採用它們。
erik dietrich，daedtech llc 的創始人、程式設計師、架構師、it 管理顧問、作者和技術人員。
程式設計師的5種型別
在我的 旅程和程式設計經歷中，已經遭遇很多奇特的對手，還有更為奇特的盟友。我至少發現有5種 勇士，有些是出色的戰友，其他則似乎都在攪黃我的每個計畫。不過他們都在軟體開發的萬神殿上都有一席之地。如果沒有不同程式設計風格的良好組合，你可能會發現你的專案要不就是耗時過長，要不就是太不穩定或太過完美而無人去...
5年經驗程式設計師的尷尬處境
程式設計師這個職業和其他職業最大的區別可能就是，5年的經驗並沒給我帶來多少安全感 事實上我確實就做了5年的業務開發，其他諸如架構設計 系統非功能性需求關注不多。然後就出去找工作了。面試官 我看你有5年經驗，跟我聊聊你們的系統架構吧？我 架構這塊我涉及不多，是架構師在負責。面試官 預期就已經下來了 說...
5年經驗程式設計師的尷尬處境
程式設計師這個職業和其他職業最大的區別可能就是，5年的經驗並沒給我帶來多少安全感 事實上我確實就做了5年的業務開發，其他諸如架構設計 系統非功能性需求關注不多。然後就出去找工作了。面試官 我看你有5年經驗，跟我聊聊你們的系統架構吧？我 架構這塊我涉及不多，是架構師在負責。面試官 預期就已經下來了 說...