在最近的一篇文章中，我寫了為什麼不應該使用微服務[1]，我在文章的另一側有提到，開發人員才是噩夢般單體應用的問題所在。不僅如此，還有更多。
讓我們從單體應用的角度來看。當一個單體應用加入了太多東西最終變成一大碗意大利麵時，它就變成了一場噩夢。改變A點的一些東西就會破壞Z點的某些東西。當你試著修復它時，你很快就會把整個意大利麵放在叉子上,難以著手。
有趣的問題是，為什麼會這樣呢?
是模式的問題嗎?另一種模式能解決這個問題嗎?
簡而言之，答案是否定的。這不是模式的問題，如果不解決原因，新模式就不能解決問題。如果你堅持同樣的根本原因，任何新的努力也都會失敗。
▌你真的覺得在同一個團隊的另一種模式下，你就會成功嗎?
人類是複雜的。團隊是一個複雜的有機體。開發團隊也不例外。
那麼，為什麼會這樣呢?
這不是一個單一的原因，它是多個原因的綜合。
這是我曾經遇到過的最大的幾點相同原因。
缺乏經驗的開發者
可能發生的最糟糕的事情之一是，一群年輕的開發人員正在開發它，卻沒有人指導他們。缺乏經驗是典型的，就其本身而言並不壞。但如果整個團隊都缺乏經驗，這意味著他們都在學習如何構建這個項目。他們會犯很多很多很多的錯誤。這在學習過程中是很正常的，但對項目來說卻是一場噩夢。我看到的結果通常是錯過了最後期限和不可維護的代碼庫。更不用提客戶從來就沒高興過。
一組獨行俠
你的團隊中有幾個開發者知道他們在做什麼。這個項目被拆分開，每個人都可以用最少的接口或重疊得到它的開發部分。現在，開發人員按照自己的風格進行編碼和工作，好或壞都不重要。他們所看到的只是他們所關心的那一小塊。
我現在過度簡化了這個問題，因為工作中的動態性非常複雜，獨行俠們各自工作、互不關心會帶來很多問題。結果是相同邏輯的多個實現，這些邏輯出現在不屬於它的地方，接口被破壞(它們從未像前面定義的那樣)，抱怨和咆哮持續發生，誰的失誤導致了錯誤，誰又應該修復它呢？
不理解或不關心複雜性
我在我的時事通訊上寫過很多次這種情況。複雜性無處不在，作為開發人員，你需要處理大量的複雜性。這一技能甚至比了解你所選擇的語言的語法更為重要。
在進行更改或實現新特性之前，請考慮更改會影響什麼。這意味著什麼?數據流向何處?把我的順序邏輯放到PersonController（人稱控制器）中有意義嗎?如果我使用那個方法/服務/X會有什麼後果? < -這一點經常被忽略。尋找數據加載，它可能有副作用，等等。
在項目中測試新的語言、框架和模式
學習是偉大的，也是有趣的。但在一個期限很緊的真實項目中卻不是這樣，團隊中也沒有人曾經使用過這個新的技術堆棧。哇偶，這個框架看起來不錯，我要用它來做下一個客戶端項目。
不要!
客戶端或關鍵任務項目不是玩弄新技術的地方。團隊應該使用他們瞭解的經過驗證的技術。如果一項新技術真的能幫上忙，那就告訴所有相關人員這是一項新技術，肯定會有錯誤產生。
我將很快實現它
它甚至與測試無關。“我做得很快”方法的普遍問題是開發人員會忽略他這麼做的後果。他不會想太多，只是想盡快把事情處理好。就像在一箇中央服務中加載額外的數據，這在他的個人情況下是必需的，他可以快速實現。該死，他只是忽略了這是中央服務器故意忽略的，他的改變破壞了另一部分的性能。
嘿，作為開發人員，你的工作就是保持代碼可維護性。唯一的例外是一次性軟件。
開發人員編寫代碼而不是業務人員
如果你聽到開發人員開始罵罵咧咧，那麼他們肯定是又在抱怨業務人員、項目經理或其他他們認為應該為軟件如此糟糕負全責的人。他們從來不會自我反省，總是一味地指責別人。
但是要知道，項目經理並沒有編寫代碼。是你作為一個開發者編寫的。所以，你的工作就是把它做好。項目經理沒有添加意大利麵條式的代碼。不，是開發人員乾的。
是啊，有時候你沒有時間，卻需要完成它，那就應該這樣：你還是要寫好代碼。時間是一種約束，要充分利用它，不要總抱怨別人。
無視規則，做事馬虎，錯誤的偷懶
你的團隊中有規則，從代碼格式化規則到處理更改請求等等。然而，總會有一群開發者直接忽略它們。
在一個團隊中，代碼格式化規則必須在代碼評審中檢查。然而，相同的開發人員總是錯誤地格式化代碼。如果一條規則很愚蠢，那就改變它。
草率和錯誤的偷懶與“我要快點完成它”的話語總是分不開的。同樣的結果，不同的原因。
對一切說“是”
如果業務人員說“跳”，許多開發者會問“跳多高?”或者直接去做。對需求或工作負載也是如此。
如果需求是一坨翔，有邏輯缺陷，缺失了某些方面，或者根本沒有意義，那就和業務人員談談。但是不要用開發人員的語言和他們胡言亂語，用他們的語言去談論問題。
對工作負載也是一樣。不要因為某個項目經理告訴你需要完成某項任務，就一時興起改變任務。一個團隊處理多個項目，項目經理各不相同,這樣的事情早已是臭名昭著。當團隊中有“是的，先生”這種類型的開發人員時，情況尤其糟糕。其結果是給那些傾向於快速和草率工作的開發人員帶來了額外的壓力。從而導致糟糕的代碼。
錯誤的決定
勇於做出錯誤的決定，而不是袖手旁觀，誇大或否認它。
最近的一個例子更清楚地說明了這一點。以開發團隊為例，他們從零開始開發了一個新應用程序。他們選擇了文檔存儲，但是用關係的方式對域名對象建模。現在增加X特性和迭代之後，性能下降了……但是，沒有人承認架構決策是錯誤的，而任何人又都在抱怨它——甚至是開發者。糟糕的單體應用。
是的，他們確實做了一個錯誤的決定，在這個特殊的案例中，它是與“客戶項目上的新技術”相結合的。
結束語
在我作為開發人員的幾十年裡，我看到了許多這樣的原因和後果。我自己做過很多，我可以告訴你一件事。如果你不改變自己，你會再犯同樣的錯誤。導致同樣的問題。無論是構建單體應用還是微服務。
不是技術的問題，而是開發者。
相關鏈接：
[1]——https://codeboje.de/do-not-use-microservices/
英文原文：https://codeboje.de/developers-problem-not-monoliths/譯者：浣熊君( ･᷄৺･᷅ )
閱讀更多 Python部落 的文章
