非技术性背后无法维护的代码

Question

您如何向非技术人员解释为什么在onclick事件背后编写代码（业务逻辑）是一种不好的做法并导致无法维护的代码？

编辑： 我必须解释管理为什么需要进行一些重构，以及为什么有些代码没有通过代码审查。对管理层中的一些人来说，这意味着更多的资金。我想出了这个例子，因为在讨论的某个时刻有人说：..输入按钮背后的代码并忘记所有模型 - 视图 - 控制器炒作，你将更快地完成你的任务。

Answer 1

这是我解释它的方式：

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

在一个中世纪城镇，每个人都在耕地，每个人都缝制衣服，建造自己的房子，并尽最大努力教育他的孩子，没有人真正专门做好任务，他们必须完成生存所需的所有任务。 这就是在onclick事件背后编写代码的代码，代码必须做所有事情，处理UI交互，进行业务验证，处理数据库访问，并为每个事件重复。

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

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

Answer 2

因为您不会将门铃直接连接到释放蜂鸣器。

Answer 3

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

可能是我能想到的最简单的解释（但这并不包括所有不良做法的原因，我认为这是最常见的原因）：

在编写软件时，您努力使其尽可能易于维护，这意味着能够快速调整应用程序以适应不断变化的用户/客户端/管理要求。每当GUI需求发生变化时，onClick事件背后的代码都会发生变化，业务逻辑代码将随业务需求的变化而变化。通过使一个独立于另一个，当这些事情中的任何一个改变时，将会有更少的工作要做。此外，在更新业务逻辑时，您无需担心它与GUI的关系，并且在更新GUI时，您无需担心业务逻辑如何实际工作。

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

Answer 4

带图片和故事:)

不要过于狡猾，但要在白板上构建一个场景，其中有一个简单的业务功能（更改用户密码）。以图形方式说明它的外观。现在扩展它以便2个表单需要更改用户密码（admin和user）双重代码！解释干。更改密码复杂性规则，现在我们需要双重修复。重构框以将代码移动到同一项目中的公共区域。

现在再次展开它，另一个应用程序需要做同样的事情。现在一个类库更好。诚实地谈论复杂性与可维护性和重用性的增加。

冲洗并重复直至其沉入。

Answer 5

我必须像其他人一样问 - 为什么？

对于非技术人员来说，重要的是单击按钮时会发生所需的行为。从他们的角度来看，您正在编写点击事件。

但如果真的是一个问题，请关注非技术人员关心的问题 - BUGS。他们不关心使代码优雅或具有漂亮的设计模式等。这都是关于事物是否有效。

说出这样的话：

任何必须编程到系统中的业务规则可能需要在许多不同的地方重用，例如报表，按钮，搜索等。我甚至可能需要在网页中使用相同的逻辑。以及软件包。您可能认为现在只需要它，但经验证明，大多数时候业务规则必须在多个地方使用，最好假设它总是被重用。

如果我直接将业务规则放在按钮后面，那么重用该逻辑即使不是不可能也是困难的。然后我不得不在系统中多次使用相同的逻辑，这会带来更多的错误机会。我可以在一个地方修复逻辑，但它仍会在其他地方被破坏。

相反，我采用业务规则并将它们放在一个中心位置，所以无论我需要什么，我都可以重用它们。然后，在一个地方修复错误是在所有地方修复的错误，并且软件将有更少的问题。

类比是网页上的链接。我们只是建立一个链接，而不是将所有文本从网页复制到另一个网页。然后我们总是拥有最新的信息。

请记住 - 非技术人员务实 - 这完全取决于他们能够立即看到和使用的内容。

Answer 6

告诉您的经理technical debt（和also here）

我认为你应该让管理者相信一般原则，即重构或偿还技术债务，这在一段时间内是必要的。就像厨师必须偶尔清理厨房才能制作美食一样，你必须在一段时间内清理你的代码才能实现新功能。

如果你的经理不同意这个一般原则，那你就麻烦大了。如果他们确实同意，那么我认为他们不应该对您进行微观管理，而是要相信您的技术专长，以确定哪种重构具有最高优先级。

Answer 7

<强>经济

典型软件应用程序的总生命周期成本的3/4是维护。通过在前面1/4部分上吝啬，你可以加载3/4。

开发的滑雪足够3/4成为19/20。做得恰当，你的10万美元项目在其生命周期内的成本为400,000美元。立即跳过TLC，现在可节省20,000美元，但您的项目在其生命周期内的成本为200万美元。

如果首席财务官在会议中，你可以放弃评论：

  

'但不要担心，额外的150万美元会   从别人的预算出来   它不会影响你的奖金。'

留下乱七八糟的其他隐藏成本是腐烂会大大减慢应用程序的变化，并增加未检测到的错误的风险，没有人注意到，直到他们正好在月末结束时。

Answer 8

ConcernedOfTunbridgeW在管理层希望听到的内容方面做得很好。重点是，如果它现在有问题，可能是因为代码逻辑的冗余。你想要做的重构将消除这种情况。从长远来看，它会花费更多，但它可以长期节省维护费用。

Answer 9

我通常不会将代码置于onclick事件背后的原因是因为我经常复制代码，并希望所有这些类型的onclick事件都调用相同的例程。

Answer 10

至少在这些方面，你不会有任何成功向非技术人员解释这一点。这太技术了。

如果你稍微概括一下并且可能试图解释一些关注点（不是那些术语），你可能会有更多的运气

Answer 11

这实际上是指分离业务层（如何处理事物）和表示层（如何显示事物）。

变化率和改变两者的原因通常非常不同。您希望能够灵活地进行更改，以尽可能轻松地响应不断变化的业务需求，从而降低风险（回归）。