问不可维护的代码落后于非技术性的

EN

我是这样解释的：

在onlclick事件背后编写代码和编写分层或分层的应用程序之间的区别，就像中古城镇和现代城市之间的区别。

在的中世纪小镇，每个人都在耕田，每个人都缝制自己的衣服，建造自己的房子，并尽其所能地教育自己的孩子，没有人真正擅长做好一项任务，他们必须完成生存所需的所有任务。这就是在onclick事件后面编写代码的样子，代码必须做所有的事情，处理UI交互，做业务验证，处理数据库访问，这对每个事件都是重复的。

在的现代化城市，有农民在更大的范围内从事农业并专门从事农业，有裁缝可以为每个人缝制更好的衣服，因为有更多的经验和专业化，有建造者，有老师在学校教孩子们，他们可以做得更好，因为他们有更多的时间做。这就是编写分层应用程序的样子，UI层只负责处理用户请求和更新用户界面，因此更容易更改、替换或扩展，没有额外的代码负担；业务层负责业务逻辑，并且所有逻辑都是集中的、可重用的；业务逻辑代码更紧凑和干净；数据访问层处理数据库交互，并专门处理可能与多种类型的数据库进行交互的操作。

在onclick事件后面编写代码是一种基本的编程风格，它不是最有效的风格，从长远来看也不会产生最好的结果，尽管结果通常是可以接受的(应用程序可以工作)，但它可以更好地工作，更容易维护和扩展，并通过使用采用良好编码实践的适当分层设计来保持更一致(关于ui、交互、错误报告、工作流程等)。

因为你不会把门铃直接连接到释放蜂鸣器上。

为什么非技术人员需要知道这一点？因为“代码风格”实际上是一个技术问题，如果不解释它背后的一些技术细节，你将无法解释它。

这可能是我能想到的最简单的解释(但这并不包括它是坏习惯的所有原因，只是我认为最常见的原因)：

在编写软件时，您要努力使其尽可能可维护，这意味着能够快速调整应用程序以适应不断变化的用户/客户端/管理需求。onClick事件背后的代码会随着图形用户界面需求的变化而变化，业务逻辑代码也会随着业务需求的变化而变化。通过使一个独立于另一个，当这两件事中的任何一件发生变化时，需要做的工作将会更少。此外，在更新业务逻辑时，您不需要担心它如何绑定到GUI，在更新GUI时，您也不需要担心业务逻辑实际是如何工作的。

另一个主要原因是可重用性。带有所有按钮的GUI实际上只是底层数据的“视图”/该数据的界面。您可能有多种方法来访问/更改相同的信息，复制业务逻辑将是多余的。如果业务逻辑发生变化，这也会增加复杂性，因为您必须在多个地方对其进行更改。