全文共2900字，预计学习时长
9分钟
图源：Unsplash
简单的成功远远胜过复杂的失败。
这句话像一个魔咒，在各行各业、各种场景似乎都得到了验证。
巴菲特早在1996年说过：“大部分投资者，包括机构投资者和个人投资者，早晚会发现，最好的投资股票方法是购买管理费很低的指数基金。”
无数股民的亲身经历验证了巴菲特建议的正确性。
“投资方法往往越简单效果越好。”
“简单常能胜过复杂。”
在一次关于代码评审的无伤大雅的辩论中，我突然发现，在所有与编码相关的决策中，我只有几个基本的想法。其中之一就是: 简单胜过复杂。大约三秒钟后，我意识到这既不是一个众所周知的咒语，也不是一个可以很快解释完的咒语。这是一个伴随你成长的信念。但是，我该如何向我的队友解释这个信念呢？
对我来说，“简单胜于复杂”是对不同问题的务实回答，就像一把简单的Occam剃刀。它带给我两个好处:
· 它可以让我把一个问题分解成现在需要解决的部分和可以推迟的部分。
· 它让我对自己的决定有了信心，因为它得到了许多其他定理、原理、规则和指导方针的支持。
那么“简单胜于复杂”到底是什么意思呢？
图源：Unsplash
这个指导方针希望你选择更简单的解决方案。你应该经常问自己：你能简化你的代码而仍然得到相同的结果吗？你能在简化设计的同时达到一样的目标吗？
可以是一些小事，比如：你是否过度使用了强大的语言结构？使用try-except语句对你有好处吗，还是简单的 if 语句更适合你的流程？
或者可以是更大的问题，比如：你真的应该支持20个不同的场景吗？或者你能通过提供最常见的三个场景来获得可比的用户体验吗？
这个指导方针是引导您对复杂性保持警惕，并要求缩小它的好理由。
复杂性如何影响一个项目
在一个项目的开始，没有代码，没有规范。未来，或者是我们必须创造的东西是令人畏惧的，但过去，也就是我们创造初的东西是简单的。到目前为止，我们还没有创造出任何东西，这很简单，任何人都可以做到。
现在我们需要创造一些东西。我们不能一下子创造出所有的东西，我们应该从什么开始呢？
图源：Unsplash
如果我们相信欣欣向荣的创业场景，务实的做法是从一个MVP开始。它代表最小可行产品，一个包含足够有用特性的产品，它成功地完成了其主要任务。这个阶段的目标是保持开发项目的低成本，直到我们有证据证明我们正在开发正确的特性。
MVP原则就是“简单比复杂好”的不同说法。应该使用最简单的解决方案来解决您的问题。不要增加复杂性，例如，成本，直到你有充分的理由。
类似的概念也出现在《帕雷托法则》中，它也被称为二八法则或少数人的法则。它指出，对于许多事件，大约80% 的影响来自20% 的原因，也就是说，80% 的故障（bug）报告是由20% 的故障引起的; 在80% 的时间中，只有20% 的特性被使用。
帕雷托法则起源于统计学和经济学，但已经应用于广泛的领域中。它很好地支持了我们的简单胜于复杂的概念。如果80%的客户只使用了20%的可能工作流，那么为什么还要费力去支持我们软件所能想到的每一个工作流呢？
因此，要决定哪些特性应该首先开发，我们必须挑剔。我们所建立的一切，我们也必须在一段时间内能及时提供支持。我们添加到软件中的任何东西都会产生维护成本，并且会影响我们如何以及以何种成本构建其他完全不相关的新东西。
提高复杂性的好理由是什么？
从理论上讲，上述内容似乎都是合乎逻辑的。但它也非常模糊。没有任何东西像复杂性或简单性的实际定义一样，没有任何东西可以作为我们的经验法则来判断哪个特性值得花费一个月的努力，哪个特性值得花费六个月的时间，哪个特性只值得投入一天即可。这就是模糊产生和争吵变得激烈的地方。
开发人员和管理人员不关心这个指导方针的真正原因是我们不能就“简单”的含义达成一致。
如果在一个会议上，我们最大的客户明确表示，如果我们在本季度末未交付 x，他们就会离开我们的公司。那么在我看来，这似乎是一个“我们的公司面临生死存亡”的局面，也是增加复杂性绝对的好理由。
然而，如果我是这个项目的新开发人员，并且我能看到这个软件在过去拙劣的项目中极差的表现，我可能也会相信，如果我们现在不采取行动，并开始为我们过去的错误判断付出代价，那么这个项目无论如何都是注定要失败的。
所以我们该如何做？
图源：Unsplash
我们提前做出计划。
这种情况可能无法解决，而最有效的解决方法就是避免它。我们不希望处于一个复杂性增长如此之多的环境下，以至于我们很难维持这个项目。
只要一个项目是简单的，就很容易让更多的人员加入其中，而且关键的是，我们很容易记住我们所涵盖的所有场景。
一个项目越复杂，新人提供有意义的帮助所需的时间就越长。这个项目变得越来越依赖于它的原作者，那些仍然知道在哪里和为什么增加了这些复杂性的作者。但是由于忘记了特性和流，这个项目也变得越来越有缺陷。
而与此同时，它的灵活性也一再降低。相当数量的bug迟早会成为特性。用户不知道哪些功能是设定的，哪些不是。他们开始依赖坏掉的功能，而且从现在开始的每一个改变都是一个无法修补的承诺。
有趣的是，团队有时借助测试来缓解这个问题。即使有些事情是无意的，只要测试断言了它，它也会警告我们，尤其是我们不小心改变了逻辑的时候。但我认为这是无用功。很少有测试被正确的阅读、理解或维护。这样的测试就像把永远醉醺醺的边防军官送到边境一样。我们能看到他们，但我们不会认真对待他们。
每个例外都是恶性的吗？
图源：Unsplash
另一方面，编写代码时，我们希望有人能在现实生活中的问题上使用它们。现在，告诉我一个自然界中的问题，它有一个干净，简单的解决方案，并且没有例外！结果是一个也没有。生活是复杂的，代码也是。
只有在理论上，我们才能“在这个物理公式中忽略空气阻力”。
但简单仍然更好
尽管如此，我们仍然需要知道理想状态是什么样子的。我们需要知道我们在为什么而奋斗，这样我们才能知道什么时候我们偏离了它，以及我们为什么偏离了它。
没有神奇的解决方案，也没有三步指南。是否在简单性和复杂性之间取得了良好的平衡，只有到后来才会变得明显。一旦做出决定，这个决定通常是不可改变的，或者改变决定的代价是昂贵的。
但是，如果我们计划在某个项目上再继续工作一段时间，我们应该考虑未来的自己，谁将不得不忍受这个决定？以及从长远来看，这个特性真的好用吗？
图源：Unsplash
专注和简单是成功的秘诀之一。简单肯能比复杂更难做到：你必须努力理清思路，从而使其变得简单。但最终这是值得的，因为一旦你做到了，便可以创造奇迹。
我们一起分享AI学习与发展的干货
閱讀更多 讀芯術 的文章
