您将如何向非技术人员解释为什么在 onclick 事件后面编写代码（业务逻辑）是一种不好的做法并导致代码无法维护？
已编辑：我必须向管理层解释为什么需要进行一些重构，以及为什么有些代码没有通过代码审查。对于一些管理人员来说，这只意味着更多的资金。我想出了这个例子是因为在讨论的某个时候有人说：..把代码放在按钮后面，忘记所有模型-视图-控制器的炒作，你会更快地完成你的任务。
问问题
906 次
11 回答
20
这就是我要解释的方式：
编写 onlclick 事件背后的代码和编写分层或分层的应用程序之间的区别，就像中世纪城镇和现代城市之间的区别。
在一个中世纪的小镇里，每个人都在耕种田地，每个人都在缝衣服，盖房子，并尽其所能教育孩子，没有人真正专精于完成一项任务，他们必须完成生存所必需的所有任务. 这就是在 onclick 事件背后编写代码的过程，代码必须做所有事情，处理 UI 交互，进行业务验证，处理数据库访问，并且对于每个事件都重复。
在现代化的城市有从事农业规模较大并专攻农业的农民，有经验丰富和专业化，可以为每个人缝制更好衣服的裁缝，有建设者，有在学校教孩子的老师，可以做得更好因为他们有更多的时间去做。这就是编写分层应用程序的样子，UI 层只负责处理用户请求和更新用户界面，因此更容易更改替换或扩展，没有额外的代码负担，业务层负责业务逻辑并且所有的逻辑都是集中的，可重用的，业务逻辑代码更加紧凑和干净，数据访问层处理数据库交互并专门处理可能与一种以上类型的数据库交互。
在 onclick 事件后面编写代码是一种基本的编程风格，它不是最有效的风格，从长远来看也不会产生最好的结果，尽管结果通常可以接受（应用程序工作），但它可以工作分配通过使用采用良好编码实践的适当分层设计，更好、更容易维护和扩展并且更加一致（关于 ui、交互、错误报告、工作流等）。
于 2009-08-19T00:12:16.140 回答
14
因为您不会将门铃直接连接到释放蜂鸣器。
于 2009-08-18T23:49:49.633 回答
3
为什么非技术人员需要知道这一点？由于“代码风格”确实是一个技术问题，如果不解释它背后的一些技术细节，你将无法解释它。
可能是我能想到的最简单的解释（但这并没有涵盖所有错误做法的原因，只是我认为最常见的原因）：
在编写软件时，您努力使其尽可能可维护，这意味着能够快速调整应用程序以适应不断变化的用户/客户/管理要求。每当 GUI 需求发生变化时，onClick 事件背后的代码就会发生变化，而每当业务需求发生变化时，业务逻辑代码就会发生变化。通过使一个独立于另一个，当这些事情中的任何一个发生变化时，要做的工作就会减少。此外，在更新业务逻辑时，您无需担心它与 GUI 的关系，而在更新 GUI 时，您无需担心业务逻辑的实际工作方式。
另一个主要原因是可重用性。带有所有按钮的 GUI 实际上只是底层数据的“视图”/该数据的接口。您可能有多种访问/更改相同信息的方法，复制业务逻辑将是多余的。如果业务逻辑发生变化，这也会增加复杂性，因为您必须在多个地方进行更改。
于 2009-08-18T23:46:34.850 回答
3
有图片和故事:)
不要太圆滑，而是在白板上构建一个场景，其中有一个简单的业务功能（更改用户密码）。用图形说明它的样子。现在将其展开，以便 2 个表单需要更改用户密码（管理员和用户）双码！解释干燥。更改密码复杂性规则，现在我们需要双重修复。重构这些框以将代码移动到同一项目中的公共区域。
现在在另一个应用程序需要做同样事情的地方再次展开它。现在类库更好。诚实地谈论复杂性的增加与可维护性和重用性。
冲洗并重复，直到它沉入水中。
于 2009-08-18T23:51:36.290 回答
2
我必须像其他人一样问 - 为什么？
对非技术人员而言，重要的是单击按钮时会发生所需的行为。从他们的角度来看，您正在对点击事件进行编码。
但如果这确实是一个问题，请关注非技术人员关心的问题 - BUGS。他们不关心使代码优雅或具有良好的设计模式等。这完全是关于事情是否有效。
说这样的话：
任何必须编程到系统中的业务规则都可能需要在许多不同的地方重用，例如报告、按钮、搜索等。我什至可能需要在网页中使用相同的逻辑以及软件包。您可能认为现在只需要它，但经验证明，大多数时候业务规则必须在不止一个地方使用，最好假设它总是会被重用。
如果我将业务规则直接放在按钮后面，即使不是不可能，重用该逻辑也会很困难。然后我必须在系统中多次放入相同的逻辑，这会引入更多出错的机会。我可以在一个地方修复逻辑，但它仍然会在其他地方被破坏。
相反，我将业务规则放在一个中心位置，这样无论我在哪里需要它们，我都可以重复使用它们。那么，一个地方的bug修复就是一个地方都修复的bug，软件的问题就会少一些。
一个类比是网页上的链接。我们无需将网页中的所有文本复制到另一个网页中，而是创建一个链接。然后我们总是有最新的信息。
请记住 - 非技术人员是务实的 - 这完全取决于他们可以立即看到和使用的东西。
于 2009-08-19T02:05:29.147 回答
2
经济学
典型软件应用程序总生命周期成本的 3/4 是维护。通过跳过前面的 1/4 部分，您可以加载 3/4。
发展足够少，3/4变成19/20。如果做得好，您 100,000 美元的项目在其整个生命周期内将花费 400,000 美元。预先跳过 TLC，您现在可以节省 20,000 美元，但您的项目在其生命周期内需要花费 200 万美元。
如果 CFO 参加会议，您可以发表以下评论：
“但别担心，额外的 150 万美元将来自其他人的预算，因此不会影响你的奖金。”
留下乱七八糟的另一个隐藏成本是位腐烂会大大减慢应用程序的更改速度，并增加未检测到的错误的风险，直到他们在月底关闭的中间才注意到。
于 2009-08-19T13:10:10.303 回答
1
ConcernedOfTunbridgeW 很好地解释了管理层希望听到的内容。重点是，如果它现在有问题，可能是因为代码逻辑的冗余。您想要进行的重构将消除这种情况。从长远来看，它会花费更多，但从长远来看，它会节省维护费用。
于 2009-08-19T13:39:12.123 回答
0
我通常不将代码放在 onclick 事件后面的原因是因为我经常复制代码，并且希望所有这些类型的 onclick 事件都调用相同的例程。
于 2009-08-18T23:43:02.733 回答
0
至少在这些方面，您不会成功地向非技术人员解释这一点。这点技术性太强了。
如果您稍微概括一下，也许尝试解释诸如关注点分离之类的东西（不是用这些术语），您可能会更幸运一些
于 2009-08-18T23:43:21.440 回答
0
这实际上是在分离业务层（如何处理事物）和表示层（如何显示事物）。
两者的变化率和变化的原因大体上是大相径庭的。您希望足够灵活地更改它们，以尽可能轻松地以降低风险（回归）的方式响应不断变化的业务需求。
于 2009-08-18T23:55:45.970 回答