开发人员花费大部分时间来确定系统

当我说开发人员将大部分时间花在确定系统上时，经常被问到我的意思。让我们打开语句的包装。

Zelkowitz，Shaw和Gannon撰写的《软件工程与设计原理》一书中有关该主题的最早文献可追溯到1979年。它说，大部分开发时间都花在了维护上（67％）。

当然，这本书没有说明如何获得该数字。从那以后，它仍然被认为是一个足够重要的问题，引起了广泛的研究关注。

让我们看看夏，宝，罗，兴，哈桑和＆amp; Li的题为“ Measurement Program Comprehension：A Professionals大规模现场研究”，发表于IEEE Transactions on Software Engineering，44，951-976，2018年。这篇论文非常有趣，因为它详细描述了如何获得这些数字。它说，理解力平均占〜58％。

特别要看一下表中的第三列：它说导航占了24％的工作量，这与理解工作量是分开考虑的！

因此，经过40年，我们可以观察到，除了学习如何测量“计算出来的”时间以外，没有太大变化。

好吧，这是我们最大的一笔支出。如果我们想优化我们学科中的任何东西，我们应该首先看这部分。我们经常谈论我们如何构建系统，但是您却经常谈论如何花费“花销”。时间？如果我们不谈论它，那不是明确的。如果不明确，则不会进行优化。

如果我们确实谈论如何“花费大量时间来建立系统”，那么我们会注意到人们花时间在阅读上。实际上，正如上述论文所表明的那样，理解力实际上是根据阅读来衡量的！这两个被认为是大部分的同义词。

鉴于在过去的40年中没有发生太多事情，我们应该接受这样一个想法，即也许我们应该以不同的方式来解决问题。

请多多包涵。这就是它变得有趣的地方。那么，开发人员为什么要阅读代码？因为他们想弄清楚情况，知道下一步该怎么做。目的很重要。这是决策。

从这个角度来看，阅读只是从数据中收集信息的手段。它还恰好是最手动的方法，因此这为优化提供了重要的机会。

在对任何事情都可以做有意义的事情之前，必须命名它。否则，就像伏地魔一样。许多冬天以前，我称其为“弄清楚系统来知道下一步该怎么做”。评定。我声称我们应该围绕它优化开发。

在整整十年的时间里，我和我的同事都探索了这个想法。它引导我们进入了现在所谓的可塑发展。

读取是从数据中提取信息的最手动的方法。它不能扩展并导致信息不完整不确定。

软件足够困难。不知道当前系统是什么样子，不应成为方程式中的可接受变量。关于当前系统的手绘图片是一种信念。决不应该基于信念。不在工程中。

一旦我们接受了系统就是数据，显然我们也应该像对待数据一样对待它。数据科学告诉我们，您首先要从问题开始，然后通过与上下文匹配的工具进行推理。

由于软件是高度上下文相关的，因此我们无法预测特定的问题。我们只能预测问题的类别。为了解决这个问题，可塑开发的关键思想是在知道问题后该工具应该可塑。这样，它可以处理上下文中重要的内容，因此，它可以处理无聊的阅读部分。当然，要切实可行，创建自定义工具的成本必须很小。

我认为在开发过程中以及在理想情况下针对每个单独的开发问题构造定制工具的流程都是软件开发的下一个重大飞跃。

从现在开始的十年中，我们不应该在阅读方面衡量＆＃34;将系统构形。我们应该用精力解决实际问题。为了到达那里，我们应该从谈论如何不阅读代码开始。我们负担不起。

我们创建了Glamorous Toolkit，为＆＃34;如何不阅读代码＆＃34;提供了一个具体的起点。会话。 Glamorous Toolkit是可模制的开发环境，可以廉价地创建有关软件系统的自定义工具。