blocks|key|225243|text|我通常不把代码放在onclick事件后面的原因是因为我经常复制代码，并希望所有这些类型的onclick事件都调用相同的例程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|225244|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The reason I don't usually put the code behind the onclick event is because I'm often duplicating the code, and want all of those type of onclick events to call the same routine.

blocks|key|1524705|text|至少在这些方面，你不会成功地向非技术人员解释这一点。这是一个太技术性的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1524706|如果你稍微概括一下，也许试着解释一些类似于关注的东西(不是用这些术语)，你可能会更幸运一点。|1524707|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

At least in those terms, you're not going to have any success explaining this to a non-technical person. It's too technical of a point.

If you generalize a little bit and perhaps try to explain something like sepeartion of concerns (not in those terms), you might have a little bit more luck

blocks|key|1524730|text|为什么非技术人员需要知道这一点？因为“代码风格”实际上是一个技术问题，如果不解释它背后的一些技术细节，你将无法解释它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1524731|这可能是我能想到的最简单的解释(但这并不包括它是坏习惯的所有原因，只是我认为最常见的原因)：|1524732|在编写软件时，您要努力使其尽可能可维护，这意味着能够快速调整应用程序以适应不断变化的用户/客户端/管理需求。onClick事件背后的代码会随着图形用户界面需求的变化而变化，业务逻辑代码也会随着业务需求的变化而变化。通过使一个独立于另一个，当这两件事中的任何一件发生变化时，需要做的工作将会更少。此外，在更新业务逻辑时，您不需要担心它如何绑定到GUI，在更新GUI时，您也不需要担心业务逻辑实际是如何工作的。|1524733|另一个主要原因是可重用性。带有所有按钮的GUI实际上只是底层数据的“视图”/该数据的界面。您可能有多种方法来访问/更改相同的信息，复制业务逻辑将是多余的。如果业务逻辑发生变化，这也会增加复杂性，因为您必须在多个地方对其进行更改。|1524734|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Why does a non-technical person need to know this? Since 'code style' really is a technical matter, you won't be able to explain it without explaining some of the technicalities behind it.

Probably the simplest explanation I can think of (but this does not cover all the reasons that it is bad-practice, just what I believe is the most common reason):

When writing software you strive to make it as maintainable as possible, this means being able to quickly adjust the application to changing user/client/management requirements. The code behind an onClick event will change whenever the GUI requirements change, the business logic code will change whenever the business requirements change. By making one independent of the other, there will be less work to do when either of these things change. Furthermore, when updating the business logic, you will not need to worry about how it ties into the GUI, and when updating the GUI you will not need to worry about how the business logic actually works.

The other main reason is re-usability. The GUI with all the buttons is really just a 'view' of the underlying data/an interface to that data. You may have several ways of accessing/changing the same information, and it would be redundant to replicate the business logic. This would also add complexity if the business logic changes, since you would have to change it in multiple places.

blocks|key|225311|text|因为你不会把门铃直接连接到释放蜂鸣器上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|225312|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Because you would not connect the doorbell directly to the release buzzer.

blocks|key|225325|text|有图片和故事:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|225326|不是太油嘴滑舌，而是在白板上构建一个场景，其中只有一项简单的业务功能(更改用户密码)。用图形说明它看起来是什么样子。现在展开它，以便2个表单需要更改用户密码(管理员和用户)双代码！解释DRY。更改密码复杂性规则，现在我们需要双重修复。重构这些框以将代码移动到同一项目中的公共区域。|225327|现在，在另一个应用程序需要做同样的事情时，再次扩展它。现在类库更好了。坦率地谈论复杂性的增加与可维护性和可重用性的对比。|225328|冲洗并重复使用，直到它吸收为止。|225329|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

With pictures and stories :) 

Not to be too glib, but build a scenario on a white board where there is a simple piece of business functionality (change a user password). Illustrate graphically what it looks like. Now expand it so that 2 forms need to change the users password (admin and user) Double code! Explain DRY. Change the password complexity rules and now we need a double fix. Refactor the boxes to move the code to a common area in the same project. 

Now expand it again where another app needs to do the same thing. Now a class library is better. Talk honestly about the increase in complexity vs the maintainability and resuse.

Rinse and repeat until it sinks in.

blocks|key|1526901|text|这实际上是在说分离业务层(如何处理事物)和表示层(如何显示事物)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1526902|改变的速度和改变两者的原因通常是非常不同的。您希望具有足够的灵活性来更改它们，以尽可能轻松地响应不断变化的业务需求，以一种降低(回归)风险的方式。|1526903|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

This is really speaking to separating business layer (how things are processed) and presentation layer (how things are displayed). 

The rate of change and the reasons for changing the two are generally very different. You want to be flexible enough to change them, in response to changing business needs as easily as possible, in a manner that reduces risk (of regressions).

blocks|key|4539592|text|我是这样解释的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4539593|在onlclick事件背后编写代码和编写分层或分层的应用程序之间的区别，就像中古城镇和现代城市之间的区别。|offset|length|style|BOLD|4539594|在的中世纪小镇，每个人都在耕田，每个人都缝制自己的衣服，建造自己的房子，并尽其所能地教育自己的孩子，没有人真正擅长做好一项任务，他们必须完成生存所需的所有任务。这就是在onclick事件后面编写代码的样子，代码必须做所有的事情，处理UI交互，做业务验证，处理数据库访问，这对每个事件都是重复的。|4539595|在的现代化城市，有农民在更大的范围内从事农业并专门从事农业，有裁缝可以为每个人缝制更好的衣服，因为有更多的经验和专业化，有建造者，有老师在学校教孩子们，他们可以做得更好，因为他们有更多的时间做。这就是编写分层应用程序的样子，UI层只负责处理用户请求和更新用户界面，因此更容易更改、替换或扩展，没有额外的代码负担；业务层负责业务逻辑，并且所有逻辑都是集中的、可重用的；业务逻辑代码更紧凑和干净；数据访问层处理数据库交互，并专门处理可能与多种类型的数据库进行交互的操作。|4539596|在onclick事件后面编写代码是一种基本的编程风格，它不是最有效的风格，从长远来看也不会产生最好的结果，尽管结果通常是可以接受的(应用程序可以工作)，但它可以更好地工作，更容易维护和扩展，并通过使用采用良好编码实践的适当分层设计来保持更一致(关于ui、交互、错误报告、工作流程等)。|4539597|entityMap^0|0|12|4|17|4|0|1|6|0|1|6|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@$D|R|E|S|F|G]|$D|T|E|U|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@$D|W|E|X|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|O|$]]

This is how I would explain it:

The difference between writing code behind onlclick events and writing applications that are tiered or layered, is like the difference between a medieval town and a modern city.

In a medieval town, everyone plows it's field, everyone sews his clothes, builds his house and educates his children to the best of his abilities, no one is really specialized to do a task well, they have to do all the tasks necessary for survival. 
This is what writing code behind onclick events is like, the code has to do everything, handle UI interactions, do business validations, handle database access, and this repeats for every event.

In a modern city there are farmers that practice agriculture at a larger scale and specialize in it, there are tailors that can sew better clothing for everyone because of greater experience and specialization, there are builders, there are teachers that teach children in schools and can do a better job at it because they have more time to do it. This is what writing a tiered application looks like, the UI tier is responsible for handling user requests and updating the user interface only and therefore is more easy to change replace or extend by having no extra code burden, the business tier is responsible for business logic and all the logic is centralized, reusable, the business logic code is more compact and clean, the data access tier handles database interaction and specializes in doing it possibly interacting with more than one type of database.

Writing code behind onclick events is a rudimentary style of programming that is not the most efficient style and doesn't yield the best possible results in the long run, although the results are more than often acceptable (the application works), it can work allot better, be easier to maintain and extend and be more consistent (regarding ui, interactions, error reporting, workflow, etc) by using a proper tiered design that employs good coding practices.

blocks|key|1323134|text|我必须像其他人一样问--为什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1323135|对于非技术人员来说，重要的是当单击按钮时，所需的行为会发生。从他们的角度来看，您是在编写click事件的代码。|1323136|但如果这真的是一个问题，那就关注那些非技术人员所关心的问题--+BUGS。他们不关心让代码变得优雅，或者拥有漂亮的设计模式，等等。这一切都是关于事情是否正常工作。|1323137|像这样说：|1323138|任何必须编程到系统中的业务规则可能需要在许多不同的地方重用，如报告、按钮、搜索等。我甚至可能需要在网页和软件包中使用相同的逻辑。您可能认为现在只需要在这里使用它，但是经验已经证明，在大多数情况下，业务规则必须在多个地方使用，并且最好假设它总是会被重用。|1323139|如果我将业务规则直接放在按钮后面，那么重用该逻辑即使不是不可能，也会很困难。然后，我必须将相同的逻辑多次放入系统中，这会带来更多的错误机会。我可以在一个地方修复逻辑，但它仍然会在其他地方被破坏。|1323140|相反，我将业务规则放在一个中心位置，这样无论我在哪里需要它们，我都可以重用它们。那么，一个地方的bug修复就是在所有地方修复的bug，软件将会有更少的问题。|1323141|一个类比就是网页上的链接。我们只需创建一个链接，而不是将一个网页中的所有文本复制到另一个网页中。那么我们总是有最新的信息。|1323142|只需记住-非技术人员是务实的-这一切都是关于他们可以立即看到和使用的东西。|1323143|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|10|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|11|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|S|$]]

I have to ask like anyone else - why? 

What matters to a nontechnical person is that the desired behavior is happening when the button is clicked. From their point of view, you are coding into the click event.

But if it really is an issue, focus on what the nontechnical people care about - BUGS. They don't care about making code elegant or having nice design patterns, etc. It's all about whether or not things work.

Say something like this:

Any business rules that have to be programmed into the system may need to be reused in many different places, like a report, a button, a search, etc. I might even need to use that same logic in a web page as well as the software package. You might think it's only going to be needed here right now, but experience has proven that most of the time business rules have to be used in more than one place and it is best to assume it will always be reused.

If I put the business rules behind the button directly, reuse of that logic can be difficult if not impossible. Then I have to put the same logic in the system more than once, which introduces more opportunities for mistakes. I could fix the logic in one place and it would still be broken somewhere else.

Instead, I take the business rules and put them in a central location so no matter where I need them I can reuse them. Then, a bug fix in one place is a bug fixed in all places, and the software will have fewer problems.

An analogy would be links on a webpage. Instead of copying all the text from a webpage into another webpage, we just make a link. Then we always have the most up-to-date information.

Just remember - nontechy people are pragmatic - it's all about what they can immediately see and use.

blocks|key|1526974|text|告诉你的经理关于technical+debt+(和also+here)的事情|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1526975|我认为你应该说服你的经理们相信一般原则，重构或偿还技术债务是有必要的。就像厨师必须偶尔清理厨房才能做出美味的食物一样，在实现新功能之前，您必须偶尔清理代码。|1526976|如果你的经理不同意这一普遍原则，那么你就有大麻烦了。如果他们确实同意，那么我认为他们不应该对你进行微观管理，而应该相信你在哪种重构具有最高优先级方面的技术专业知识。|1526977|entityMap|0|LINK|mutability|MUTABLE|url|http://www.c2.com/cgi/wiki?TechnicalDebt|1|http://www.codinghorror.com/blog/archives/001230.html^0|8|E|0|P|9|1|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]|$A|V|B|W|1|X]]|C|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

Tell your managers about <a href="http://www.c2.com/cgi/wiki?TechnicalDebt" rel="nofollow noreferrer">technical debt</a> (and <a href="http://www.codinghorror.com/blog/archives/001230.html" rel="nofollow noreferrer">also here</a>)

I think you should convince your managers of the general principle, that refactoring or paying down the technical debt, is necessary once in a while. Just like a cook has to clean its kitchen once in a while in order to make good food, you have to clean up your code once in a while before you can implement new features.

If your managers don't agree with this general principle, then you're in big trouble. If they do agree, then I think they should not micromanage you but trust your technical expertise on what kind of refactoring has highest priority.

blocks|key|225451|text|经济学|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|225452|典型软件应用程序总生命周期成本的3/4是维护成本。通过省去前面的1/4部分，你就加载了3/4。|225453|足够少的开发，3/4变成了19/20。如果做得好，你的10万美元的项目在其生命周期中会花费40万美元。提前跳过TLC，你现在可以节省2万美元，但你的项目在其生命周期中花费了200万美元。|225454|如果首席财务官在会议中，你可以写下这样的评论：|225455|225456|：不过别担心，额外的150万美元会从别人的预算中拿出来，所以不会影响你的奖金。|blockquote|225457|225458|225459|留下一团糟的另一个隐藏成本是，位腐烂将极大地减慢应用程序的更改，并增加未检测到的bug的风险，直到它们在月底关闭时才会被注意到。|225460|entityMap^0|0|3|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|10|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|11|8|@]|D|@]|E|$]]|$1|M|3|N|5|O|7|12|8|@]|D|@]|E|$]]|$1|P|3|-4|5|6|7|13|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|14|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|15|8|@]|D|@]|E|$]]|$1|T|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|U|$]]

Economics

3/4 of the total life-cycle costs of a typical software application are maintenance. By skimping on the 1/4 part up front you load the 3/4. 

Skimp of the development enough and the 3/4 becomes 19/20. Do it properly and your $100,000 project costs $400,000 over its lifetime. Skip on TLC up front and you save $20,000 now but your project costs $2 million over its life time. 

If the CFO is in the meeting you could drop a comment along the lines of:

<blockquote>
 'But don't worry, the extra $1.5m will
 come out of someone else's budget so
 it won't affect your bonus.'
</blockquote>

The other hidden cost of leaving a mess lying around is the bit rot will massively slow down changes on the application and increase the risk of undetected bugs that nobody notices until they're right in the middle of a month-end close.

blocks|key|4539799|text|ConcernedOfTunbridgeW很好地解释了管理层想要听到的内容。要点是，如果它现在出现问题，可能是因为代码逻辑的冗余。你想做的重构将会消除这一点。从长远来看，它的成本会稍高一些，但从长远来看，它将节省维护费用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4539800|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

ConcernedOfTunbridgeW explains it well in terms of what management wants to hear. Main point is that if it has problems right now, it probably is because of redundancy of code logic. The refactoring you want to do will eliminate that. It will cost a little more in the long run, but it will save money in maintenance long-term.

How would you explain to a non-technical person why writing code (business-logic) behind the onclick event is a bad practice and leads to unmaintainable code?

Edited:
I have to explain management why some refactoring is needed, also why some code is not passing code review. To some people in management this only means more funding. I came up with this example because at some point of a discussion somebody said: ..put the code behind the button and forget all that model-view-controller hype, you will finish your task faster.

Unmaintainable code behind to the non-technical

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

您将如何向非技术人员解释为什么在onclick事件后面编写代码(业务逻辑)是一种糟糕的做法，并导致无法维护的代码？编辑:我必须解释为什么需要一些重构的管理，也为什么一些代码没有通过代码审查。对于一些管理人员来说，这只意味着更多的资金。我之所以想出这个例子，是因为在一次讨论中，有人说：..put按钮背后的代码，忘记所有模...

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

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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