在最近的一篇文章中，我写了为什么不应该使用微服务[1]，我在文章的另一侧有提到，开发人员才是噩梦般单体应用的问题所在。不仅如此，还有更多。
让我们从单体应用的角度来看。当一个单体应用加入了太多东西最终变成一大碗意大利面时，它就变成了一场噩梦。改变A点的一些东西就会破坏Z点的某些东西。当你试着修复它时，你很快就会把整个意大利面放在叉子上,难以着手。
有趣的问题是，为什么会这样呢?
是模式的问题吗?另一种模式能解决这个问题吗?
简而言之，答案是否定的。这不是模式的问题，如果不解决原因，新模式就不能解决问题。如果你坚持同样的根本原因，任何新的努力也都会失败。
▌你真的觉得在同一个团队的另一种模式下，你就会成功吗?
人类是复杂的。团队是一个复杂的有机体。开发团队也不例外。
那么，为什么会这样呢?
这不是一个单一的原因，它是多个原因的综合。
这是我曾经遇到过的最大的几点相同原因。
缺乏经验的开发者
可能发生的最糟糕的事情之一是，一群年轻的开发人员正在开发它，却没有人指导他们。缺乏经验是典型的，就其本身而言并不坏。但如果整个团队都缺乏经验，这意味着他们都在学习如何构建这个项目。他们会犯很多很多很多的错误。这在学习过程中是很正常的，但对项目来说却是一场噩梦。我看到的结果通常是错过了最后期限和不可维护的代码库。更不用提客户从来就没高兴过。
一组独行侠
你的团队中有几个开发者知道他们在做什么。这个项目被拆分开，每个人都可以用最少的接口或重叠得到它的开发部分。现在，开发人员按照自己的风格进行编码和工作，好或坏都不重要。他们所看到的只是他们所关心的那一小块。
我现在过度简化了这个问题，因为工作中的动态性非常复杂，独行侠们各自工作、互不关心会带来很多问题。结果是相同逻辑的多个实现，这些逻辑出现在不属于它的地方，接口被破坏(它们从未像前面定义的那样)，抱怨和咆哮持续发生，谁的失误导致了错误，谁又应该修复它呢？
不理解或不关心复杂性
我在我的时事通讯上写过很多次这种情况。复杂性无处不在，作为开发人员，你需要处理大量的复杂性。这一技能甚至比了解你所选择的语言的语法更为重要。
在进行更改或实现新特性之前，请考虑更改会影响什么。这意味着什么?数据流向何处?把我的顺序逻辑放到PersonController（人称控制器）中有意义吗?如果我使用那个方法/服务/X会有什么后果? < -这一点经常被忽略。寻找数据加载，它可能有副作用，等等。
在项目中测试新的语言、框架和模式
学习是伟大的，也是有趣的。但在一个期限很紧的真实项目中却不是这样，团队中也没有人曾经使用过这个新的技术堆栈。哇偶，这个框架看起来不错，我要用它来做下一个客户端项目。
不要!
客户端或关键任务项目不是玩弄新技术的地方。团队应该使用他们了解的经过验证的技术。如果一项新技术真的能帮上忙，那就告诉所有相关人员这是一项新技术，肯定会有错误产生。
我将很快实现它
它甚至与测试无关。“我做得很快”方法的普遍问题是开发人员会忽略他这么做的后果。他不会想太多，只是想尽快把事情处理好。就像在一个中央服务中加载额外的数据，这在他的个人情况下是必需的，他可以快速实现。该死，他只是忽略了这是中央服务器故意忽略的，他的改变破坏了另一部分的性能。
嘿，作为开发人员，你的工作就是保持代码可维护性。唯一的例外是一次性软件。
开发人员编写代码而不是业务人员
如果你听到开发人员开始骂骂咧咧，那么他们肯定是又在抱怨业务人员、项目经理或其他他们认为应该为软件如此糟糕负全责的人。他们从来不会自我反省，总是一味地指责别人。
但是要知道，项目经理并没有编写代码。是你作为一个开发者编写的。所以，你的工作就是把它做好。项目经理没有添加意大利面条式的代码。不，是开发人员干的。
是啊，有时候你没有时间，却需要完成它，那就应该这样：你还是要写好代码。时间是一种约束，要充分利用它，不要总抱怨别人。
无视规则，做事马虎，错误的偷懒
你的团队中有规则，从代码格式化规则到处理更改请求等等。然而，总会有一群开发者直接忽略它们。
在一个团队中，代码格式化规则必须在代码评审中检查。然而，相同的开发人员总是错误地格式化代码。如果一条规则很愚蠢，那就改变它。
草率和错误的偷懒与“我要快点完成它”的话语总是分不开的。同样的结果，不同的原因。
对一切说“是”
如果业务人员说“跳”，许多开发者会问“跳多高?”或者直接去做。对需求或工作负载也是如此。
如果需求是一坨翔，有逻辑缺陷，缺失了某些方面，或者根本没有意义，那就和业务人员谈谈。但是不要用开发人员的语言和他们胡言乱语，用他们的语言去谈论问题。
对工作负载也是一样。不要因为某个项目经理告诉你需要完成某项任务，就一时兴起改变任务。一个团队处理多个项目，项目经理各不相同,这样的事情早已是臭名昭著。当团队中有“是的，先生”这种类型的开发人员时，情况尤其糟糕。其结果是给那些倾向于快速和草率工作的开发人员带来了额外的压力。从而导致糟糕的代码。
错误的决定
勇于做出错误的决定，而不是袖手旁观，夸大或否认它。
最近的一个例子更清楚地说明了这一点。以开发团队为例，他们从零开始开发了一个新应用程序。他们选择了文档存储，但是用关系的方式对域名对象建模。现在增加X特性和迭代之后，性能下降了……但是，没有人承认架构决策是错误的，而任何人又都在抱怨它——甚至是开发者。糟糕的单体应用。
是的，他们确实做了一个错误的决定，在这个特殊的案例中，它是与“客户项目上的新技术”相结合的。
结束语
在我作为开发人员的几十年里，我看到了许多这样的原因和后果。我自己做过很多，我可以告诉你一件事。如果你不改变自己，你会再犯同样的错误。导致同样的问题。无论是构建单体应用还是微服务。
不是技术的问题，而是开发者。
相关链接：
[1]——https://codeboje.de/do-not-use-microservices/
英文原文：https://codeboje.de/developers-problem-not-monoliths/译者：浣熊君( ･᷄৺･᷅ )
閱讀更多 Python部落 的文章
