在软件开发中，可能慢才是快

Java学研大本营

已于 2022-09-04 10:20:26 修改

阅读量745

点赞数

文章标签： java 数据库开发语言

于 2022-09-04 10:10:18 首次发布

本文链接：https://blog.csdn.net/u013643074/article/details/126686169

版权

慢下来，是一种哲学。

扫码关注《Java学研大本营》，加入读者群，分享更多精彩

关键要点

匆忙使我们既不会更快，也不会更有效率；它会增加压力并分散注意力。我们需要创造力、有效性和专注力。
聘请更好的人才，一起做，一起实践，一起学习，以提高您的组织的专业性和工匠精神。
通过制定计划并经常修改计划、收集和分析并消除浪费，提高团队的适应能力和流程的效率。
没有高质量的代码库，你就无法敏捷。下推缺陷，频繁发布，先测试再重构，专注于简单设计。
工作软件不一定要精心设计。只有优秀的专业人员才能构建出精心制作的软件，而只有精心制作的软件才能让您比以往更快地构建。

在没有控制的情况下快速发展可能是软件开发的最大敌人。您应该放慢速度的三个主要领域是人员、流程和产品。在深入细节之前，让我先讲一个故事。

2011 年，我加入了一个负责构建在线营销平台的团队。我的主要职责是尽可能快地向系统添加新功能。我是高级开发人员。当开发人员能够比其他人更快地开发时，我们称他们为“高级”，对吧？但是当我加入时，我们注意到由于技术债务和设计挑战，几乎不可能走得快。每一次尝试更快，我们注意到我们增加了复杂性并破坏了质量。在我看来，加速的唯一方法就是从头开始重写整个系统。

我记得，我打电话给产品经理说我们需要重写整个系统。电话那边沉默了 30 秒后，项目经理回答说：“你是说你的团队写的产品质量太差了，同一个团队不得不再次重写同一个产品，但这次更好。对吧？对不起，伙计，这是不可接受。你应该写得更好。”

僵尸软件需要一次又一次地重写

根据 Standish Group 的 Chaos Report ，94% 的软件项目不止一次从头开始重新开发。那是巨大的。同样，当我查看我过去从事的产品时，我发现几乎所有产品都是用更新的技术、架构和设计从头开始重写的。重写在该领域非常普遍，以至于企业公司通常将其视为项目管理和创新的唯一选择。我们一次又一次地写作，重写和重写。

我们必须了解我们在软件开发中最大的敌人。在软件世界中，快速是至关重要的。不仅在市场上抢占先机很重要，而且通过添加新功能和快速消除错误来响应客户，从而保持高客户满意度。但我们都有一个“速度”的问题。我们认为更快、更聪明、更有效地与为目标设定期限有关。我们认为通过更多或与更多人合作，我们会更快。因此我们要么增加新人，要么加班以加速生产。匆忙使我们既不能更快，也不能提高生产力。匆忙会增加压力，分散注意力并破坏生产力。我们需要创造力，效率和专注力。

软件开发非常困难和复杂。我们无法摆脱复杂性。因此，我们必须忍受它。对速度的需求创造了一个不稳定、不可持续的环境，使我们压力大、注意力不集中、效率低下。它只是行不通。团队能力、总体规划、估算、固定工作时间、截止日期和速度概念是虚构的；无能是现实。交货时间直接取决于人员的技能、流程的效率和产出的质量。大多数时候，开发人员为自己设定了隐藏的最后期限，而没有任何真正的需要。

归根结底，我们得到的是遗留软件。截止日期的压力加上无能导致遗留软件，工作软件的死胡同。一段时间以来，我一直在为遗留软件使用不同的术语：僵尸软件。僵尸软件更适合，因为这种软件实际上已经死了，但似乎还在生产中。它在生产中起作用，人们从中获利，但它需要软件开发人员的血液、生命和精力才能以某种方式继续工作。开发人员太害怕触摸它，因此如果它有效，没有人愿意改变它。

Robert C. Martin 在 twitter 上对遗留软件的症状有一句完美的说法：“如果你的软件越来越难开发，那你就做错了。” 在匆忙的同时，我们正在破坏质量，以至于我们前进的每一步都会使整个进度和流程比以前慢。我相信放慢速度直到我们达到可持续的页面是加快速度的唯一途径。

匆忙在软件开发中是邪恶的

正如 Robert C. Martin 在 CleanCoders 关于软件的主要价值所提到的，“软件系统容忍和促进这种持续变化的能力是软件的主要价值”。在软件开发中，匆忙是邪恶的。任何匆忙的尝试都会导致戏剧性的后果生产力、注意力、人们的效率、适应能力和软件容忍度的损害。

例如，我们总是有时间修复错误，但没有时间编写测试。我们不重构和编写测试，因为我们没有足够的时间。但是我们有时间进行调试、修改代码和修复错误。

我们非常关注流程，以至于我们经常忘记软件开发中的主要资产：人。流程帮助人们改进他们制造产品的方式，增加动力并营造健康的环境。最后，流程的效率很重要，但人是至关重要的。

我们不得不承认，没有人也没有什么是完美的。客户、老板、经理、队友、商务人士，甚至你自己，都远非完美。需求、文档、工具、代码、您构建的系统和设计，也永远不会是完美的。因此，我们必须停止无节制的奔跑和加速。以可持续的速度加快速度的唯一方法是在三个重要领域放慢速度：

提高专业水平和工艺的人
提高适应性和效率的过程
用于提高自动化和质量的产品

涉及到人的地方要放慢脚步

流程和工具不会构建产品，但人会。我们不得不承认，“人才招聘”是一个组织最重要的功能。它直接影响到公司和产品本身的未来。

为您的组织雇用最优秀的人才。我所说的“最好的”并不是指周围最聪明或最有经验的人。我至少要寻找激情、纪律和动力。如果这三个技能都存在于一个天赋中，那么其他技能可以轻松成长。招聘是一个双赢的过程，所以双方都应该从这个过程中获益。因此，您应该放慢招聘过程并投资于改进它。人们加入他们相信的公司。因此，对您希望看到的行为进行建模。并通过您的公司文化、愿景和人员，让人才相信您。

自我是一种氰化物，会慢慢杀死你的组织。永远不要让自我进入组织的大门。从可爱的傻瓜到天才混蛋，永远不要让极端情况加入你的团队。永远不要雇佣自负的人。有了这些人，你永远无法建立一种人们钦佩的公司文化。

停止单独工作，开始一起工作。永远不要让孤岛发生，因为孤岛或英雄开发者是功能失调组织的症状。坐在一起，紧紧的。共同定义团队标准。成对和成群结队地工作；一起回顾。让责任在团队中分担。

一起练习是提高技能的最有效方法。在合作的同时，我们不仅能激励人们，还能互相学习。在您的团队中定期组织代码务虚会、随机活动和编码道场。每个工作日花 30 分钟来练习。

让知识在人与人之间流动。一起学习。自 2010 年以来，我一直在我工作的团队中每周组织棕色包/午餐和学习课程。我在不同时间听到我的同事两次，“每周三参加课程让我提高自己，这激励了我很多”。这反映了公司定期内部会议的力量和影响。

收集并提供反馈。为了收集集体反馈，您可以像我多年来所做的那样组织盛大回顾。顺便说一句，Grand Retrospective 是一种挖掘问题的新型回顾会，有 20 多人参加。

教学和分享是掌握一个主题的最佳方式。成为演讲者并回馈社区。

开发人员似乎讨厌文档，但实际上恰恰相反。人们阅读的任何输出都只是一个文档；从生产代码本身到测试代码，从提交消息到提交图，从日志消息到错误消息，开发人员无意中记录了很多。所以无论你记录什么，因为人们阅读它是为了理解，所以做得更好。

你们不是孩子。公司不是你的父母。我们必须拥有自己的事业并投资于自己。如果投资意味着花费时间和金钱，那就为自己做吧。

我们如何通过放慢速度来优化流程？

每一天，我们都面临着新的挑战。这些挑战不应仅仅关乎市场需求或新要求。技术挑战对我们的进步也有很大影响。

计划什么都不是，但计划就是一切。经常计划和修改。尤其是在初创公司的早期阶段，您需要极高的敏捷性。每天一次对齐，例如通过每日 Scrum 或每日站立会议，是不够的。您必须密切合作，结对工作，并且每天不止一次对齐。保持迭代长度短，短至一周。通过组织定期审查和演示会议创建多反馈循环渠道。

定义短期目标和长期目的。短期目标为您的团队创造焦点，长期目标可以防止注意力分散。

如果您想了解哪里出了问题，请从技术和业务方面的流程可视化开始。可视化失败和失败，以促进您从过去的经验中学习。

永远不要凭直觉做出决定。始终收集数据、分析数据并根据数据做出决策。允许每个开发人员访问产品和代码指标也很重要。这增加了围绕产品开发的集体所有权和常识。

废物是您生产的任何没有商业价值的东西。检测并消除办公室、代码和流程中的浪费。童子军离开露营地时比他们发现的要干净。同样的理念在软件开发中也是有效的。遵循童子军规则，让你的代码更干净。当您打开文件以添加新功能并注意到其中的问题时，请在未获得任何许可的情况下对其进行修复。不要忘记在解决问题之前编写测试。这让您在触摸代码时感到自信和自在。

您可以在软件开发生命周期的每个点检测浪费。遵守您对完成的定义并消除“完成 90%，剩余 90+”的任务。永远不要让长寿的树枝。长寿的树枝被认为是邪恶的。不要通过手动测试来验证您的代码。手动测试主要验证快乐路径。所有其他场景只能通过测试代码进行验证。所以认真对待。

减速如何提高产品质量？

一件事很清楚。没有高质量的代码库，你就不能敏捷，抱歉。您需要做的第一件事是消除技术债务并解决错误。如果您需要暂时停止构建功能，并专注于消除错误。

“修复错误并随后部署到服务器”不是今天的正确程序。它包含风险和危险。我们需要一种更好、更有纪律的方式来做这件事。当您想修复错误时，首先编写测试并以编程方式重现问题。然后修复错误并查看测试是否通过。之后部署到生产环境是安全的。

我在几乎所有时间都在修复错误和维护代码库的团队中工作。这些团队遭受生产不稳定的困扰。要在修复错误的同时继续开发新功能，您需要将您的团队分成虚拟团队。例如，我们每次迭代都会选择两名队友来提供直接的技术支持并继续修复错误。我们称他们为蝙蝠侠与罗宾。无论你急于什么样的功能，错误都必须被修复而没有任何中断。

今天，开发人员通常使用一种做法来减慢进度，以加快进度。那是使用拉取请求。他们停止生产线，进行验证和代码审查以提高代码质量。他们从不将未经审查的代码部署到生产环境中。

我们的最终目标应该是实现持续交付，并经常发布。从 git 分支机制到部署策略，从反馈机制到自动化测试实践，都需要不同的思维方式。

您在 SDLC 中使用的做法表明您的开发速度。对于 git 分支机制，“早提交、常提交、晚完善、发布一次”的理念和基于主干的开发以及功能切换可以让您消除浪费。

多年来我一直在使用 TDD。许多人向我抱怨 TDD 对编程速度的影响。 Joe Rainsberger 在推特上分享了他对 TDD 的看法：“担心 TDD 会拖慢你的程序员的速度？不。他们可能需要放慢脚步。”

TDD 重构多于测试，思考多于编码，简单多于优雅。这就是为什么它会带来更好的质量。 TDD开发；有足够的测试和简单的设计。

你有没有达到 100% 的代码覆盖率？我在一个为期三个月的项目中实现了这一点。我为每一行生产代码编写了单元测试。那时，我觉得自己是一个拥有超能力的英雄。但是，当我们部署到 UAT 的预生产环境时，我们注意到有四个功能不起作用。我必须编写集成和功能测试来检测错误并解决它们。然后我意识到单元测试并不能保证良好的设计和工作功能。停止计算代码覆盖率。代码覆盖率不过是愚蠢的信息辐射器。

如果您需要 30 分钟或更短的时间来修复错误，请修复它们。此外，使用 20% 的时间消除技术债务。

我们通常编写代码以防止将来更改它。因此，当我们设计软件时，我们同样会选择技术和工具，以免将来改变它们。但我们错了。重构应该出现在我们开发过程的每个阶段。正如 Kent Beck 所说，我们必须进行简单的更改以使更改变得容易。为了实现这一点，我们在一个单一的存储库中管理我们所有的微服务。 Mono 存储库用于简化重构，而这正是我们真正需要的。

在需要之前做出的任何设计决策都是错误的。因此，我们等到最负责任的时刻采取行动。我们在系统的高级设计中使用六边形架构来激活松散耦合和高内聚。这也导致了精心设计的巨石。顺便说一句，巨石并不邪恶，但糟糕的设计才是。我们总是从单体开始，在端口和适配器的帮助下，我们提取一些功能作为微服务。正如 Martin Fowler 在其博客中的“单体优先”文章中，“直接使用微服务架构是有风险的，所以首先考虑单体系统。在需要时拆分为微服务。”