👨‍💻精益开发

Ryan

值得译读|2023-9-8|最后更新: 2023-12-22|
summary
category
tags
date
🤯
"精益开发"指的是创建一个最小的产品原型,交付给客户,观察他们如何使用它,再快速推出小幅改进的下一代产品。这样就能迎合快速变化的需求,不会引入无用功能。
作为比较,福特方法则是详细计划所有功能,全部开发出来,然后一次性交付。
 
 
软件开发最有价值、最独特的方面是我们可以迭代的速度。不能快速而频繁地迭代的软件项目通常会停滞不前并且失败,而那些能够在几乎实时的基础上处理用户反馈的项目是最成功的。我在 Archytas 自动化公司工作的时候就注意到了这种不同。最近,我读了《精益创业》、《摩托车维修的艺术》和《务实的程序员》。虽然每种方法都使用自己的术语,但都深入探讨了快速迭代周期这一主题的深度。

精益生产和精益思维

正如《精益创业》中解释的那样,精益生产是一种注重避免浪费的生产方法。这本书的主要例子是丰田生产系统。
notion image
在20世纪30年代中期,世界上最大的汽车制造商是福特。福特的工厂生产了成千上万个独特的零件,这些零件可以组成一辆汽车。他们批量生产这些零件,每个不同的零件都有一台专门生产这些零件的机器。有一种制造弹簧的机器,一种制造螺母的机器,还有一种制造螺栓的机器。没有机器可以制造除了它设计用来制造的零件以外的任何零件。
这是伟大的: 这意味着汽车将比以往任何时候都便宜,更多的人可以体验拥有汽车。
notion image
大约在这个时候,丰田进入了汽车工业。然而,他们既没有时间,也没有资金来设计和制造福特所使用的那种超特定制造机器。相反,他们选择购买相对较少的超广义机器。他们的策略是一次造一辆汽车,然后尽快卖掉(最好是在它从工厂车间滚下来的那一刻)。这样,如果有一个问题的车辆,设计可以修改之前,有太多的故障汽车组装。
丰田生产体系强调灵活性而非效率。通过保持灵活性,丰田赋予了自己在生产过程中优化业务各个方面的能力。
一方面,福特的流程是这样的:
  • 买一百辆汽车的材料。
  • 为每辆汽车制造超过1000个不同的部件(可能总共超过10万个部件)。
  • 组装一百辆车。
  • 卖一百辆车。
  • 接收车辆和生产过程的反馈。
  • 对车辆的设计和生产过程进行所有可能的改变(这将是非常小的)。
有了这么多步骤,每个步骤都需要相对较长的时间,迭代周期很少,而且间隔很长。另一方面,丰田的生产系统是这样的:
  • 买一辆车的材料
  • 制造汽车所需的相对较少的独特部件
  • 如果生产过程中出现问题(机器坏了,有人受伤等)。停止整个过程并解决这个问题,这样就不会影响未来的汽车。
  • 组装一辆车。
  • 卖掉一辆车。
  • 接收车辆和生产过程的反馈。
  • 对车辆的设计和生产过程进行所有可能的改变(考虑到两者的灵活性,可能会有很多改变)。
与直觉相反,以一个批量大小执行每个步骤实际上最终会更有效率。尽管福特在每一批产品中都经历了更高的效率,但是他们的工艺导致了更多浪费的部件被制造出来,以及各个步骤之间缺乏沟通,这极大地增加了浪费的工作量。此外,由于丰田生产系统允许相对快速的迭代,丰田汽车只是更好: 更耐用,更有用的客户。

软件中的精益思维

在软件开发中,人们很容易走福特的路线: 为您希望添加到服务中的所有特性创建一个详细的计划,然后开发这些特性,并一次性交付它们。只有这样,您才能接受反馈并评估每个特性的有用性。
然而,在《精益创业》一书中,受丰田生产系统的启发,Eric Ries 提出了一种替代方法。在决定在您的服务中包含哪些功能之前,请先进行实验。创建一个特性的绝对最小原型,提供给客户,并观察他们如何使用它。有可能他们发现这个特性没有帮助,或者他们以一种你意想不到的方式使用它。通过在早期运行这个实验,引入的无用功能就会少得多,客户就能得到与他们需求更紧密相关的产品。
此外,您对问题域的理解可能是错误的。当项目的需求发生变化时,提前几个月计划好整个产品发布是有问题的(而且他们经常会发生变化)。

为什么口译语言如此有效

解释型编程语言几乎无处不在。在2023年 StackOverflow Developer 调查中最流行的十种编程语言中,有六种是解释语言。该计数不包括可以以半解释方式使用的 TypeScript。直译语言的流行通常归功于它们易于使用、抽象、简单、类似英语的句法。然而,我相信还有一个额外的原因: 它们允许迭代快得多得多。

微型迭代

迭代可以在任何时间尺度上发生。微迭代发生在最短的时间范围内。这些是在调试或优化代码时(通常)发生的小的增量更改。它是一个变化所产生的时间量(进一步说,是精神开销)。测试编译和运行的时间越长,调试的时间就越长。
我相信你可以这样做:
time to debug=(time to test)2text editingtime to debug=(time to test)2∗text editing
这不是一个精确的,有代表性的方程式,只是一个抽象概念来说明我的观点,基于个人经验。
换句话说,总调试时间随着测试程序更改所需时间的增加而呈二次方增加。注意,随着 time to test 的增加,实际的时间量 text editing 降低到总时间的一个可以忽略的比例。我相信这是因为随着编译时间的增加,每次微迭代收集的信息量趋于减少。

准时编译与热重装

这就是我们讨论文章标题的地方。
精益思想的概念延伸到编译器技术。丰田生产系统包括“准时生产”的概念,意思是“只生产产品所需要的东西,准确地在过程中需要的时候生产。”避免提前规划资源需求,并构建只生成实际需要的系统。
虽然当我们提到编译器时,“ Just-in-time”的意思是不同的,但是思路最终是相同的。与其在编译和优化不相关代码上浪费宝贵的人力资源时间,不如在需要的时候编译您需要的代码。这大大减少了测试的时间,并最终减少了调试的时间。
此外,像 React 和 Flutter’s Hot Reload 这样的技术使得无需重新启动程序就可以完成这些微型迭代。我相信这也是为什么解释语言对初学者如此友好的部分原因(除了它们通常提供的高级抽象)。编程新手大部分时间都花在语法问题和简单的运行时错误上。通过使微迭代尽可能快地发生,您可以减少处理这些问题的麻烦。

拖延症

如果你在上大学(就像我现在一样) ,或者其他教育水平,推迟做家庭作业实际上是有益的。项目或论文需求在最后一分钟发生变化并不罕见(至少在我的经验中是这样)。你的一些同事可能会选择尽快完成项目或论文。如果是这样的话,你可以从他们的经验中获益。如果某个逻辑或分析链令人困惑或误导,它们可以提醒您避免浪费时间。假设他们愿意,他们也可以在你写作或学习的过程中对你的工作提供有见地的反馈。

结论

迭代对于任何设计和开发周期都是非常重要的,特别是在软件中。自从我接受迭代开发以来,我已经看到我的生产力和效率有了显著的提高。因此,我鼓励您: 如果您的构建过程需要30分钟,那么花一些时间来改进它。如果你正在进行一个项目,而这个项目还没有呈现在你的客户面前,试着把它展示给你的家庭成员或者非技术性的朋友看。要求他们残酷的诚实,你的项目将会更好。
 
  • Twikoo