背景
我是公司的軟件工程師和 TDD從業人員。我的經理還負責編碼（如果需要），並管理他的工程師下屬。
最近與我的經理就使用軟件設計模式進行了激烈的辯論。
問題
通常，當我受命執行功能和代碼時，在我的代碼審查期間，經理會因使用常見的軟件設計模式而受到挑戰。他認為這是不必要的，因此應該盡可能“直截了當”地編碼。我引述直截了當，因為我們似乎不同意“功能”的範圍。在許多情況下，此功能不像我的經理認為的那樣“簡單明了”，並且要求使用設計模式來分離職責並最大程度地減少對（未經測試的）代碼庫的影響。
有兩種常見用法情況下，我將應用設計模式來解決問題：
-
實現需要更改不可測試的舊類的新功能
-
通過連接未知數來解決不確定性
- 經常沒有對新功能的要求進行徹底考慮。面對最後期限，我們必須在代碼中留下“漏洞”，以便讓企業下定決心而不影響進度。
- 例如，我可能正在實現一個接口以從中檢索運行時值一些未知的數據源，我實現了一個裝飾器，該裝飾器在運行時使用 IRuntimeValueProvider 進行檢索。我可以保留實際的實現方式，直到做出決定為止，而不會影響其他業務邏輯。
- 經理認為我正在引入具有自己不熟悉的名稱的接口，例如 IHttpContentFactory ， IHttpClientProvider 。他仍然對我的解釋和論證感到不滿意，這些解釋和論證表明這些工廠在構造組件中具有特定目的，並為可擴展性提供了接縫。
- 在我使用 IHttpClientFactory 來抽象在他的使用者之外構造 HttpClient 的過程中，他特別提到，他認為使用者應該負責構造每個實現細節，這將導致構造邏輯遍及整個地方。
由於類似的設計會議，我們陷入了一些爭論。在一個激烈的爭論中，甚至有人告訴我“ [他]從事編程已有20多年了！” ，這意味著我什至不敢質疑他的權威。
我為緩解此問題所做的嘗試
- 對一些不太明顯的組件寫了詳細的評論，為什麼我需要這些組件以及它們的作用是什麼 li>
- 被動地證明了我的設計
- 與其他大多數組件相比，我構建的組件的bug計數明顯降低
- 正確預期了需求的變化，這使得實現該目標所需的代碼更改最少要求
- 當我受到挑戰時，我會通過解釋自己的思維過程和推理來解決他的擔憂。
- 但是，我仍然因過分設計代碼而受到譴責。
- 與我的同事們進行了非正式的討論，並私下徵求他們的意見。
- 他們中的大多數人都讚賞我的做法合理，甚至有人提到他從我那裡學到了很多東西。大多數工程師喜歡與我討論他們的編碼問題，因為我通常可以向他們提供有用的建議或指出他們可能會錯過的一些東西
- 舉行非正式的演講會來教育我為何我在這里和那裡應用設計模式的其他工程師（和經理）
我不想因為說我的編碼技能絕對比我的經理更好而自大即使在演示，解釋和向他展示了客觀結果之後，也沒有足夠的想法說服他。一方面，我想交付無錯誤，經過良好單元測試和設計的代碼。另一方面，我因設計不佳而不斷受到批評，並且肯定將其強制為“批准”方式來“複雜化”我的代碼。
我們如何找到中間立場？
更新
由於我收到了很多關於遵循軟件工程原則的教條式，甚至過分狂熱的態度的評論，因此我想澄清一下：
我不是在教條，也不是在發狂。我願意關心人們是否閱讀和理解我的代碼，無論他們是否使用/理解設計模式。我要求同事在代碼審查期間提供反饋，以了解他們是否了解我的代碼。他們說他們這樣做，並且他們理解我為什麼以這種方式設計組件。在一種情況下，我對設計模式的使用有助於將配置查找邏輯集中在一個位置，而不是分散在數十個位置，而這經常需要更改。
說實話，看到如此強烈的刻板印象“為什麼工程師不能像經理一樣思考”，我感到非常失望。歸根結底，每件事都可以說是過度設計：為什麼將字段標記為 private 而不是公開所有內容，為什麼要進行單元測試，如果沒有用戶執行一個單元，
我使用設計模式或實際上進行任何軟件工程的動機是最小化風險並為公司帶來價值（例如減少了代碼庫中不必要的邏輯散佈，以便可以在一個位置進行管理。
對不起，如果聽起來像是一聲喧。我一直在尋找“我們如何找到中間立場”的答案，而不是像“工程師認為通過應用沒人能理解的設計模式而變得聰明”這樣的屈從性答案。