简单到复杂再回归到简单_简单就是复杂-CSDN博客

简单到复杂再回归到简单

Recently I attended a meeting with multiple stakeholders from the business side. When asked to explain a feature, I started explaining them the details of the feature and its implementation. After the meeting one of my colleagues told me even though I explained it in detail, they will be requesting a follow-up meeting to discuss the same thing and it was true — the next day we had a meeting invite for the same thing as a follow-up. He explained to me that the reason was I had provided them more details than necessary which probably confused them. This incident led me to the principle of Occam’s Razor.

最近，我参加了与业务方面的多个利益相关者的会议。当被要求解释功能时，我开始向他们解释功能的详细信息及其实现。会议结束后，尽管我已经详细解释了，但我的一位同事告诉我，他们将要求召开后续会议以讨论同一件事，这的确是事实–第二天，我们开会邀请跟进。他向我解释说，原因是我向他们提供了不必要的详细信息，这可能使他们感到困惑。这件事使我想到了奥卡姆剃刀的原理。

Quoted from Wikipedia

引自维基百科

Occam’s razor or the law of parsimony is the problem-solving principle that essentially states that “simpler solutions are more likely to be correct than complex ones.” When presented with competing hypotheses to solve a problem, one should select the solution with the fewest assumptions. The idea is attributed to English Franciscan friar William of Ockham (c. 1287–1347), a scholastic philosopher and theologian.

解决问题的原则是奥卡姆(Occam)的剃刀或简约法则，其本质上说“简单的解决方案比复杂的解决方案更可能是正确的”。 当提出竞争性假设来解决问题时，应选择假设最少的解决方案。 这个想法归因于英国方济各会修士威廉·奥卡姆(William of Ockham，约1287-1347年)，是一位学术哲学家和神学家。

We have all heard the famous quote by Sherlock Holmes

我们都听过福尔摩斯的名言

Once you eliminate the impossible, whatever remains, no matter however improbable, must be the truth.

一旦您消除了不可能，那么无论多么不可能的一切，剩下的一切都必须成为事实。

This follows directly from Occam’s Razor. This principle states that given two explanations of a situation, the one in which there is the least number of variables(simpler) however improbable is the most likely explanation. This principle is very helpful and it can be used in a wide variety of situations but it is especially powerful in the hands of software professional.

这直接来自Occam的Razor。该原理指出，给定两种情况的解释，最有可能的解释是变量数量最少(简单)但不太可能的一种解释。该原理非常有用，可以在多种情况下使用，但是在软件专业人员手中特别有用。

There are many areas of Software development which can benefit from this principle. A few of them are:

可以从该原理中受益的软件开发领域很多。其中一些是：

编码 (Coding)

The first and foremost area is coding. As developers, we make hundreds of decisions every day which directly affects the health of the codebase and in turn the business. Few of the mistakes we make include adding unwanted abstractions, designing for the future, making it “extensible”(whatever that means). These code with unwanted additional complexity slowly rots over time and becomes “that” part of the codebase that no one understands and nobody is willing to touch. These are the things we do either knowingly or unknowingly which can put a dent on our codebase health in the long-run.

第一个也是最重要的区域是编码。作为开发人员，我们每天都会做出数百个决策，这些决策直接影响代码库的运行状况，进而影响业务。我们犯的错误很少包括添加不必要的抽象，为未来设计，使其“可扩展”(无论这意味着什么)。这些带有不必要的额外复杂性的代码会随着时间的流逝而缓慢地腐烂，并成为代码库的“那部分”，没人能理解，没人愿意接触。这些都是我们有意或无意地做的事情，从长远来看，这些事情可能会影响我们的代码库运行状况。

To overcome this it would be prudent for us to think in terms of Occam’s Razor. Always do the simplest thing possible at any point in time. Principles like YAGNI and KISS are examples of Occam’s Razor in coding. If you want to combine 3 design patterns to accommodate a feature request you expect in the future, restrain your primal instincts and stick with a single class for now. Using Occam’s razor during the development process would keep the codebase simple and readable and your future peers will really thank you.

为了克服这个问题，我们应该从Occam的Razor角度考虑。始终在任何时间点做最简单的事情。诸如YAGNI和KISS之类的原则是Occam的Razor编码示例。如果您想结合3种设计模式来满足您将来的功能需求，请限制您的原始直觉并暂时坚持使用一个类。在开发过程中使用Occam的剃须刀将使代码库简单易读，您的未来同仁将非常感谢您。

A word of caution here is, this principle should not be used as an excuse to write bad code or take shortcuts. If there is a real need to add complexity, by all means, you should do that. Consider this a framework for you to step back and think for a moment and weigh the cost of your decision in the long run.

这里要提醒您的是，不应将此原则用作编写不良代码或采取捷径的借口。如果确实需要增加复杂性，则应该这样做。考虑一下这个框架，您可以退一步思考一下，从长远来看，权衡您的决策成本。

调试 (Debugging)

Another interesting application of this principle is while debugging. The hard part about debugging is nobody knows the answer especially when you work in a legacy code base with business critical functionalities. Bigger the codebase, more complex the debugging process and thus the Occam’s Razor comes in really handy. All the good software developers I know trace the root cause of a bug by using this principle without even realising it.

此原理的另一个有趣的应用是在调试时。调试的难点是没人知道答案，尤其是当您使用具有业务关键功能的旧代码库时。更大的代码库，更复杂的调试过程，因此Occam的Razor非常方便。我认识的所有优秀软件开发人员都没有使用此原理就跟踪了错误的根本原因。

Let's say there you write a program to display a few stats in the dashboard. You observe that each time the dashboard is updated you get 2x instead of x for a particular stat. What would be your first instinct? Is it a double counting issue or some thread level race condition? I am guessing most of you with go with the former. This is Occam’s Razor in action. You picked the choice which provides the simplest explanation for the issue intuitively.

假设您在这里编写了一个程序来在仪表板上显示一些统计信息。您会观察到，每次更新仪表板时，对于特定的统计信息，您将得到2倍而不是x。你的第一个本能是什么？是重复计算问题还是某种线程级竞争条件？我猜你们中的大多数人都喜欢前者。这是奥卡姆的剃刀。您选择了可以直观地为该问题提供最简单说明的选择。

This is not to say that always the simplest explanation is the right one. Instead, you start from the simplest one and eliminate one by one either by theory or experimentation until you arrive at the actual root cause for the problem. This provides a framework for you to tackle problems methodically.

这并不是说，最简单的解释总是正确的解释。取而代之的是，您从最简单的问题开始，然后通过理论或实验逐一消除问题，直到得出问题的实际根本原因。这为您有条不紊地解决问题提供了一个框架。

通讯 (Communication)

One of the most under-rated functions of a software developer is communication. Be it with peers/ managers/ stakeholders, communication is as important as coding for any developer. As developers, we are the closest to any given problem and it is natural for people to rely on us for understanding the whole picture of a product/feature. This makes what you communicate and how you communicate extremely crucial from a business standpoint.

通信是软件开发人员最被低估的功能之一。无论是与同行/经理/利益相关者一起，对于任何开发人员而言，交流与编码一样重要。作为开发人员，我们最接近任何给定的问题，人们自然而然地依靠我们来了解产品/功能的整体情况。从业务的角度来看，这使您进行的沟通以及沟通方式变得至关重要。

As we are closest to a problem, we will have a lot of technical and domain knowledge around it. But it is extremely important to communicate the right things to the right people. Assume you are in a mail thread with Sr. engineer, PM, Manager, and a Business development executive, you need to provide just the right amount of detail so that the Engineer can get the technical challenges and the others can also understand the complexity technically as well as the business justification. You need to achieve the right amount of balance in the technical/business mixture for the audience to understand and not lose interest. This is where Occam’s razor comes in. You need to provide the least level of detail in the mail and schedule a follow up for the people who need to understand more.

由于我们最接近问题，因此我们将掌握许多技术和领域知识。但是，将正确的事情传达给正确的人非常重要。假设您与高级工程师，项目经理，经理和业务开发主管处于邮件联系中，则需要提供适当数量的详细信息，以便工程师可以解决技术难题，而其他人也可以从技术上理解复杂性以及业务理由。您需要在技术/业务组合中取得适当的平衡，以使听众理解而不失兴趣。这是Occam剃须刀的用处。您需要在邮件中提供最少的详细信息，并为需要更多了解的人员安排后续行动。

Take this as an example “we did a POC on x and we were able to achieve y. Even though we discussed A in the previous mail, we could not achieve A due to the complexities in a library that we were using. There were a lot of assumptions in the threading model in the library and thus it prevented us from achieving A”.

以此为例“我们在x上进行了POC，我们能够实现y。即使我们在上一封邮件中讨论了A，由于使用的库的复杂性，我们也无法实现A。库中的线程模型有很多假设，因此使我们无法实现A”。

Now, what do you think the different stakeholders will understand?

现在，您认为不同的利益相关者会理解什么？

Engineer — Yes I get the issue.
工程师-是的，我有问题。
PM- So basically we cant achieve A. And what is a threading model?
PM-所以基本上我们无法达到A。什么是线程模型？
Manager — Did he try enough to achieve A?
经理-他是否做了足够的努力来取得A？

Instead, if we write “we did a POC on x and were able to achieve y. A was targetted but not achieved. I’ll schedule a meeting to demo the POC and go into details on the blocker for A.” After that, you have all the time in the world to explain in detail the blockers for the right audience and achieve a consensus.

相反，如果我们写“我们在x上进行POC，并且能够达到y。目标A但未实现。我将安排一次会议来演示POC，并详细介绍A的阻止程序。” 之后，您将无时无刻不在为合适的受众详细解释阻碍因素并达成共识。

Now, what is the thought process after the demo?

现在，演示之后的思考过程是什么？

Engineer — Makes sense.
工程师-很有道理。
PM — The POC is good for now. I guess we can drop A for now and proceed without it.
PM — POC目前很好。我想我们现在可以删除A，然后继续删除它。
Manager — He has done an in-depth analysis and knows what he is doing.
经理-他进行了深入的分析，知道自己在做什么。

结论 (Conclusion)

Occam’s Razor can be employed in a wide variety of scenarios and these are just a few examples. Developers use this principle intuitively without knowing it. But knowing it and using it deliberately in various situations will greatly improve you as a software developer. If you can think of any other area of Software where this principle is being used feel free to leave your thoughts in comments.

Occam的Razor可以在多种情况下使用，这些只是几个示例。开发人员在不了解的情况下直观地使用了这一原理。但是了解它并在各种情况下有意使用它会极大地提高您作为软件开发人员的能力。如果您可以想到使用此原理的软件的其他领域，请随时在注释中留下您的想法。

If you liked this article, feel free to reach out to me at https://kaizencoder.com/contact.

如果您喜欢这篇文章，请随时通过https://kaizencoder.com/contact与我联系。