每日分享最新,最流行的软件开发知识与最新行业趋势,希望大家能够一键三连,多多支持,跪求关注,点赞,留言。
代码改动表示代码更改的频率。高代码流失有时可能是一个潜在的危险信 。您如何检测非生产性流失以及您可以采取什么措施?
作为工程主管,您的首要任务之一是提高团队中开发人员的效率和生产力。管理和改进工程团队的第一步是采用指标驱动的方法来识别威胁团队绩效的问题领域。
成功的团队通过一组称为软件工程指标的选定指标来跟踪他们的绩效。借助这些指标,工程领导者可以可视化进度、识别瓶颈、观察异常趋势,并在错过最后期限之前预测何时出现问题。
软件开发中一个如此重要但经常被忽视的指标是代码流失。在本指南中,我们将解释什么是代码改动,为什么高级别的改动会对项目有害,以及当您注意到意外的改动高峰时该怎么做。
什么是代码流失?
代码流失,也称为代码返工,是指开发人员在编写代码后不久删除或重写自己的代码。代码流失是软件开发的正常组成部分,观察代码流失的趋势可以帮助管理人员注意到截止日期何时面临风险、工程师何时陷入困境或挣扎、有问题的代码区域,或者何时出现与外部利益相关者有关的问题。
新编写的代码经历多次更改是很常见的。给定时间段内代码更改的数量和频率可能因多种因素而异,代码改动的好坏取决于发生的时间和原因。例如,工程师经常测试、重写和检查一个问题的多个解决方案,尤其是在新项目或任务开始时,他们正在试验手头任务的解决方案。在这种情况下,代码流失是好的,因为它是创造性解决问题的结果。
代码流失的好坏取决于发生的时间和原因。
代码流失指标分解
代码。重构代码通常是维护所需的可接受更改,因此与代码改动不同,以免引发任何危险信 。
代码,不会替换或重写现有代码。
在开发生命周期中观察这些指标范围内的趋势为有效调试根本原因和获得潜在洞察力创造了更好的基础,例如:
当这些指标中的任何一个或所有指标超出预期范围时,异常警 可以使管理人员应对挑战,抢先交付风险,并获得对可能需要改进的关键流程的可见性。
如何检测非生产性代码流失
代码流失因许多因素而异。例如,当工程师处理一个相当新的问题时,流失率很可能高于基准,而当开发人员处理一个熟悉的问题或相对容易的问题时,流失率很可能低于基准。流失率还可能因项目在开发生命周期中所处的阶段而异。因此,对于工程经理和领导者来说,了解组织中不同团队和个人的流失水平模式或基准非常重要。
虽然代码流失本身并无好坏之分,但只有当流失水平偏离正在处理的特定项目的团队或个人基准时,才值得关注。当发生这种偏离时,确定导致非生产性代码流失的因素很重要。
高代码流失率表明什么?
复杂的任务
当工程师正在探索和回溯手头的一个特别具有挑战性的问题时,预计会有更高的流失率。当探索进行的时间过长时,才引起关注。
不寻常的高流失率可能表明工程师没有完全理解任务,或者忽略了完全理解问题,或者没有解决任务的专业知识。在许多情况下,工程师认为他们已经成功地处理了问题,甚至可能将其送去审查,然后发现其中的重要区域需要更改。
来自外部利益相关者的不明确要求或变更请求
正常开发过程之外的因素,例如 PRD(产品需求文档)不佳或利益相关者不明确或优柔寡断,也可能导致高代码流失。流失率突然增加或新工作突然激增,尤其是在项目的最后阶段,通常表明利益相关者之间的沟通不畅或新需求导致最终代码发生变化。当看到这种模式与同一个团队一起冲刺冲刺时,它会损害士气和进步,并且随着时间的推移会导致团队沮丧。
未来质量问题的指标
衡量代码流失使管理人员具有远见,可以预测和预防潜在的未来问题。最有问题的代码是那些难以掌握且经常更改的代码。高水平的流失会暴露潜在的代码热点,如果对复杂和关键的代码执行这些频繁的更改,代码往往更容易出错。因此,代码流失可能是高风险代码的预测指标。
这些代码热点,如果没有在重构工作的早期识别出来,可能会导致开发人员积累大量的技术债务。随着错过更多代码重构的机会,这种债务会增加,因此,新的开发变得困难,特别是当功能是基于遗留代码构建时。
截止日期有风险
在项目开始时,通常会看到由实验导致的更高比例的返工和代码删除——尤其是当项目是新的或不熟悉的时候。在特别具有挑战性的问题的情况下,预计会出现类似的趋势,有时称为“探索性流失”。虽然创造性问题解决导致的代码流失是一个积极的结果,但当这种实验性编码持续很长时间时,它会成为项目截止日期前的风险,从而危及开发周期的时间表。
同样,随着项目接近发布时间表,流失率应该会稳定下来。交付应该推迟的早期迹象是当您开始看到导致发布的大量流失时。
如何防止高代码流失
当面对高效率的代码流失时,这里有一些经理可以实施的潜在行动。
更好的规划
管理人员应根据编程语言和代码的复杂性将开发人员分配给项目和任务。使用数据驱动和事实洞察来规划团队和任务分配可以改善非生产性代码流失的情况。
特定代码热点的高流失率可能是工程师在很长一段时间内始终坚定不移地专注于代码库的特定区域,只是到处做一些小调整的例子。这可能是倦怠的早期迹象。数据驱动的规划为管理人员提供了将一组新任务或项目分配给这些工程师的机会,这将帮助他们导航到代码库的新区域。
训练
领导者应确保他们的开发人员接受正确的培训和学习,以便他们拥有正确的技能来创建应用程序所需的功能。一种广泛使用且成功的培训方法将编程课程与自然倾向于帮助他人的高级工程师配对。这种结对学习练习还有助于提高团队的士气和效率。
明确要求
如果规范定义不明确或不充分,开发人员将被迫处理模糊的需求,迫使他们依靠他们最合理的猜测来解码和填补任何空白。为避免这种情况,管理人员必须确保他们的开发人员获得最新的需求,以便他们可以创建适当的解决方案并避免返工。
结论
长期以来,工程领导者一直依赖有限的信 和他们自己的直觉来评估团队的绩效并充分帮助他们的团队。跟踪代码流失和其他指标的目的是实现事实和数据驱动的决策。数据驱动的反馈循环有助于识别流程改进的可能性并实时调整工程例程。
一些软件组织经常忽略和未充分利用代码流失。然而,跟踪和管理流失可能导致团队发现严重问题,不仅在他们的代码库中,而且在他们的开发人员教育和工程例程中。衡量代码流失肯定会帮助工程领导者管理和优化他们团队的绩效和生产力。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!