为什么您的团队需要降低代码目标

“软件正在吞噬世界” 。 马克·安德森(Mark Andreessen)在2011年发表的著名文章中写道:“我们正处于技术和经济急剧变化的大潮之中,软件公司已准备好接管大范围的经济。” 他预计会有更多的行业被软件打乱,并被证明是正确的。 随着AI的最新突破,我们还没有看到所有中断的终结。

马克·安德森(Mark Andreessen)主张增加对软件的投资,并认识到交付的业务价值。 尽管通常认识到软件解决方案的商业利益,但是创建软件的成本很高 。 每行5K到10K的代码创建成本约为1 FTE。 一个普通的iphone应用程序轻松地需要约10-50K行代码,而现代汽车则使用100M行代码(来源:代码库大小)。

拥有软件也很昂贵 。 即使不需要更改功能,原始软件的环境也会不断变化。 新的操作系统破坏了多年来完美运行的功能。 即使具有相同的功能,新的硬件也需要软件工程师结合新的驱动程序。 采用新颖的破坏安全性的方法,需要重写部分软件以确保其安全性。 根据我的经验,每年重复执行的每行50K-200K代码大约需要1 FTE的维护。

如果您有一个10 FTE团队,每年创建50K到100K LOC,那么您还会产生在该软件的整个生命周期内持续维护该代码的需求。 第一年,团队效率很高。 第二年,他们需要部分时间来维护在第一年中创建的代码,依此类推。 如果您认为维护是代码大小的函数,那么创新速度将为零!

有几个因素使您的代码大小超出所需的大小:

  • 生产过剩:有些工程师比其他人更冗长。 创建简洁的软件需要技能,时间和审查。 正如马克·吐温(Mark Twain)所说:“我没有时间写一封短信,所以我写了一封长信。”
  • 过度抽象 :软件工程师可能会“过度抽象”,例如创建高度可配置的代码或创建框架以供将来使用。 尽管这可能是真实的业务需求,但通常并不需要满足业务需求。 需要配置或重用的代码比为特定用途量身定制的代码更冗长。
  • 过度处理 :基于事件/异步的体系结构比同步的体系结构更冗长。 并非所有现实世界中的问题都需要异步体系结构,我相信这种模式已被过度使用。 另外,异步体系结构可能会产生不必要的运行时动态,从而产生昂贵且难以诊断的质量问题。
  • 超支:业务压力始终很高,许多项目团队需要同时增强相同的代码以同时满足截止日期。 那么:项目负责人有什么要求? 独立! 我需要自己的分支,现在需要! 当然,这会带来合并的开销。 合并既昂贵又复杂。 拆分可能导致需要支持更多产品变体。 与隔离设计相比,隔离创建的不同分支中的代码很有可能膨胀。

随着时间的流逝,并不是最初要求团队执行的所有要求仍然是必需的。 曾经是“热门”和“新颖”的软件技术现在已经过时和新颖的范例,可让您以更简洁的方式表达功能。 通常,软件堆栈包含失去其价值的抽象层。 结果,大多数代码库都比需要的大得多。 我给出了膨胀的但仍可正常工作的代码示例。 代码堆栈中可能还包含根本不再使用的代码(无效代码)。 尽管看似无害,但在新的上下文中重用无效代码可能会对业务产生重大不利影响。 例如,请阅读对Kevlin Henney的采访,他认为需要找到并删除无效代码。

您拥有的代码越多,您拥有的错误也就越多。 这不会以线性方式缩放。 如果您将代码加倍,则错误将增加一倍以上。编写过多代码的最终结果是,您在维护上花费的时间超过了必要的时间,并且没有给利益相关者足够的需求。

如何打破负面螺旋? 第一步是要认识到监视代码大小的重要性。 您需要将其嵌入团队文化中。 建立“极简代码”文化将使您的团队控制他们的代码库。 他们可以发现意外的代码大小增加,并在寻找减少机会方面挑战自己。 设定自己的目标将激励团队在可能的情况下查找并删除无效代码。

对于较大的代码大小,这是一项多年的工作。 但是开始旅程可以节省许多FTE的维护费用。 以下是一些我成功减少了旧代码大小的方法:

  • 它从询问开始。 大多数软件工程师对代码栈膨胀的位置有很好的了解。
  • 衡量您的要求并测试覆盖范围。 对您的代码进行测试是放心减少代码大小的第一步。
  • 从旧代码恢复模型。 阅读TNO ESI的Arjan Mooij的采访,以了解更多信息。
  • 提高代码的表达能力:使用领域特定的语言(如果适用)以最简洁的方式表达您的意图。
  • 使用模型驱动的软件工程工具,例如Verum的dezyne

软件正在吞噬世界。 但是,维护超出所需数量的旧版软件代码库会降低创新速度 您需要为团队减少代码大小的目标!

  • 因为你需要创新速度
  • 因为您需要提高代码质量
  • 因为你需要健康的工程文化

请让我知道您过去减少代码堆栈的成功方法!