软件开发的阴阳
基础设施元素如何使开发团队在不限制创造力的情况下提高生产力
MIKE VIZARD：大家好，欢迎收听由 Mike Vizard 主持的 cast 的另一期高级版。本期节目由 Parasoft 赞助播出，Parasoft 是自动化软件开发流程管理工具的领先供应商。
今天加入我的是 Parasoft C++ Plus 的解决方案经理 Sergei Sokolov，我们将讨论应用程序开发的阴阳，以及如何为本质上由创新驱动的过程带来一些结构。
Sergei，欢迎来到节目。
SERGEI SOKOLOV：很高兴来到这里，Michael。
MV: 那么这里想到的事情之一是，当将阴阳的概念应用于应用程序开发时，每个人都认为这全是阴，而没有阳。创新没有真正结构化的方法，因为这完全是人们头脑中的左脑活动。那么，您真的可以将某种结构应用于应用程序开发过程，从而真正提高生产力吗？
SS: 这是一个相当困难的问题，因为软件开发显然有一段历史，很多人认为软件开发是艺术，实际上我们在 Parasoft 有些人就是这么跟我说的。
同时，我认为软件开发本身所涉及的任何创造力都可以从结构中受益，而其根源在于，软件开发实际上并非完全是艺术。其背后的思考过程实际上是艺术，但是在获得知识并需要将其放入软件之后，有很多机械性的东西要做，而这些机械性工作就是编写代码、构建代码、测试代码、确保其他人理解您编写的代码等等。
因此，虽然即使这是一个单独的主题，也很难将结构融入思考过程，但是一旦想法成熟，肯定可以在实现过程中加入相当多的结构，我认为这就是结构在软件开发中的位置。
MV: 有没有办法提出一些简单的步骤，概述人们应该定期检查的一些事项，例如在项目上应该做的五六个最佳实践，以提高生产力？
SS: 意见各异，但显然，如果您尝试建立结构，那么最好有一些简单的步骤，以便人们可以掌握并将其简化为计划，而不是进行漫无目的的追逐。
Parasoft 作为一个组织已经在软件行业工作了 20 年。因此，我们当然积累了相当多的关于哪些方法有效，哪些方法无效的知识，事实上，我们已经提出了一些要素，如果您愿意的话，这些要素确实有助于提高生产力，并且通过对那些经常困扰人们的非常机械的方面施加一些结构来实现。
我们认为，高效开发的基本平台是五个步骤，或者您应该说是五个组成部分。它们基于我们自己的经验——正如我所说，这是非常广泛的——以及参考了过去 20 年左右行业内进行的一些研究，看到如果人们开始做某事，并且他们试图从中赚钱，这在软件领域就是这种情况，他们试图找到更经济、更高效、更高效地完成工作的方法。
因此，可以理解的是，有很多研究。
因此，回到这个问题，我们认为必不可少的事情首先是构建或每天构建软件的基本能力。当我与客户、潜在客户以及技术展会的参观者交谈时，令人有点不安地意识到有多少工程团队没有定期构建。
他们认为，只要他们可以按需生产软件，他们就会没问题，但这不是一个受控的过程。
因此，基本的构建步骤，构建基础设施，是第一个要素。我们可以更详细地讨论一下我们在定期构建方面实际寻找什么。
一致的编码有所帮助，因为这是将思想转化为代码的基本过程。一致的编码有两个好处，一是其他人可以阅读您编写的内容，因为软件代码只不过是被捕获的知识，如果您想将知识传达给他人，就像写文章一样，您最好以其他人可以理解的方式编写。另一方面，语言中的一些基本习惯用法和最佳实践，无论是 Java、C++、C Sharp 还是人们使用的任何其他语言，如果他们可以始终如一地使用某些模式，那么他们可能会更好地更快地将他们的想法转化为代码，因为他们会使用他们习惯的东西。
一旦代码编写完成，检查代码是否正确或可能完整的最佳形式是代码审查。让团队中的其他人以比喻或字面意义上的方式查看您的代码，并说，嘿，我在这里做对了吗？
因此，代码审查——定期的代码审查，一致的代码审查——是我们的第三步。
一旦代码被粗略检查过，并且看起来没问题，那么尽早进行测试，尽早测试，就可以将您带到更高的生产力水平。我们一直发现，这不仅是我们的经验，而且还得到了许多研究的证实，即编写代码、组成应用程序，然后将其交给其他人进行测试的做法通常不是那么有效，因为人们在该阶段发现的是相对复杂的用例相关错误，并且将这些错误追溯到可以更改以修复效果的几行代码非常复杂且耗时。
有各种图形表示，表明等待测试的时间越长，成本就越高，有些人说，在编码时修复问题与在 QA 的后期阶段修复问题之间，成本相差五倍，有些人说相差 100 倍，当然，这可能取决于项目的性质等等，但没有人否认存在差异。
因此，您越早测试，您就可以越经济地检测到问题，并且实际上您可以更快地完成代码。我刚从我们的一家大型客户那里完成培训回来，那里有一位同事正在讨论单元测试，我问听众过去谁做过单元测试，有一些人实际上非常精通单元测试，他们说，通过单元测试，这是一种早期测试形式，他们可以清楚地看到，如果他们正确地进行单元测试，那么他们在完成软件时就不会加班。软件可以工作，他们可以很好地预测它何时会完成。
对我来说，这是高生产力的一个症状，因为您可以更正确地估计您何时完成，并且您可以确定您将在不每天工作 12 或 16 小时的情况下完成。
最后，一旦我们克服了早期测试这个主题，我们就进入了通过回归进行自动化。同样，关于回归测试的一个有点错位的概念，最近指出由 QA 团队在周期后期，当软件准备就绪时进行测试，并且他们针对给定的版本进行测试。因此，版本 1 发布，他们进行此测试周期。他们验证版本是否按照规范工作，然后在六个月后，发布版本 1.1，他们在接下来的六个月结束时进行相同的周期，他们称之为回归测试。
他们确保版本 1.1 需要像版本 1.0 一样工作，并且确实如此。
这两个测试会话之间基本上有六个月的间隔，当然，在这两个会话之间发生了许多事情，当然，如果功能发生变化，回溯功能更改的原因非常困难。
我们对回归测试的概念是持续回归测试或每晚回归测试。因此，除了我们希望每晚完成的构建之外，我们还鼓励人们每晚运行回归测试，因为这使他们能够每天检查代码的一致性。
您不可能想出比这更有效率的东西，因为如果有人犯了一个错误，并且某些功能被破坏了，那么您第二天就会知道发生了这种情况，而不是两、三或四个月之后。
因此，解决这些影响的周转时间显然比在最后一刻发现这些影响要短得多。
MV: 那么，这一切听起来都很基本。是什么阻止组织实际实施这种结构？仅仅是简单的惯性吗？还是软件开发的性质中有什么东西，也许是团队协同工作的方式，阻碍了每个人？
SS: 这可能是关于软件开发的最重要的问题。是什么阻止人们做得更好？我认为存在一种对变革的根本性污名。人们显然有不同的背景，但不幸的是，鉴于软件开发的历史，开发人员通常来自没有结构的团队。
我非常幸运，我开始工作的第一家公司是一家非常小的公司，只有五个人，在从马萨诸塞大学获得硕士学位后，碰巧实施了许多这些最佳实践。每晚构建、回归测试、一些早期测试和代码审查。
因此，我很幸运从早期就接触到了它，而且在我工作过的其他组织中，我也没有看到什么太大的不同。也许这就是我选择我工作过的组织的方式，也许这就是他们选择我的方式，但并非每个人的道路都像我一样，当有人呼吁做一些不同的事情时，人们总是会想出我为什么需要做一些不同的事情？
哦，实际上看起来会更费力。例如，如果您进行单元测试，它看起来像是做了更多的工作。
您以前没有做过测试。现在您需要做测试。您必须编写更多代码。您必须检查结果。哦，我们的项目要迟到了。当然，这与事实相去甚远，因为您投入到早期测试（在本例中）的时间投资，您最终会获得巨大的回报，当您不必每天工作 15 个小时时，正如我所说，行业中有很多例子表明确实发生了这种情况，但我认为仅仅是对变革和惯性的基本抵制是始终如一地朝着这个方向前进的根本障碍之一。
MV: 然而，这里存在真正的成本，因为绝大多数应用程序开发项目都迟到了，当它们迟到时，通常会在其基础上增加成本。那么，有没有办法衡量这一点，或者考虑您的投资回报率是否过时，在应用程序开发过程周围建立更多的结构？
SS: 坦率地说，我还没有看到可以应用的单一可靠的 ROI 公式。但这并不意味着没有 ROI 研究。对吧？例如，如果我们与潜在客户交谈，他们要求 ROI，我们过去采取的第一种方法是，好吧，让我们构建一个复杂的电子表格，并尝试插入一些参数，包括每个缺陷的成本和预期的缺陷数量，并得出一个数字，我不知道，每个项目 80,000 美元或 200,000 美元，然后您从那里倒推。
我认为有一种更好的方法，更好的方法是案例研究。
因为案例研究不是模型。它们是真实的东西。当我们有一个案例研究，例如我们最近来自菲律宾 NEC 的案例研究时，他们是一个实施了 C++ 测试的团队，并且报告说在项目过程中生产力提高了大约三分之一。这是一个真实的 ROI 示例，虽然对于给定的组织，可能会有一些变化——也许他们会获得 25%，也许他们会获得 40%，也许在那个范围内——但有人做对了事情并且他们的生产力提高了 30% 这一事实是无可争议的。
因此，我认为人们需要改变他们对 ROI 的看法。他们需要将案例研究作为良好事情发生的证明，然后基于这种信念，在他们自己的环境中尝试一下，并仔细衡量指标，并提出他们自己的 ROI 评估。
MV: 鉴于所有这些，Parasoft 软件实际上是如何在实践中工作的？有哪些组件？有哪些要素？
SS: Parasoft 软件为我们谈论的大多数实践提供自动化——代码分析、代码审查、早期测试和回归测试以及上述所有内容的报告。
当然，根据这些实践中哪些对给定的组织更重要，我们可以以不同的方式构建软件，但在基本层面上，我们的每个工具都是一个系统，它包含组件，解决这些特定步骤。
例如，对于语言工具，我们有 C++ 测试、4C 和 C++ J 测试用于 Java、JSP 以及用于 dot-net 环境的 dot 测试，所有这些工具的结构都非常相似。它们都有一个代码分析组件，该组件由大量编码规则组成，这些规则源自最佳实践。这些有助于与团队建立一致的编码模式。
还有一种更复杂的代码分析形式，它依赖于路径刺激，并尝试根据程序在现实生活中可能看到的不同数据来识别可能的错误。因此，这都处于代码分析的层面。
我们有一个用于自动化代码审查的组件。显然，它不会自动审查您的代码并给您结果。那将是一个非常困难的问题，但同样，我们试图做的是通过自动化平凡的事情来启用创造性方面，这几乎是我们所有工具的核心主题。对吧？如果您加快重复性元素，您基本上可以提高生产力。
因此，对于代码审查，我们有软件可以跟踪代码更改，向开发人员显示差异，允许他们注释他们的评论，然后跟踪代码审查问题的状态，直到它们完成。
所有这些事情在代码审查中都很薄弱，因为它们往往没有非常一致地完成，如果某些事情没有一致地完成，生产力通常会受到影响。
我们通过我们的工具支持早期测试，如单元测试和组件测试。无论人们选择使用什么，都取决于他们的开发状态。我们有用于测试的自动生成器，可以根据代码结构生成测试，并将所有测试基础设施（测试驱动程序、单独的测试）以结构化的方式就位。
我们有覆盖率分析，基本上可以衡量测试对代码的覆盖程度，并指导人们在必要时改进测试。
因此，同样，这基本上解决了平凡的问题。我估计，实施单元测试大约一半的时间用于运行测试驱动程序并确保它是所有可以从不同机器重新运行的结构等等，而工具可以处理它，从而为人们留下更多时间来实际进行测试，即分析用例并在软件中进行相应的调用，与他们的架构和算法相对应。
最后但并非最不重要的一点是，就回归功能而言，我们所有的工具都实现了自动化。因此，无论您有什么测试，您都可以运行，可以在每晚的界面上处理，并通过 HTML 或我们的报告系统获取报告，该系统使您可以跟踪您每天的进展情况。
因此，我们确实尝试涵盖我们认为基本的所有步骤。
MV: 设置这样的东西有多困难？人们会为此挣扎吗？还是相对简单直接？
SS: 不，这相对简单直接。事实上，我们的语言工具目前是 Visual Studio 和 Eclipse 这两个最重要的 ID 的完整插件，从这个角度来看，人们基本上没有门槛。如果您在 Visual Studio 中工作，一旦加载项目或解决方案，我们就会开始工作。如果您在 Eclipse 中编写 Java，那么基本上我们就在那里作为一个插件，并且在您编写新类后，您可以进行分析，您可以对该类进行单元测试，您可以保存测试并将整个内容放入源代码控制中。
Eclipse 实际上正在成为嵌入式开发的驱动 ID，因此解决方案和供应商向其整合的趋势非常明显，我们非常欢迎这一点，因为我们现在可以为多个环境提供一个解决方案，而嵌入式行业以环境的多样性而闻名。这将适用于大多数人，并以与他们在 ID 中拥有某些东西相同的方式为他们带来价值，他们可以获得插件，例如 C++ 测试的形式，并且他们可以立即开始使用此插件。
MV: 构建这样的东西相关的成本是多少？是极其昂贵，还是几乎任何组织都能负担得起？
SS: 非常有趣的问题，在组织中实施此类解决方案的价格实际上有很多组成部分。我以前在电子设计自动化行业工作，该行业生产用于设计电子芯片的软件，众所周知，决定整个软件包价格的不是工具的成本，而是将所有工具缝合在一起的成本。
因此，实施来自不同供应商的所有工具的成本通常比这些工具的成本高出两到三倍。
好吧，对于软件工具、ID 和桌面的标准化，幸运的是，常规软件开发并非如此。因此，就组织成本而言，除了仅仅购买 Parasoft 软件或其他人的软件（如果这有助于降低成本）之外。维护基础设施、维护流程以及关注流程的成本是不可忽视的。但这与软件成本相比相对较小。
至少根据我们收到的回复，我们的软件价格合理。它不便宜，因为好的东西不便宜，但同时，我们也没有被告知我们非常昂贵。
MV: 那么，对于那些想要为应用程序开发流程带来一点结构的人，您最好的建议是什么？只是为了让事情开始启动和运行，以及如何打破第一层惯性？
SS: 我认为我能给出的最好建议是不要试图在第一天让一切都正常工作，因为任何事情都不会在一夜之间发生。即使在 Parasoft 内部，显然我们在营销这些实践之前已经积累了多年的整合这些实践和开发流程的经验，我们也看到了非常渐进的采用曲线，这与开发生命是多维的有关，因此您必须确定在当前阶段能够带来最大收益的步骤，对于不同的人来说，这可能是不同的。
这取决于软件的状态，无论是从头开始编写的软件，还是正在增量开发的软件，还是遗留代码的维护，因此路径可能不同。
我对每个人的标准建议是，如果您没有每晚构建，请将其就位。看到除非您可以定期构建软件，否则其他一切都无关紧要。
过了这一点之后，基本上，我们提倡的另外四个步骤或多或少按照我们建议使用的顺序排列，但当然可能存在变化。
例如，如果它是一个精益组织，他们没有太多资金可以支配，那么基本上只需进行定期构建并建立代码审查流程，就可以让他们完成一半以上的工作，以生产无缺陷的软件，因为如果正确执行代码审查本身，平均分析可以发现 60% 到 70% 的所有缺陷。
如果该实践到位，并且渴望引入更多自动化，那么代码分析肯定是下一步，因为它通常非常不具侵入性，可以在每晚的基础上完成，而无需太多用户干预，并且有助于代码审查。因此，您正在加入一个组件，通过更专注于代码审查，消除诸如您是否符合编码指南等问题，使最佳的错误查找练习代码审查更有效？
您是否以适当的方式编写 C++，并专注于算法？然后转向测试。
MV: 这是 cast 的另一期高级版，由 Parasoft 赞助播出，Parasoft 是自动化软件开发流程管理工具的领先供应商。有关更多信息，请访问 www.Parasoft.com，我想感谢 Sergei 分享他的知识和建议，Sergei，我们祝您一切顺利。
SS: 非常感谢您。我很荣幸能参加这个节目。
最初发表于 Queue vol. 5, no. 4—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但它们的设计方式似乎存在差距。出于各种安全需求，存在许多针对加密哈希的标准，但在非加密方面，存在一定数量的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚的 whims 的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的经过验证的解决方案。用例于 1986 年首次引入，后来被普及，是这些经过验证的解决方案之一。
© 保留所有权利。