彼得·纳尔（Peter Naur）的编程观点

让我问一个问题：您认为源代码有多少价值？

为了回答这个问题，让我带您回到几年前，当时我与一家小型高科技初创公司合作。我们正在开发一个非常复杂的增强现实系统，该系统涵盖从低层计算机视觉组件到跨平台的移动和Web应用程序的所有层。特别是对于较低级别的组件，已经进行了大量的研究。我们与一家专门从事计算机视觉的学术机构紧密合作。

简而言之，这个项目并不是任何人都可以轻松地重新创建的。因此，我们隐含地做出的假设之一是我们的源代码是该公司的主要资产之一。

当我们雇用新的首席运营官时，他曾经在大型公司工作过，他震惊地听到我们所有的代码，通信基础架构和内部系统都生活在云中。他认为，我们应该尽快转向本地解决方案，部分是出于对知识产权盗窃的恐惧，部分是为了安抚具有类似担忧的投资者。

虽然我没有发言权，但当时他的论点对我来说似乎有点不合理，我无法全力以赴。但是首席技术官已经加入了。因此，即使有人在那个月初闯入我们的办公楼，我们仍在我们办公室的一个壁橱中安装了一个Cheapo服务器。我们摆脱了GitLab，转而从Slack和Trello转移到本地Jira安装。整个过程花了几个月的时间才能完成，我想所有事情都考虑到了，这花费了大约6人的小公司大约半年的开发时间。此外，由于无法再使用涉及云的任何新工具而产生的持续机会成本。

但是整个事情让我想到了一个有趣的问题：如果有人只接受了我们所有的代码，将会发生什么？更进一步，如果我们自己将其全部放到具有MIT等宽松许可的GitHub上，将会发生什么？如果不让投资者认为我们疯了，这会对公司产生什么直接影响？

我对这些问题进行了漫长而艰苦的思考，而我认为在当时的情况下，答案是：绝对没有。

面对现实吧，即使上述轶事可能给您带来相反的印象，我们仍然是一家快速发展的创业公司。我们的代码每两周仍在发生巨大变化。更改整个体系结构或完全重写组件并不罕见，这在某些早期初创公司中很常见。就像您在这种情况下可能期望的那样，代码也不是最高质量的：一半的时间，构建会被破坏。基本上不存在测试和文档。团队外部的任何人都不太可能启动并运行该程序。即使他们这样做，过一会儿也会过时。

管理层担心的一个问题是，像Google这样的大公司可能会采用我们的代码来构建竞争性服务。在更详细地考虑了这一点之后，现在这个想法对我来说似乎是可笑的：与尝试理解我们一起编写的拙劣代码相比，从头开始自行构建它会更快。

但是，让我们退后一步，做一下相反的假设：编写精美，干净的代码，并覆盖完整的测试范围。一键式构建过程。出色的架构和组件文档。这会改变情况吗？我真的不这么认为。

您会看到，在2017年，实际上发生了一起高调的源代码盗窃事件：Panic是一家生产高质量Mac和iOS软件的公司，其大部分应用程序的完整源代码都被黑客窃取了。当攻击者要求赎金以防止代码公开发布时，Panic拒绝付款。他们得出的结论是，最糟糕的事情可能是人们在构建充满恶意软件的应用程序的破解版本。但这已经发生了（就像大多数软件一样），甚至在源代码被盗之前。不要误会我的意思，我确定这对Panic来说是一个沉重的打击，而且我绝不认为盗窃源代码不会造成损害。但是，甚至Panic在他们的博客文章中也表示，他们也不太担心竞争对手使用其代码，主要是因为它很快就会过时：

“仅在上周，该资源就已经丢失了我们承诺的大量修复和改进，而从现在开始的六个月后，它将丢失主要的关键新功能。简而言之：它已经越来越老了。”

因此，也许代码本身并不是那么有价值，但是软件公司仍然具有价值。如果技术，代码和文档的有形方面不是公司的主要资产，那是什么？

在我偶然发现由图灵奖获得者彼得·纳尔（Peter Naur）撰写的精彩文章《作为理论构建的编程》之前，我无法真正回答我的问题。如果您上过任何正规的计算机科学课程，您可能已经听说过他的名字：他是BNF（或Backus-Naur形式）中的N，它是描述编程语言的一种重要且广泛使用的符号。

在文章中，Naur描述了他对编程真正的看法。他认为程序员的主要活动是在他们脑海中建立问题空间的理论或模型：

“ [[]]正确编程应该被视为一种活动，程序员可以通过该活动形成或获得对当前问题的某种见解，一种理论。”

他将这种编程观点称为“理论构建观点”，并将其与他所谓的“生产观点”形成鲜明对比，在“生产观点”中，“ […]编程被视为程序和某些其他文本的产物。”

Naur认为，尽管生产视图很普遍，但它与我们在软件项目中根据经验观察到的许多事情相矛盾。相反，“理论构建视图”使我们能够解释许多现象，例如我在本文中所做的观察，即源代码本身几乎没有价值。 1 Naur的主要结论之一是，对现有程序进行更改（以适应不断变化的需求）通常比从头编写新代码的成本更高，至少是由不同团队的人员完成的。这是因为程序员头脑中存在模型/理论的无形方面，无法在代码和文档中表达：

“编程理论构建观的主要主张是，任何程序的本质部分，即程序理论，都是无法想象的表达，但却与人类密不可分。”

当一个新的团队获得源代码时，他们必须首先重新构建头脑中的原始理论，Naur认为，这比起从头开始构建自己的理论还要做更多的工作。

Naur带来了现实生活中的产品开发的多个示例，这些示例要求团队修改或扩展程序，但是如果没有原始开发团队的帮助，它就无法做到，否则，他们将“破坏其功能和简单性”：

“ [...]程序文本及其文档不足以作为某些最重要的设计思想的载体。”

“结论似乎不可避免，至少对于某些大型程序而言，对它们中的错误的持续适应，修改和纠正，基本上取决于与之紧密且持续联系的一组程序员所拥有的某种知识。他们。”

由于这些知识本质上是无形的，因此无法通过代码或文档进行交流-必须由加入该团队的每位新程序员重新体验。虽然以前的程序员可以帮助新的团队成员完成此任务，但是代码本身和任何书面文档在此过程中并不是很有用。这些无形要素/方面是什么？

根据Naur所说，很难或不可能用任何书面形式的代码或文档来表达三个方面，但是原始程序员可以很容易地解释它们：

1）程序员了解并了解现实世界问题与程序之间的关系。他们可以解释如何将问题的详细信息映射到代码和其他文档中：“因此，程序员必须能够针对程序文本的每个部分以及其总体结构特征来解释问题的哪些方面或活动。世界与之匹配。”

虽然我认为从理论上讲可以通过文档使这些知识变得更切实可行，但详尽地这样做是完全不切实际的。但是，Naur指出，必须全面了解现实世界的问题才能理解程序的理论：

“到目前为止，世界上绝大部分地区当然不在计划文本的范围内，与上下文无关。”但是，只有一部分了解整个世界的人才能做出与世界的一部分相关的决定。这种理解必须由程序员做出贡献。”

让我给你一个我的经验的例子。几年前，我从事的项目是改善工厂生产线的流程。那里的工人仍在使用纸质清单进行质量保证，从而使该过程非常费力且容易出错。我们将这些纸质清单替换为可在平板电脑上运行的移动应用程序。尽管应用程序本身非常简单，但是其基础业务流程却很复杂-涉及多个不同的装配线和各种不同的机器。此外，环境在不断变化和变化-工人经常改变班次，工厂内的WiFi将会关闭或在某些区域不可用，机器将发生故障，等等。由于任何停机时间都会招致高昂的成本，因此该应用程序必须准备应对所有这些情况。

正如Naur所描述的那样，交流代码与现实世界的映射将要求我们以细致的细节记录所有这些过程。如果我们尝试这样做，我相信结果将是数百页描述业务流程的页面，这些页面可以是单独的文档，也可以通过某种方式在代码中进行注释。一方面，这会激增预算，另一方面，对于项目的任何新程序员来说，这几乎没有用。仔细阅读所有这些文档将非常耗时且乏味，以至于没人能做到。

但是，这是一个很弱的论点-仅仅因为有些乏味，这并非没有可能。因此，让我们看一下Naur描述的第二个无形元素：

2）程序员不仅可以解释代码如何映射到现实世界，还可以解释为什么选择这种映射。根据Naur的说法，这种辩解可能是：一般设计原则，定量估计以及与替代方案的比较。需要注意的重要一点是，这些决策不能仅通过盲目遵守规则来做出。程序员的经验和直觉起作用：“证明的最终基础是而且必须始终保持程序员的直接，直观的知识或估计。 […]决定它们与当前情况有关的决定，再次必须归根结底是程序员的直接知识。”

回到工厂示例，假设我们已经花了时间写下如上所述的所有业务流程。然后，我们还必须为大多数技术决策添加解释和推理。例如，我们可能已经解释说，当工厂中的WiFi出现故障时，我们在应用程序中包含了离线模式。从总体上讲，这很有意义，我们实际上已经做到了。但是，随着您对问题的深入了解，这在创建本文档时以及对于任何阅读此文档的新程序员中都将花费大量成本。

但是，我认为Naur提到的第三个无形方面是“理论建构”观点的最有力论据：

3）程序员可以响应更改请求：现实世界中的问题已经有所改变，现在程序员必须判断新情况/问题与旧情况/问题有多相似。就像在上一点中一样，这些决定也不能被编码为严格的规则：“设计如何将修改最好地结合到已建立的程序中，取决于对新需求与程序中已内置操作设施的相似性的感知。 。”

显然，这不能在书面文档中表达。它涉及到如何应对现实环境中的变化的决策，这是编写原始程序时无法预料的。否则，它们可能已经包含在程序的原始设计中。

回到工厂示例：在实时用户测试的某个时候，我们发现工厂工人输入的数据不一致。经过大量调查，我们意识到这是由于他们在轮班期间有时会意外抽烟。对于我们来说，在应用程序中进行细微调整以纳入此新要求非常容易。但是，如果我们在开发过程中没有发现数据不一致的情况，那么对于一个完全负责接管代码的全新开发团队进行此更改将是一项艰巨的工作。当然，由于这是完全出乎意料的要求，因此也不可能事先编写任何类型的文档或建议以了解如何对其进行处理。

重要的是要注意，Naur还说有可能在程序员之间传递程序的理论，但这需要个人互动：

“要求的是，新程序员有机会与已经掌握该理论的程序员紧密联系，以便能够在相关的现实世界情况下更广泛地了解程序的位置。从而获得有关程序工作原理以及在程序理论中如何处理异常程序反应和程序修改的知识。”

他甚至将这些互动与教授写作或学习乐器等技能进行比较，而这需要老师不断的个人指导。

想象一个专业的钢琴演奏家。他们可以细致地“记录”在演奏时将手指放在哪里。但是，即使具有最精细的细节，您也无法仅通过阅读本文档来学习如何弹奏钢琴。

如果我们同意Naur对编程的评估，那么，那就是高科技公司的价值与开发团队以及问题领域的模型密不可分。从本质上讲，这意味着什么：

一家软件公司的主要价值是在开发人员头脑中映射源代码和问题空间。

这个结论对软件公司的许多方面都具有重要的意义，但对于管理，雇用和整体文化尤其重要。

使软件更加灵活或模块化，从而使程序员更具有可替换性的大多数努力都被误导了。正如Naur写道：“ […]当前有关编程的许多讨论似乎都假定编程类似于工业生产，程序员被视为该生产的组成部分，该组成部分必须由程序规则控制，并且可以轻松更换。 […]在工业管理方面，这些观点支持将程序员视为责任心很低的工人，并且只接受简短的教育。”

他认为应该给开发商更多的责任，并将其视为公司的永久资产。

如果您是管理人员，则需要意识到发展主要是决策，当然只有在获得必要的自主权来做出决策时，这才有效。我相信这种认识是许多成功的公司拥有更好的工程文化的主要原因之一。

给您的开发人员足够的自主权和决策权。他们不仅需要参与有关如何构建事物的决策，还需要参与构建内容的决策。

让您的开发人员尽可能地靠近客户（并且让他们满意）。这是他们可以直观了解需要解决的实际问题的唯一方法，毕竟，这种理解是贵公司的主要价值。

由于这本质上是无法衡量的，因此请勿尝试衡量开发人员的生产率。有时，一下午思考问题而不产生任何实际痕迹可能是公司最重要的事情。毕竟，开发人员花费了大部分时间来确定系统。

留住人才比您想像的更为重要。疯狂的是，在一个主要价值与个人贡献者息息相关的行业中，人们每两年更换工作

理论构建视图还为我们提供了有关如何构建入职流程的见解。它有助于解释为什么新开发人员通常要花很长时间才能达到完全生产力

真正理解自治为什么很重要，不仅会帮助您的公司，而且会改善您的招聘流程。您的工程师会更快乐，从长远来看，这将滴入招聘并简化工作。进行这项更改并非易事，但值得。

如果您想真正改善您的招聘并获得一些可行的建议，请随时阅读我有关该主题的最受欢迎文章：招聘高级工程师时，您不会买，而是在卖