软件重用是否会妨碍流程的可重复性

代码重用成为问题

我一直在思考有关软件交付的问题，并且我一直回到可重复性和/或可再现性的问题。它们很重要，因为如果您不重复一个项目，那么改善用于构建项目的流程就变得更加困难。工程涉及不断改进与设计和施工有关的过程，以产生更高质量的项目。

由于其数字形式，软件可能严重依赖于重用。无需重写模块，我们只需再次调用它或将其复制到另一个系统即可。一些示例是身份验证/登录或登录功能。这些类别有许多众所周知的示例，并且传统的智慧是重用现有内容而不是自己动手做。

与其他学科的一些比较

施工

相反，物理系统（建筑物，桥梁）的构建远没有可重用的范围。确实，房屋的蓝图可以重复使用多次以建造房屋的相同副本，但是必须每次都执行建造。剪切和粘贴在模拟世界中不像以前那样工作。桥梁的蓝图比房屋的可重复使用性差，因为场地条件会有所不同。

大师级建筑商是公认的专家，他们在他们所在的地区设计和/或建造了数十，数百或数千个事物。例如，世界著名的建筑师兼设计师Frank Lloyd Wrightdesigned more than 1,000 structures and completed 532 works。与设计了“仅”五种语言（Turbo Pascal，Delphi，J ++，C＃，Typescript）的Anders Hejlsberg形成对比。在很多方面，这是不公平的比较，因为域是不同的。但是从广义上讲，两个非常有才华的人的可量化生产差异很大。

武术

武术家会说，对动作的精通仅来自数千次重复。在完成大部分重复之后，许多武术家对于以前被认为是复杂的kata或形式变得如此简单感到惊讶。这些学生的讲师还将注意到运动如何变得更加流畅和有目的性，以及运动的经济性。同样，与没有经验的学生相比，经验丰富的武术家能够更快地拾起更复杂的kata。重复的经验为他们提供了一个框架或过程，使他们可以更快地学习。

木工

木工经历了类似的转变。业余爱好者木工总是回想起他们的第一个需要大量抽屉的项目。如果他们完成了该项目，他们将对装配线产生的效率重新获得赞赏。还有其他好处，例如更好地了解如何在单张纸料上放置抽屉部件，以最大程度地利用木材。与业余爱好者相比，专业的木工可以更快地设计，开始和建造他们以前多次制作的物品。他们还具有查看他人设计中固有错误的能力，而这些错误是他们工作中的错误。

那么，软件重用会阻止软件开发人员变得更加熟练吗？

在许多方面，软件设计和构建始终是新的。我们不会重复过去的工作，因为如果我们可以重用模块，库或系统，那么我们会做。在从头开始重写整个内容之前，我们将优先扩展现有系统。但是重复是使我们能够发现设计和构造效率的原因。任何进行过体育锻炼或体育锻炼的人都会告诉你，重复锻炼是成为一名优秀练习者的关键。

我的问题：软件的重用能力是否会阻止重复项目带来必要的流程改进和效率？

重用软件的能力不会阻止流程的改进。

如果您考虑构建软件的过程-开发需求，设计系统，实施系统，部署系统，管理需求，管理配置，验证和验证工作产品，跟踪更改以及其他许多过程（请参阅CMMI流程域，用于对软件开发中的关键活动进行可能的细分）-不管您有多少重用，在每个项目上都会重复这些过程域。此外，每种方法都具有某种定量和定性度量，可以用来确定特定过程或活动的良好程度，从而确定整个开发过程的良好程度。

在极端情况下，我们可以假设一个强大的软件产品线。另一方面，您可以假设未开发的项目。尽管它们可能以不同的速率甚至可能以不同的顺序发生，但是仍然需要以不同的程度执行所有这些过程。例如，在大量的重用中，可能会在系统级别（要求V＆V，集成测试，系统测试，验收测试）上花费较大比例的分配时间来进行集成和验证/验证活动。通过新的开发工作，在设计和实现上可能需要更多的时间。只要您在项目过程中至少执行一次流程，就可以（定量和定性）对其进行度量。进行调整后，查看这些调整如何影响过程域或交付软件的整体能力的某种衡量标准，

它们对流程改进的关键是对活动和流程进行某种逻辑分解，确定如何（最好是一致地）对其进行衡量，以及如何理解这些度量以使流程朝着某个方向做出改变。这与重复项目无关，而与重复过程的一致性有关。

我认为其他工程学科不利用重用的想法是错误的。即使在设计建筑物/机器时，您仍然拥有许多其他项目使用的组件。例如，您设计自己的螺钉吗？引擎？门还是窗户？当然不是。这些通常是由不同的人设计的，然后在不同的产品中使用它们。而且它们经常被标准化，从而促进了更多的重用。

我认为这个问题很复杂。您甚至无法将最复杂的建筑物的复杂性与复杂的软件进行比较。人们普遍认为，软件的复杂性使得从工程方面难以解决。一旦有了可以创建质量可接受的软件的过程，就会发现创建数量级跳跃所需的软件复杂性。因此该过程无法使用。因此，如果我们不得不重复执行软件的某些部分直到对结果满意，我们将永远无法完成该软件。

这就是为什么要推广干净代码的原因。根据新经验更改过去代码的能力可以说是设计重用的形式。因此，我们无需重复创建不同的软件，而是通过重用新经验和针对旧问题进行设计来重构和完善单个软件。所有试图使软件做同样的事情。

软件与大多数其他学科是不同的，因此，我们在时间上花费最多的时间的经济学往往是不同的。

在施工中，你花了一定的时间和金钱上的蓝图（和软件是远远更像生产的蓝图比就像盖大楼），那么，粗略地说，很多更多的实际构建了一个或更多次。因此，将大量工作投入正确的蓝图中是值得的。更具体地说，您的问题-值得重复进行从头开始的工作，以使最终产品更好一些。

在软件中，有了蓝图，构建产品要比制作蓝图便宜得多。至少在大多数情况下-如果将软件嵌入到起搏器中，您将在某种程度上更接近桥梁制造商的情况。但是总的来说，重用软件可以节省最大预算项目的90％的成本，而节省90％的小得多的预算项目用于建造桥梁。因此，重复使用的成功率更高。

就生产力而言-当您建造一座桥梁时，您将面对真正重要的现实约束。想象一下，如果向建筑师支付了大笔资金来设计大型多人在线游戏的桥梁，那儿的建筑成本接近0，而且限制大大低于现实世界。他们将设计按实际桥梁标准异常复杂的桥梁。蓝图阶段可能需要更长的时间。

而且，建造的桥梁数量有限，并且由于设计只是成本的一​​小部分，因此您可以付出最好的代价，而少数最好的人可以完成大部分设计。有成千上万的软件开发人员，而且基本上所有的人都有大量积压的积压工作，如果他们有时间的话。您不会找到一个在所有这些工作中占很大比重的人-确实有些人真的很令人惊讶。

您的真实观点似乎是，我们可能会因重复使用而失去某些东西，而不是尝试重复和改进某些东西。我想你有一点。问题在于，尽管重写某些基础内容并尝试对其进行改进在全球范围内更有效率，但任何承担此责任的人都会承担所有风险，而获得的回报却可能不多。（也存在一个严重的依赖地狱的实际问题，它可能会从重写内容中获得一些胜利，但至少在全球范围内，它并没有意义，这毫无用处。版权和专利也可能迫使拟议的重新设计工作消耗大量的重写工作来重做较小的现有代码。

在从重复学习的条件-在所有的学科出现这种情况不是在建设少的设计，因为是重复少，学习机会，所以较少，或许少效益。而且，设计过程可能不是那么可重复。这有点像编写小说的过程。好的过程几乎可以肯定会有所帮助，并且软件通常比新颖的东西更具协作性，但是当目标是发明新事物时重复进行过程是有问题的。甚至小说家也从过去学到很多东西，但是可重复的过程是创作努力的次要因素。而且，如果软件开发的任何部分确实真正可重复，那么为什么计算机不这样做呢？

软件的重用能力是否会阻止重复项目带来必要的流程改进和效率？

在过去的17年中，我曾在同一大型项目中担任系统和软件工程师，顺便说一句（在您的第一个链接中想到了空中客车A380参考），尽管我的职责是在军用飞机领域。这样的故事基本上都是虚构的，当您有内部洞察力时，观看这些故事真的很有趣。

但是对于您的简短问题：根据我的经验，我会说是和否。

首先让我说，我全力以赴以各种形式回收软件（嗯，也许不是全部...）。总体上，从剪切和粘贴的代码片段和算法到整个代码模块和函数库，重用几乎所有优点都比总是从头开始（稍微推翻）要好得多。

缺点是，正如您指出的（或至少可以推断出的那样），当您仅通过组合给定的一组组件来添加功能时（是的，我将其简化到了极致），您实际上并不会像程序员，工程师或其他任何人。

只是看着工作中我周围的软件工程师，我从长期的经验中知道，他们中的大多数人都不知道，更糟的是-对学习没有兴趣，除了正在生产的最低限度的产品外，我们正在构造的产品没有任何其他东西文档或它们指定要执行的代码段。

我在这里讨论的话题不多，但是我的观点是，当程序员不需要学习他们正在构造的代码将真正用于什么目的时，并且不需要学习系统的内部工作原理，因为他们可以重用已经编写并经过测试的组件，那么大多数组件就不会再这样做了。

当然，这也是由于其他情况造成的，例如我们正在制造的产品非常复杂，一个人不可能了解所有产品（而我只是在谈论飞机中的一台计算机-其中最复杂的一个，但仍然）。

如果我们的软件工程师没有选择重新使用那么多代码的选择，我相信他们将在总体上变得更好，尤其是对该项目而言，资产将会更多。

哦，你可能已经注意到，我谈论他们在这里有很多。我当然也包括在这些软件工程师中。唯一的例外是，我似乎比其他人更加好奇和渴望学习新事物：-)面对一项新任务时，我总是把自己学到的知识带给自己，无论是在事实形式和研究源代码（是的，我实际上也很喜欢）。

啊-当当，又被跟踪了...我的借口是我没有睡32个小时，所以我的专注能力有点...我在说什么？

如果仍然有人在阅读，我的结论是：

是的，过多地重复使用软件会使知识不足的软件工程师受益，这使他们在实际需要了解事物的工作原理时效率明显降低。问题分析是一个很好的例子，甚至可以说出建议的设计解决方案是否可行。当然，当您真的不知道自己在做什么时，也很难实现流程改进：-)

并没有，重用软件小心，可能给你很多的空余时间来考虑和计划流程的改进。

正如在另一个程序员问题中可接受的答案中所指出的那样，应谨慎对待与构造的类比：

推荐的读物是《软件构造类比被打破》

软件通常被比作构建。不幸的是，这种类比是有缺陷的，并且怀疑从建筑业汲取的教训。

我观察到的是，好的软件项目将很多可重复性“转移”到了质量保证中。

当我是一个长达1.5年的项目的测试员时，我们每周执行“检查点”发布的测试周期，整个项目的测试周期约为70次。那是……相当可重复，轻声细语（一周内变化不大）。对夜间构建的测试自然会更具可重复性-在该项目中进行了约500次（很少有有趣的showtopper错误很少发生，因此无法有所作为）。

现在，按照“可疑”的比喻，告诉我一家建筑公司已经建造了500座桥梁-全部由同一支队伍组成。

• 进一步讲一下，告诉我一家公司，他们在每个新桥中都使用了几乎相同的砖头和铁块（在这里，我指的是，我们测试的发行版日复一日，每周都具有几乎相同的代码段。周-“变化不大”。
  

大师级建筑商是公认的专家，他们在他们所在的地区设计和/或建造了数十，数百或数千个事物。

好的，按照您上面引述的重复性解释，我可以说呢？那时，我们的一群测试人员（不是很特殊）已经进行了验证，请参见上方（“约500”）我们所在地区的数百种内容。

对于项目开发人员而言，他们实际上是在构建（“每晚构建”）-看到的单词是相同的，并且在此上下文中的含义是正确的-他们所在的区域有数百个东西。

如果要继续把这种“可疑”的类比延伸到“成千上万的事物”，那么当人们着眼于正确的事物时，这些数量在软件开发中再也不是什么壮观的事了。

• 举例来说，我过去的另一个项目（同样，没有什么引人注目的，而是定期的），这次是开发人员角色，已经进行了5年以上（8个主要发行版，几十个次要发行版）。有类似的每周检查点5x52~=250，有类似的夜间发布5x365~=1800，并且有类似的开发人员/质量检查团队在处理这些问题。每天重复，每周重复，每月重复，大部分都是重复的内容（两次夜间构建之间变化不大）-所承诺的范围是数千次（1800）。

寿命较长的项目（例如Windows或Java或AutoCAD）的寿命可能长达10、20、30年，这很容易导致重复进行了多达“成千上万”的夜间构建和夜间测试。

通过持续集成，可重复性转向质量保证的概念变得更加突出。

每天几次将所有开发人员工作副本与一条共享主线合并的实践... CI可以看作是定期集成实践的强化。

除了自动化的单元测试外，使用CI的组织通常还使用构建服务器来实施通常应用质量控制的连续过程-少量的工作，经常应用。除了运行单元测试和集成测试外，此类过程还运行其他静态和动态测试，测量和分析性能，从源代码中提取文档并设置格式并简化手动质量检查过程。这种连续的质量控制目标的应用，提高软件质量，并通过替换应用质量控制的传统做法，以减少对提供它所需的时间，之后完成所有开发。这非常类似于最初的想法，即更频繁地进行集成以使集成更容易，仅适用于质量检查流程...

可重复性？它就在那里，就像人们能想到的一样。

通过频繁/连续的质量检查，出问题的地方会迅速归还给开发人员，这些开发人员被迫重复正确地进行尝试，直到成功通过失败的测试为止。从某种意义上讲，重复直到通过的循环类似于代码cata，

编程中的一项练习，可帮助程序员通过练习和重复练习磨练自己的技能...

您所说的是正确的：例如，库解决了高级语言无法解决的功能，这些语言解决了汇编不解决的问题，机器语言未解决的问题。当您在Java中调用System.out.println（）时，您将看不到CPU如何输出到设备。

所以，是的，您正在失去一些东西。您获得的是专注于未解决问题的能力。现在可能您需要将自己投入技术的其他方面（例如，网络如何运作）以解决问题。但是，当您要做的只是构建网页时，您无需成为阅读机器语言的专家。

同样，桥梁建造者每次都解决一个稍有不同的问题（这是一条不同的河流）。他们不必担心如何创建具有一定抗拉强度的钢梁，也不必担心如何以一定的公差加工螺栓。他们将其留给解决该问题的专家。

仔细观察，您会发现我们的整个社会和基础架构都建立在99％的可重用性和仅1％的真实进度之上。大多数新事物只是旧事物，添加或删除了一些额外的东西。这是人类知识的积累。您可以使用像样的库用高级语言编写代码，因为有人找出了达到这一点所需的所有令人难以置信的复杂内容。它使您能够解决新的有趣问题。

将所有这些联系在一起并回应评论：您不必解决已经解决的问题就可以提高能力。此外，您所做的大部分工作都会重新发明轮子。简而言之，答案是否定的-您无需重新实现库的功能即可熟练掌握。磨练工艺的机会很多，有些死了，有些很有创造力。

这都是关于资源的。几年前，如果您为大型主机开发软件项目，则它们可能会存在大约15年左右的时间，并且具有很大的静态开发环境。数十年来，FORTRAN程序用于计算工资单或COBOL程序是完善的，因为它一直在被使用。有资源可以查看如何进行改进。我们不再需要那种缓慢的环境来微调和完善特定项目的技能。但是，我们确实采用了这些技能，并使其适应下一个项目资源的允许。但是最后如果选择花在新项目上的钱来做这项工作，或者用大量镀金来做新工作成为一种选择。将项目镀金意味着将其提高到第n级，即使用户没有这样做，也要添加大量的铃声和口哨声。

我们能做的最好的事情就是看一个新项目的总体设计，并根据团队的过去经验来研究如何对其进行改进。但是需要真正有经验的软件架构师来了解如何真正考虑改进设计以提高技能，而不是简单地将最新的流行语（例如敏捷，OOP等）包含在内。