本文最初发布于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开发人员来说，代码更改看起来可能需要两天的时间，但是考虑到上面的步骤，实际上可能需要几周到一个月的时间。我用下图来说明一下。

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

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

创作场景

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