Categories
程式開發

为什么我们经常要花将近一个月的时间来发布几行代码?


本文最初发布于******hackernoon.com*,经原作者授权由InfoQ中文站翻译并分享。*

你有没有想过,为什么我们要花将近一个月的时间,才能把几行代码修改交付给我们的明星客户或忠实客户?当所做的更改符合产品、营销和应用程序管理人员的要求时,有什么会妨碍它立即发布?为什么管理人员会针对维护发布列出一个在你看来如此“不现实”的时间表呢?这些是我在编写生产级代码的最初几个月里的思考。

在大学的时候,我总以为完成项目就是开发,就是永无止境地编写代码。一旦特性的初版完成,项目即告完成。全部完成。没有同行代码评审,没有文档,什么都没有。只是一些原始的代码文件,其中零星有一些注释。它是有效的,可以满足需求。我们从不考虑可维护性、可读性、可伸缩性等等。你提出的功能需求,你设计了它,开发了它,然后又测试了它,你当然会对它满意。

更重要的是,我们的软件有效。我不只是说它没出问题,或者它的行为完全符合书面规范,或者它可以高效地生成报告。它是真得很有效。

但是,企业界的情况似乎有所不同。

有一种东西叫做“流程”,流程的成功/成果取决于团队。团队要有足够的耐心和纪律来遵循流程。本文将讨论这个所谓的流程。不同的公司遵循不同的流程,我会尽量使这篇文章尽可能的通用,以便读者可以将自己的情况与本文的内容联系起来。请在评论区与我们分享您公司的流程。

第一步:软件产品建议

产品线的市场营销部门会分析产品服务的市场趋势,在一个较高的层面上简要地了解客户的需求(有些客户往往会提供更多的细节和见解,但一般情况下,很多人只会提供高层细节,因为你还没有表现出要给予任何承诺。这也取决于你的目标市场的活跃程度)。下面这句话总结了营销团队的工作。

在编程中,困难的不是解决问题,而是决定要解决什么问题。

一旦市场营销团队基于前面的分析找到了一个有前途的ROI,他们就会继续,创建一个软件产品建议,简要说明公司在市场上的位置、产品的规格、潜在客户、预期收益等。一旦得到批准,领导团队就会确定每个模块对应的所有者——业务所有者、产品经理、S/W经理、S/W开发人员、S/W测试主管、质量经理和应用程序/客户经理。

第二步:软件产品规范

一旦确定了高层次的市场需求,相关的产品经理就会介入,并创建一份全面的S/W产品规范。一般情况下,其中会包括执行概要、产品描述/分类、产品分销、客户的特定要求和产品安全要求(适用于汽车和相关行业)。产品经理会考虑不同的受众,并创建框图来解释高层次的设想。

草案准备好之后,产品经理就会将其分发给不同涉众进行评审,并召开评审会议,讨论什么时候可以执行完成、外部依赖关系以及向客户交付产品。

第三步:软件架构、设计&测试计划

一旦研发团队与业务/营销团队在功能和规范上达成一致,他们就会继续下一步工作,创建S/W架构和设计文档。他们从产品经理那里获得输入,并创建这些文档,以便将每个营销特性很好地映射到需求。每个需求都会映射到各自的架构和设计规范。这样,就可以无缝地进入开发阶段了。

构建软件设计有两种方法:一种方法是使其非常简单,明显没有缺陷,另一种方法是使其非常复杂,没有明显的缺陷。

S/W开发经理了解所有的映射,并将需求分配给S/W开发人员(根据可用资源情况)。与此同时,S/W测试主管会了解规范,他/她将制定测试计划和测试策略来测试特性。产品执行所需的任何豁免现在就开始执行。

在此阶段,产品经理和S/W开发经理还创建了风险管理计划,记录了所有的依赖关系、可用的资源,以及如果事情没有按照预期进行,可能出现的时间延迟。(通常情况下,事情并不像预期的那样发展)。基本上,这份文档旨在抑制所有可能的意外,但我每天都会经历。

第四步:特性&测试用例开发——单元测试

如果软件产品规范、需求、架构和设计文档广受好评,就意味着可以进入开发阶段了。终于到容易产生共鸣的东西啦。

开发完全由研发团队掌控,间歇性地从应用管理方和项目管理方那里获取输入。通常,特性开发与测试用例开发同步。然而,测试用例开发将特性视为一个黑盒,对特性开发一无所知。测试计划的整个输入是软件产品规范。这有助于保持测试的公正。当特性开发部分完工时,大多数开发人员会编写单元测试用例来检查预期的功能。通常,单元测试是高度模块化的,并且在函数级进行。这可以使开发人员有足够的信心相信函数的响应总是确定的。下面是我最喜欢的一种调试形式。

最有效的调试工具仍然是经过仔细考虑的、放在适当放置的打印语句。

S/W开发经理会密切关注开发进度,并向项目经理报告执行进度的最新信息(每周/每月)。

第五步:更多测试——集成测试&静态/动态分析

当特性和测试用例开发快完成时,开发人员会以可测试的方式将代码交付给测试负责人。当测试团队在代码上执行严格的迭代测试时,开发人员也没闲着,他们会执行需求级的集成测试。他们通过集成各种单元测试来测试特性/需求。他们有了足够的信心,事情会按预期进行,但这还没完。测试负责人将报告一些不确定的行为,显然,这些行为会使开发人员感到惊讶/沮丧。通常情况下,开发人员和测试人员会保留各自的意见。你不能责怪测试人员,因为那是他们的工作职责:发现Bug。

测试的另一个重要方面是执行静态和动态分析。这种形式的测试属于开发人员的职责范围。大体上,他们会检查代码是否符合适当的编码准则,先前执行的单元测试覆盖了多少语句和函数,等等。根据我的个人经验,通过执行这项分析,我已经修复了许多未发现的Bug。这保证了代码的完整性,并使代码更具确定性和可维护性。通常,一旦由开发人员提供的报告(如单元测试、集成测试和静态分析)就绪,代码就会被冻结。同时,测试负责人会生成测试报告。

第六步:整合

代码被冻结。已确认。通过所有测试用例。已确认。你认为我们可以交接并继续前进了,对吗?坚持住,伙计。

文档,它的重要性再怎么强调都不过分。

文档是一封写给未来的自己的情书。

这个产品现在只有两类人可以理解——开发人员和测试人员。应用工程师/客户工程师完全不知道如何有效地使用你提供的特性。开发人员需要编写清晰的文档说明如何使用该特性。不要太长,那令人厌倦。也不要太短——他们肯定会回来问你更多的问题。文档的资源占用经常被低估。它确实会花费你大量的时间来解释如何使用这个特性。

S/W开发经理移交代码,应用团队提供产品信息,测试负责人提供报告,质量经理验证文档并根据流程的遵循情况来打分。项目经理把所有东西都整合在一起,召开最后的交接会议。

回到文章开头提出的问题。为什么要花近一个月的时间来发布几行代码?

假设我们的目标是一次维护发布,我们只执行开发、测试和文档编制的步骤(步骤4-6)。对于一名S/W开发人员来说,代码更改看起来可能需要两天的时间,但是考虑到上面的步骤,实际上可能需要几周到一个月的时间。我用下图来说明一下。

为什么我们经常要花将近一个月的时间来发布几行代码? 1

问这个问题的人是那个火柴人。我希望他现在明白了。

原文链接:
Why Does it Often Take Nearly a Month to Ship a Few Lines of Code?