敏捷：开发人员可能忘记的部分考虑它的重要性。敏捷实践已在全球范围内采用。许多企业都以敏捷而自豪，并以不同的方式实施它。这很好，但没有单一的方法可以做到这一点，需要针对每种情况进行调整。根据高级软件工程师JorgeFernándezRodríguez的说法，过于关注敏捷的一个方面很容易忘记另一个关键方面。这不是什么新鲜事，但如果没有这个方面，发布新版本的软件可能是一个永无止境的故事。这是本文要解决的问题。但在深入研究之前，让我们回顾一下软件开发的演变，从瀑布和敏捷方法论的诞生开始。1.很久以前就采用了瀑布许多在过去10年开始其职业生涯的开发人员可能在敏捷环境中工作过。然而，敏捷性并不总是存在。在2000年代初期，瀑布是一种常见的做法。在瀑布式方法中，应用程序通常作为一个整体进行规划，客户可能需要几个月的时间才能看到一些可用的软件。开发计划作为一个项目进行，理论上有开始就有结束（有时可能是公司失败）。该项目分为以下几个阶段：需求收集系统设计任务规划开发测试和交付每个阶段通常由不同的人执行。客户在开始和结束时都参与了合同的签署。如果项目成功完成，应用程序将部署到生产环境，并且通常会移交给另一个负责保持正常运行的团队。众所周知，这些做法造成了许多问题。其中一些是：收集所有需求、预先设计系统和规划任务几乎是不可能的，而且需要数周时间。每个阶段的交接都会导致沟通不畅。产品交付时间长，实施多次，远超预期。在预算和范围内关闭也很困难。阶段之间没有反馈循环。很多时候，反馈只会在最后才出现。如果反馈是负面的，那么整个投资就失败了。2.敏捷解决关键问题Rodríguez说，在他刚开始职业生涯的时候，他听说了一个新概念：敏捷。我当时不知道发生了什么事。那时他专注于提高自己的开发技能，并不太关心软件开发方法论。敏捷似乎解决了很多瀑布法难以解决的问题，很快就被采用了。但很多人将其视为教条，认为采用几个套路就可以解决所有问题。行业专家听到最多的流行语，如：“Scrum”、“极限编程(XP)”、“Sprint”、“复古”、“修饰”等（后来证明与精益更相关），例如看板,进行中的工作(WIP)。这些流行语中的大多数本身并不能说明什么。工作了一段时间后，他对了解为什么许多企业采用这些做法产生了兴趣，于是他开始深入研究这个话题。他在工作中理解了其中一些术语的含义，并看到了很多讨论：开发团队应该采用Scrum、看板、极限编程(XP)还是其他方式？团队应该在每个Scrum的每个例程上花费多长时间？应该谈什么？etc.他知道一些肤浅的信息，还有一些信息被遗漏了。也许是他的研究能力。回过头来看，我发现不仅如此。在阅读敏捷宣言时，他理解的一件事是：“个人和交互高于流程和工具”。在他的工作过程中，给人的印象是过于注重过程和惯例。这是谷歌的算法和部分软件行业都在关注不太重要的话题的第一个迹象。还值得澄清的是，有些人将这些原则解读为“第二部分无关紧要”。然而，正如他多次听到的那样，这些原则应该被解读为：“第二部分虽然重要，但第一部分更重要。”专注于敏捷的本质，与瀑布的主要区别之一是增量开发的组织方式：应用程序将被划分为具有优先级的小块。每个块都是在一个Sprint内开发的（通常是1或2周）。在每个Sprint之后，应向客户提供应用程序的功能版本。客户（或者，在某些情况下，业务代表）积极参与该过程，因此可以尽早获得反馈。可以看出这些想法如何解决瀑布方法中出现的一些问题，瀑布方法通过快速交付和及早获得反馈而很快失败。而在敏捷宣言中，价值观之一就是“欢迎不断变化的需求，即使是在开发后期”。起初，罗德里格斯无法理解这句话的意思，他不确定这是否是个好主意。然而，在思考和在敏捷环境中有不同的经验之后，他认为这是最重要的部分之一。重要的是要考虑到变化可能涉及该领域的新特性和概念，但也可能涉及现有行为和市场的变化等。因此，在敏捷中快速行动不仅很重要（尽早交付客户需要的价值，失败快速反馈），而且对环境变化做出快速反应。它们不是唯一重要的方面，但下面将重点介绍这两个方面。因此，继续软件开发实践的这种演变，提到一些主要有助于快速开发的改进。3.快速行动：软件编码和交付实践的演变当时的工具并不能使采用频繁部署等敏捷实践变得容易。在过去的25年中出现了一些实践和技术来帮助开发团队更快地发布软件。其中一些是敏捷的结果，而另一些则是独立出现的。Rodríguez简要提到了其中一些技术及其好处，但没有详细说明。他认为大多数是众所周知的技术，但如果它对人们来说是新的，则可以通过大量在线资源找到更多信息：测试自动化通过防止大量错误和减少调试需求，让开发人员充满信心。版本控制可帮助开发人员追溯更改的添加时间、轻松还原更改、更轻松地解决冲突，并且它是许多其他改进的基础。特色分支或与分支并行工作。并行总是好的，但在很多情况下这也带来了一个新问题：当进行大量更改或长时间保持分支打开时，开发人员需要花费大量时间来集成这些更改。功能标志。如果团队需要长时间并行处理多个计划，但希望避免长寿命分支经常发生的冲突，则这是一个选项。持续集成(CI)/持续交付(CD)。通过集成变更、运行测试和经常部署，交付到生产的巨大障碍正在消失。代码审查/结对编程。多年前，每个开发人员都在开发自己的代码，甚至是关键代码。审查代码不仅可以帮助开发人员更好地编写代码，还可以分享知识、学习并减少遗漏重要内容的机会。Rodríguez认为这并不总是必要的，但与在长期存在的分支上进行大量拉取请求相比，它可以提供优势，因为在编码时会提供反馈，避免重写代码。开发人员构建并运行它。开发团队还负责维护应用程序。这是有道理的，因为开发应用程序的团队比其他任何人都更了解它，并且它带来了几个好处：更少的时间来发现问题。解决问题时少犯错误。在生产环境中处理问题会带来宝贵的经验。这些都有利于进一步发展。这节省了大量时间，因为不再需要交接会议。如果团队随叫随到，软件的质量会进一步提高，因为每个人都会尽最大努力避免在不适当的时间被联系。团队结构的变化：组建小型、独立、跨职能的产品团队，打破IT孤岛。消除开发阶段之间的交接可以加快交付速度并避免沟通不畅。让团队更接近领域专家将对解决方案的质量产生积极影响，并通过减少场景切换等方式增加关注度。它还促进了系统的模块化（康威定律）。需要注意的是，跨职能人员并不意味着全栈人员，Rodríguez认为这非常困难，甚至会适得其反。“T型开发者”的想法可能更有趣。DevOps、容器、服务网格、分布式架构和云平台。基础架构变为自助服务（团队无需等待服务器分配即可部署）。它还变得不可变、易于替换、提高安全性等等。自动依赖更新。更好的监控和事件管理，例如SLI/SLO、DORA指标和其他，以关闭反馈循环并做出更明智的决策。除了这些实践之外，新工具、IDE改进、框架、库和语言演化使开发人员能够加速软件开发。如果企业采用上述大部分做法，则可能意味着可以比以前更快地交付软件。而且这些变化不仅更快而且更安全，因为许多任务是自动化的或委派的。有些人可能认为软件交付快如闪电，对吧？根据Rodríguez的经验，即使遵循了这些做法，也可能需要很长时间才能实现价值。以下是一些示例：示例1：Rodríguez表示他花了三天时间才理解必须更改的代码。这是他第一次接触那个代码。值得庆幸的是，他正在与非常了解该应用程序的人一起工作。开发团队花了两周的时间来实施重大更改并进行相应的测试。最后，他们花了大约16周的时间寻找错误并在整个代码中实施修复。可以看出，第三点花了不少时间。在这16周内，大约70%的人在寻找错误，大约20%的人理解开发人员发现的逻辑并思考如何使其适应新的行为，3%的人编写自动化测试，1%的人自己进行更改.以下是花费这么长时间的一些原因：该服务正在做太多事情。代码耦合非常紧密，因为很多问题发生在代码的不同部分。同时，代码的内聚性不是很好。处理同一问题的逻辑广为流传。示例2：Rodríguez表示，他们的研究团队花了三天时间了解需要更改的内容，一天时间实施这些更改，七天时间让测试再次通过。在这种情况下，开发人员正在修复代码中的先前错误。其中一些甚至没有完全修复。显然，一些开发人员对这些技术还不够熟悉。幸运的是，问题并不严重，客户没有注意到。更糟糕的是，当应用新的更改时它们会弹出，使得测试几乎不可能，因此必须在工作完成之前修复它们。另一个问题是堆栈不是最新的，开发团队想要实施的许多解决方案都不起作用。在这些情况下，可能会看到大量时间浪费在调试和理解需要调整的代码上。除此之外，还有可以永远运行的构建通道（同一应用程序中的大量代码、缓慢或不稳定的测试等）。4.被遗忘的部分是……围绕软件开发采用许多实践可以使其更快：敏捷、CI/CD、DevOps、团队结构等。但是在更改现有代码的同时保持现有代码的工作可能是一场噩梦。很多时间仍然浪费在理解代码和四处寻找错误上，尽管那里有很多有用的实践。同时，围绕Scrum、看板、独立团队等存在很多争论，并且如上所述，敏捷宣言并没有过多地关注特定的过程或仪式；它只是给出了一些一般性的想法。所以代码（测试）质量（尤其是灵活性）是敏捷中被忽视或遗忘的最重要的部分之一。代码质量不是Agile独有的问题，但它在这里尤为重要，甚至比在传统项目中更重要。还有一种误解，认为在敏捷方法中，不需要对软件架构和设计进行任何计划或努力，但事实恰恰相反。代码经常被扩展和调整，所以让系统易于更改是至关重要的，否则它们会使未来的开发非常缓慢。因此，对于敏捷开发，这句话的下一个迭代可能是：系统灵活性是敏捷中被忽视或遗忘的最重要的部分之一。这不是什么新鲜事。如上所示，敏捷宣言中提到了这一点，但持续关注技术卓越和良好设计可以提高敏捷性。敏捷过程促进可持续发展。赞助商、开发人员和用户应该能够无限期地保持恒定的速度。如果代码混乱、难以理解和更改，团队如何保持一致的步伐？要记住的是，质量并不意味着复杂。简单也很重要：简单是最大化未完成工作量的艺术。架构通常与刚性和提前计划相关联，因为通常会想到难以更改的架构。从这个角度来看，在敏捷环境中花时间在架构或设计上是没有意义的，因为事情经常变化。但在软件世界中，可以选择一些架构，让选项保持开放状态并使更改更容易。事实上，敏捷提倡短期思维。众所周知，预测并不容易，开发人员最终会在不知道两天后客户需要什么的情况下付出代价。对于不采用敏捷方法的开发人员，重要的是要知道高绩效者不必以速度换取稳定性，反之亦然，因为通过提高质量，您可以实现两全其美。5.开发缓慢的后果随着开发人员添加更多代码，开发变得更慢，这不仅仅是开发人员的问题。每个利益相关者都以自己的方式说话，并且含义略有不同：对于用户体验(UX)实验爱好者：实验可能需要数周而不是数天。对于产品爱好者：及时响应市场/满足客户需求……会发生吗？对于管理者：目标缺失，工作积压。对于DevOps研究和评估(DORA)指标爱好者：部署频率(DF)降低，平均变更提前期(MLT)增加，变更失败率(CFR)增加。对于企业：即使开发人员有绝妙的想法，如果不能轻松将其转化为软件，企业也会举步维艰。代码将成为一种负担而不是一种资产，同时，竞争对手可能会利用它。对于开发人员：不得不处理糟糕的代码可能会导致开发人员精疲力竭。所以显然开发会慢一些，但幸运的是，如果你投资于灵活的代码，你可以节省一些时间。然而，要说服其中的一些人并不容易。还有一个问题：死板代码的效果不是立竿见影的。从长远来看，它们是可见的。在短期内投资于开发灵活的代码可能看起来更慢。那么，谁愿意投资那些没有立竿见影效果的东西呢？很多人的想法大多是短期的，需要更多地了解代码质量将如何影响未来的发展。6.将僵硬的系统对业务的影响联系起来僵硬的代码对开发某个产品所花费的时间的影响是不容易察觉的。因此，对业务的影响并不明显。如果两者之间没有联系，就很难让人们相信拥有灵活系统的重要性。这是一个非常复杂的话题，但需要填补空白。DORA指标至少部分解决了这个问题。它的代码不是同质的，代码路由很慢，而且问题可能发现得太晚了。软件架构师GlennEngstrand的技术能力计划(TCP)在他的演讲中介绍了在微服务架构中管理技术债务，这可能是一个起点。Rodríguez说他没有一个理想的解决方案，梦想在每次提交后更新一个分数，并且可以用作乘数来估计未来任务需要多长时间才能完成。但是，我想以一些关于如何提高代码灵活性的简单想法作为结尾。7、提高代码灵活性的思路网上关于代码质量的书籍和资源很多，这里不再赘述：代码需要通俗易懂。通过阅读方法名称，应该清楚它是做什么的。例如，理解一个方法不应超过10秒。代码需要模块化。模块、松散耦合、封装。这适用于每个级别：系统、库、包、类和方法。代码需要具有凝聚力。每个部分只需要做一件事，所有做那件事的代码都需要紧密耦合。将业务逻辑与控制器、监听器、过滤器等框架结构分离尤为重要。代码需要简单（不要过度工程化，不要强行设计模式）。为当前需求而开发。当开发人员思考：“如果我们需要功能X怎么办？”，请使用YAGNI。对于测试，您需要记住它们提供安全性，但它们抗拒更改并且可能比生产代码本身占用更多时间，因此：它们需要带来足够的价值。进行测试驱动开发（TDD）是一种可以帮助企业实现它的实践。如果他们测试实施细节，他们将很难改变。许多单元测试来验证提供内部结果的代码片段。这些代码是开发人员组织代码的结果。如果需要以不同方式组织和移动逻辑，许多测试就会中断。发生这种情况时，测试不再具有保护作用，几乎毫无用处。它还为团队提供了额外的工作。因此，重要的是要考虑什么是实际单位。在不得不多次重组代码后，Rodríguez表示他一直在思考这个问题，开始认为单元的概念可能不仅仅是一个方法或者一个类，可能需要从特性的角度来考虑.这听起来可能很奇怪并且类似于集成测试，但事实并非如此。支持更简单、更快速的测试：单元优于集成。考虑应用层的集成；集成测试应该处理单元测试中无法验证的事情，例如与框架的集成。默认情况下，并非每个功能都需要端到端测试。它们对于可能危及生命的功能非常重要，在这些功能中，个人身份信息(PII)至关重要，可能会使企业损失大量资金，或类似的事情。8.结论如果开发人员需要频繁引入变更，保持系统的灵活性至关重要，就像在敏捷环境中一样。否则随着时间的推移，合并更改将变得越来越困难。其他做法将有助于暂时弥补这一点，但最终它们的影响不会那么明显。很多时候，帮助开发人员保持代码灵活性的做法非常容易应用。每天都有更多的证据支持这样一个事实，即质量有助于保持持续的发展步伐。此外，还出现了一些新的想法，可以将刚性代码在业务中的作用联系起来。原文链接：https://dzone.com/articles/agile-forgotten-parts
