在過去的4-5年中，對程式設計師的需求增長如此之快，以至於程式設計師的數量總是每五年翻一番。結果，擁有5年經驗的程式設計師所擁有的行業任職時間比整個行業的一半還多。

我現在在這個行業中已經推進了20年。我花了大約10個角色擔任我的主要職能是編寫程式碼。其他10個專案涉及管理程式設計師，指導他們，就如何管理它們向組織提供諮詢，執行程式碼庫評估實踐以及如今的內容營銷。但是在所有這些角色中，我都不同程度地編寫了程式碼。以下是我認為是20年程式設計生涯中最重要的教訓和收穫。

1. 重複是最糟糕的

“避免複製貼上程式設計！”，這是可怕而草率的做法。

想象一下，您有一個可以完美使用的CalculateBill（）方法，但是產品經理徘徊並說：“我們在墨西哥招募了新客戶，您在那兒計算的帳單有所不同。”因此，您複製當前方法，將其貼上，將其重新命名為CalculateBillMexico（）並根據需要進行調整。

下面是這種方法的問題：

1. 如果將來的更改需要調整核心邏輯，那麼您現在必須做更多的工作並修改2種方法。
2. 現在，您有2次機會在此類更改期間引入錯誤。
3. 現在，您已經建立了一個“設計模式”，並且隨著全球擴張的繼續，您的程式碼正在乞求一種新的冗餘方法。
4. 隨著工作的進行，您的勞動量將急劇增加。
5. 通過忘記在任何需要的地方進行更改來引入錯誤只是時間問題。
6. 最終，所有這些方法都將有足夠的不同，以致您無法再將它們合理地合併回去並解決問題，但相差無幾，您可以避免每次有人更新計費規則時進行20次更改。

系統中的知識重複可以多種方式發生，而簡單的複製貼上只是最明顯和最晦澀的。還有重複知識的其他示例：

• 一個for迴圈和一個程式碼註釋就在其上方，解釋了開始，結束和增量。
• 全域性變數向內聯分配了一個值，然後（也許）從配置檔案中重新分配了一個值。
• 具有“ PretaxTotal”，“ Tax”和“ Total”列的資料庫表
• 範圍廣泛的ERP系統，將客戶儲存在CRM模組中，然後再儲存在計費模組中。

最好的情況就是您已經有了適當的流程和系統來認真地跟蹤重複並確保同時更新。

當您開始構建複雜的邏輯（然後必須進行維護-請參閱下一節）以確保同步時，會發生更糟的情況。

2.程式碼是責任

少即是多，實際上，我已經擔任了多年非常專業的管理顧問。我進行資料驅動的程式碼庫評估，並幫助IT領導者制定有關程式碼庫的戰略決策。因此，我可以檢視，分析和收集大量程式碼庫的統計資訊。

關於程式碼庫的幾乎所有不良之處都與程式碼庫的大小有著顯著的關係，以邏輯程式碼行來衡量。

我喜歡編寫，研究，分析和使用它來構建事物。但是請不要誤會-這是一個巨大的責任。始終努力使用盡可能少的程式碼來完成所有工作。

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

我的意思是警告您，有多少高階開發人員表面上看起來很牛，但實際上並非如此。

因此，當您是新手時，請給前輩帶來疑問的好處並順應他們，但不要僅僅假設他們告訴您的是對還是對。自行驗證（最好不要在它們前面）。

4.  TDD是有效的，但是帶來維護成本

大約10年前，我對TDD持懷疑態度。我決定寫一篇關於TDD為什麼不是那麼出色的部落格文章。

5.證據為王

程式碼審查或團隊或組織內的任何其他形式的協作過程中，如果您想就任何事情向管理層或領導層提出任何理由，證據就是您的朋友。

證據將贏得您的論點，尊重，領導角色和職業發展。

我的意思是在程式碼庫中查詢有無全域性狀態的模組，並對照JIRA故障單或其他事件的發生率交叉引用這些模組。