Accompany you grew up "mantra": Simple is better than complicated?

The full text 2900 words, when learning is expected to grow 9 Fenzhong

Figure source: Unsplash

 

Simply Success is far better than complex failed.

 

This sentence is like a curse, in all walks of life, all kinds of scenes seem to have been verified.

 

As early as 1996, Buffett said: "Most investors, including institutional investors and individual investors, sooner or later will find the best method of investing in stocks is to buy low management fee index funds."

 

Numerous investors personal experience verifies the correctness Buffett suggested.

 

"Investment approach is often as simple as possible effects."

 

"Simple is better than complex can often be."

 

In the innocuous debate on the code review, I suddenly found that in all decisions relating to coding, I have only a few basic ideas. One of them is: Simple is better than complex. After about three seconds, I realized that this is neither a well-known mantra, nor is it a complete explanation can quickly spell. This is a growing belief with you. But how do I explain this belief does to my teammates?

 

For me, "Simple is better than complex" is a pragmatic answer to a different question, like a simple Occam's razor. It gives me two advantages:

 

· It allows me to break down a problem into parts need to be addressed now and may postpone part.

· It gives me confidence in my decision, because it was supported by many other theorems, principles, rules and guidelines.

 

 

Then the "simple is better than complex" in the end what does it mean?

 

Figure source: Unsplash

 

The guidelines want you to choose a more simple solution. You should always ask yourself: Can you simplify your code but still get the same results? You can achieve the same goal right at the same time simplify the design?

 

It may be little things, such as: Do you overuse a powerful language constructs? Use try-except statement is good for you, or do simple if statement is more suitable for your process?

 

Or it may be a bigger problem, for example: You really should support 20 different scenes it? Or you can provide the three most common scenarios to obtain a comparable user experience?

 

The guidelines are alert to guide you through the complexities and requires reduced its good reason.

 

 

How the complexity of the impact of a project

 

在一个项目的开始,没有代码,没有规范。未来,或者是我们必须创造的东西是令人畏惧的,但过去,也就是我们创造初的东西是简单的。到目前为止,我们还没有创造出任何东西,这很简单,任何人都可以做到。

 

现在我们需要创造一些东西。我们不能一下子创造出所有的东西,我们应该从什么开始呢?

图源:Unsplash

 

如果我们相信欣欣向荣的创业场景,务实的做法是从一个MVP开始。它代表最小可行产品,一个包含足够有用特性的产品,它成功地完成了其主要任务。这个阶段的目标是保持开发项目的低成本,直到我们有证据证明我们正在开发正确的特性。

 

MVP原则就是“简单比复杂好”的不同说法。应该使用最简单的解决方案来解决您的问题。不要增加复杂性,例如,成本,直到你有充分的理由。

 

类似的概念也出现在《帕雷托法则》中,它也被称为二八法则或少数人的法则。它指出,对于许多事件,大约80% 的影响来自20% 的原因,也就是说,80% 的故障(bug)报告是由20% 的故障引起的; 在80% 的时间中,只有20% 的特性被使用。

 

帕雷托法则起源于统计学和经济学,但已经应用于广泛的领域中。它很好地支持了我们的简单胜于复杂的概念。如果80%的客户只使用了20%的可能工作流,那么为什么还要费力去支持我们软件所能想到的每一个工作流呢?

 

因此,要决定哪些特性应该首先开发,我们必须挑剔。我们所建立的一切,我们也必须在一段时间内能及时提供支持。我们添加到软件中的任何东西都会产生维护成本,并且会影响我们如何以及以何种成本构建其他完全不相关的新东西。

 

 

提高复杂性的好理由是什么?

 

从理论上讲,上述内容似乎都是合乎逻辑的。但它也非常模糊。没有任何东西像复杂性或简单性的实际定义一样,没有任何东西可以作为我们的经验法则来判断哪个特性值得花费一个月的努力,哪个特性值得花费六个月的时间,哪个特性只值得投入一天即可。这就是模糊产生和争吵变得激烈的地方。

 

开发人员和管理人员不关心这个指导方针的真正原因是我们不能就“简单”的含义达成一致。

 

如果在一个会议上,我们最大的客户明确表示,如果我们在本季度末未交付 x,他们就会离开我们的公司。那么在我看来,这似乎是一个“我们的公司面临生死存亡”的局面,也是增加复杂性绝对的好理由。

 

然而,如果我是这个项目的新开发人员,并且我能看到这个软件在过去拙劣的项目中极差的表现,我可能也会相信,如果我们现在不采取行动,并开始为我们过去的错误判断付出代价,那么这个项目无论如何都是注定要失败的。

 

所以我们该如何做?

图源:Unsplash

 

我们提前做出计划。

 

这种情况可能无法解决,而最有效的解决方法就是避免它。我们不希望处于一个复杂性增长如此之多的环境下,以至于我们很难维持这个项目。

 

只要一个项目是简单的,就很容易让更多的人员加入其中,而且关键的是,我们很容易记住我们所涵盖的所有场景。

 

一个项目越复杂,新人提供有意义的帮助所需的时间就越长。这个项目变得越来越依赖于它的原作者,那些仍然知道在哪里和为什么增加了这些复杂性的作者。但是由于忘记了特性和流,这个项目也变得越来越有缺陷。

 

而与此同时,它的灵活性也一再降低。相当数量的bug迟早会成为特性。用户不知道哪些功能是设定的,哪些不是。他们开始依赖坏掉的功能,而且从现在开始的每一个改变都是一个无法修补的承诺。

 

有趣的是,团队有时借助测试来缓解这个问题。即使有些事情是无意的,只要测试断言了它,它也会警告我们,尤其是我们不小心改变了逻辑的时候。但我认为这是无用功。很少有测试被正确的阅读、理解或维护。这样的测试就像把永远醉醺醺的边防军官送到边境一样。我们能看到他们,但我们不会认真对待他们。

 

 

每个例外都是恶性的吗?

 

图源:Unsplash

 

另一方面,编写代码时,我们希望有人能在现实生活中的问题上使用它们。现在,告诉我一个自然界中的问题,它有一个干净,简单的解决方案,并且没有例外!结果是一个也没有。生活是复杂的,代码也是。

 

只有在理论上,我们才能“在这个物理公式中忽略空气阻力”。

 

 

但简单仍然更好

 

尽管如此,我们仍然需要知道理想状态是什么样子的。我们需要知道我们在为什么而奋斗,这样我们才能知道什么时候我们偏离了它,以及我们为什么偏离了它。

 

没有神奇的解决方案,也没有三步指南。是否在简单性和复杂性之间取得了良好的平衡,只有到后来才会变得明显。一旦做出决定,这个决定通常是不可改变的,或者改变决定的代价是昂贵的。

 

但是,如果我们计划在某个项目上再继续工作一段时间,我们应该考虑未来的自己,谁将不得不忍受这个决定?以及从长远来看,这个特性真的好用吗?

 

图源:Unsplash

 

专注和简单是成功的秘诀之一。简单肯能比复杂更难做到:你必须努力理清思路,从而使其变得简单。但最终这是值得的,因为一旦你做到了,便可以创造奇迹。

留言 点赞 关注

我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”

(添加小编微信:dxsxbb,加入读者圈,一起讨论最新鲜的人工智能科技哦~)

发布了699 篇原创文章 · 获赞 2365 · 访问量 31万+

Guess you like

Origin blog.csdn.net/duxinshuxiaobian/article/details/103955133