在这篇文章中，我想探讨一些我过去几个月一直在研究的想法，因为我已经研究和开发了更多的语言和范例。

什么是bug？

这是一个很好的问题。 这是你错过的东西吗？ 由于意外的副作用，是不良行为吗？ 是否范围蔓延没有考虑？ 是否未能理解给定解决方案的设计？

我想我们中的许多人都会在内部拥有一个复杂的模型来描述我们软件中的错误。 但是现在我们来看看维基百科的定义......

“软件bug是计算机程序或系统中的错误，缺陷，故障或失败，导致其产生不正确或意外的结果，或以非预期的方式运行。”

但是，这里缺少一个时间元素。 “什么时候”你会说软件有bug呢？

当客户或客户发现它？

当你的测试套件出现语法错误时？

当你的编译器发现你传递的是Integer而不是String？

当你在纸上写下你的知识模型时？

在早期认识到你的现实模型失败对于开发过程至关重要，这样我们就可以确保我们的软件可靠并且可以执行其设计的自动化任务，并最大限度地减少你的破坏模型将对世界的损害。

我们很幸运能够拥有能够帮助我们识别模型何时被破坏的语言和工具。

我们一直在问错误的问题

关于范式和语言的讨论并不缺乏。事实上，如果你阅读有关Hacker News，Reddit等的一些评论，你可以清楚地看到每个群体都有一种部落主义形式。

从社会角度来看，这是有道理的，对吧？我们都希望成为社区的一员，并对我们所做的工作产生归属感，以便我们可以分享并从中受益。

我曾经是一名前世的音乐家，这些关于工具和语言的对话就像我们坐在那里并在音乐装备上呆呆的时候。你用什么吹嘴？你的放大器设置是什么样的？你喜欢用什么字符串？

随着你的旅程进展，你将意识到这些只是工具。真正的力量来自音乐家的意图以及他们在脑海中所持有的价值观，以便与同龄人和观众沟通。

软件开发在这方面没有什么不同。我们试图用代码来表达关于世界的一些东西，我们所持有的价值观反映在我们创造的“事物”中，这会影响我们在协作期间的同行，以及最终用户

在投入生产时的情况。然后这些继续在商业，文化等世界中产生许多其他影响。

像“面向对象的编程已经死了”，或者“函数式编程是未来的方式”这样的论点，略微忽略了这一点。这些工具和思维模式由我们的价值观支持。

我们需要首先从驱动一切的基本核心价值开始，以便了解我们做出的选择。

早期软件开发的一个想法

“让我从一个公认的事实开始：总的来说，编程社区对程序正确性问题表现出非常矛盾的态度。 平均程序员活动的主要部分是致力于调试，从这一观察结果我们可以得出结论，他的

程序的正确性 - 或者我们应该说：他们的专利不正确吗？ - 对他来说是一个相当令人担忧的问题。 我声称程序员只有在他的程序完美无缺时才能完成一份体面的工作，而不是当他

的程序在大多数情况下正常运行时。

- E.W Dijkstra”

软件中的许多人已经通过其他一些方式表达了这一点。 我不会列出所有这些（我鼓励你从你的导师那里寻求这些观点），但这里有两个暗示同样的想法。

“简单，正确，快速。 以该顺序。

- Drew DeVault”

“让它工作，做对，快速。

- Kent Beck”

这是本声明的第二部分。 我们中有多少人在日常工作中超越了本声明的第一部分？ 如果你确实超越了第一部分，你能诚实地告诉自己你做对了吗？ 如果你这样做，你怎么知道？

这是需要绘制战线以谈论语言和工具选择的地方。 随着软件工程师积极开展更多语言和工具，让我们在发布我们在世界上所写的内容之前做到正确，这种趋势正在转向行业。

开发人员 - 专注于正确性。 这是我们开始看到的范式转变。

要说它只是“函数式编程”，或“面向对象编程”或“在这里插入一些其他工具或技术”，根本就不是这样。

也许在Haskell的情况下，它是纯粹的，懒惰的和函数式编程与参数多态的结合，这是语言追求正确性的最大优势。 我会说Rust非常注重正确性，但也许这可以通过强制执行正确的

内存分配/解除分配以及ADT和模式匹配来实现。

如果你使用说法，动态语言或面向对象设计，你需要注意的是，从长远来看，动态调度的“对象”的语言和思维方式是什么，让你与众不同 每次尝试进一步发展软件引入新要求时，

似乎都会重复出现的错误？

正确并不意味着完美

在讨论正确性的想法时经常会出现这种情况。这是我自己长时间联系在一起的东西。但是我已经意识到一些基本的东西。

我知道这看起来像是陈词滥调，但没有“完美”软件这样的东西。我怎么知道这个？

软件，我们的知识，编码，以便机器可以基于该知识执行操作，以便其他人可以随着时间的推移发展该知识。

我们的知识，绝不是“完美的”。最好的是现实的表现。关于正确性的核心思想之一是将这些知识置于详细审查之下，以查看裂缝开始出现的位置。你的模型和理解在哪里开始垮台

？是否有你的知识表示意味着你最终没有意外的副作用？

编码知识中的这些“裂缝”是我所知道的失败不变量。不变量是程序的属性，在所有情况下都适用。

你知道兔子洞有多深吗？

以下是一些可以指导你和你的团队的初步问题。

你有多少bug？

它们可以归类吗？

他们多久发生/再次发生？

当你必须在代码库的“遗留”部分实现一个功能时，你的速度会下降多少？

当你开始询问这些类型的问题时，你可能不知道还有其他选项可供你使用。但是，我鼓励你开始考虑你的工具选择和语言选择。

作为一个行业，我们花费大量时间来维护充满地雷的软件。为什么是这样？

部分由于历史技术原因，可能正确性的实际实施不足。部分原因是我们的行业非常有利可图，我们每次编写代码时都在为自己创造持续的工作。对我们中的许多人来说，部分地，可

能更接近家庭的是，软件开发中的激励被误解和误传。

我们受到业务需求的推动，以便为用户和客户提供最大价值，并立即跳转到下一个任务，所有这些都是为了获利。我并不反对盈利，事实上我是全力以赴，但直接关注它可以创造一

种适得其反的心态。就像是：

“我希望能够比其他任何人更快地将我的软件创意带入世界，并且能够牺牲在所有非成功的路径场景中需要考虑的边缘情况和行为 - 我将在以后填写这些“。

弱类型动态编程语言的值似乎与这些想法一致。我绝对肯定这不是动态语言的意图。他们在进行元编程的能力以及Smalltalk背后的思想以及系统中的每个行为就像一个微生物通过消

息与其他微生物交谈时表现得非常富有表现力，这仍然是一些尚未完全实现的东西。

然而，需要“完成任务，快速完成”或“快速移动并破坏事物”的声音非常类似，在某种程度上，它们与在世界上运营的许多企业保持一致。这并不是说它无法完成。但它需要人力

训练，沟通和运作良好的团队来实现这一目标，以弥补这种价值调整的不足。

你能怪开发商吗？你能责怪企业吗？在这里继续推动这种构建不良软件的文化作为一种可接受的编写软件的方式，谁是罪魁祸首？

我们都是。在我们开展日常工作时，我们都对此负责。这意味着我们也有能力改善它。

这条路很长，直到它没有

我不会给它涂糖衣 - 采取“正确”道路有一些非常明显的障碍。

● 函数式编程和类型语言理论在学术上受到很大影响，而编程的入门门槛却大大降低。

● 对于不受欢迎的“生产就绪”语言的语言而言，重要的工具和入门短缺。

● 成功案例很少见，特别是其他人要学习的实施细节。

● 业界担心 - “我能否在其他地方使用我的技能，是否有Haskell开发人员的工作等”

● 缺少来自关键业务决策者的支持，即自动化系统的正确性，使你能够以可持续的方式更快地移动，而不是更慢。

我相信这个清单上还有更多的东西，但我鼓励你不要试图用这些点作为借口。

每个失败的不变量都会花费一些东西，并随着时间的推移而成倍增加，因为这些不变量会重叠并且恰好同时发生。 时间，收入，客户参与，幸福，就业保留，业务可持续性，利润，

团队合作，沟通清晰度。 在你煮熟之前，这真的是一种逐渐的沸腾。 所有这些事情都可以显着降低许多数量级。

沿着“正确”路径前行是有很大好处的。 我们应该关注哪些事情来实现目标？ 以下是我认为很重要的一些内容，但绝不是明确的清单。

● 弥合用于将软件部署到生产的工具差距，用于没有临界质量且具有部署约定的语言。

● 更多故事，以及不同技术堆栈的安全迁移路径和部署技术的详细信息。

● 更准确和可访问的学习OOP设计模式与Functor，Applicative和Monad的比较与正确性的关系 - 具体而言，OOP如何不配备工具来实现其核心的正确性结果。

● 从软件团队到企业其他团队的更多沟通，关于他们因正确性的副作用而获得的好处，例如提高开发人员的幸福感，积极的学习文化，提高生产力，尤其是财务收益。

● 打破“不是在这里发明”的综合症，作为个人和团队。相反，站在巨人的肩膀上，他们致力于寻找原则，科学，正式和可证明的方法来开发正确的软件。

最后的想法

例如，许多人学习Haskell的经验是，他们无法立即提高工作效率。 他们无法轻松编写程序 - 如果你在现有范例中富有成效，这可能会非常令人失望。

然后，他们错误地认为永远编写所有Haskell应用程序一定很困难。 持续的成本。 我还记得看到同事因为类似的原因而与Rust挣扎。

请记住，第一次尝试这个 - 你正在尝试学习一种新的思维方式。 这就是范例。 它并不总是很容易。 但是一旦你得到它，你只需支付一次费用，并能够永远从这种心态中获益。

业界开始在这个领域发出很多噪音，包括功能性Scala，Typescript，Purescript，Elm，Haskell，Rust，Coq，Agda，Idris等等。 其中一些对于编写生产代码是不实际的，但其中

许多都是。 我鼓励你花时间在正确性范例中研究工具范围内存在的可能性。

我们都有一定数量的代码，我们可以在生命中编写。 我们是否真的希望在你的职业生涯结束之前处理相同类别的（已解决的）问题，同时为你的同行，企业和世界留下一系列无法维

护的软件和无意识的副作用？

我们可以做得更好。 就像我们一样 - 让我们与那些只能在软件社区之外利用这一想法的人分享正确的信息。

一如既往，我希望这对你有用，并感谢阅读！