FB 前工程主管：发布代码的正确方式

我在这方面历练多年，发布过许许多多的软件，我曾在3人到1万人的高科技公司工作，开发的软件从免费到五千万美元授权费——以及这之间的任何价位。这些产品的开发和发布方式各有不同，在有机会进行比较和对照之后，我也想揭示发布软件的正确方式。

很惭愧，我承认我给不出来。

我多次发现而又重新发现构建软件、发布软件的“正确”方法。我近乎狂热于某些实践（比如精确的估算编码，详尽的规格定义或通过 A/B 测试的UI设计），但是当我尝试把这些实践应用到其他产品上时，魔法却失灵了。

在这个行业里，我们因为制表符长度和大小写问题持续了几十年的“圣战”，人们深深迷恋自己的开发和发布习惯，也就不足为奇了。如果发布了这么多软件能够教会我一件事，那就是做一个不可知论者。不同的方法适用于不同的目的，而且它们各有各的不足。如果强化时间表的可预见性，就会损失工程生产力（也就是变成了经典的时间/空间取舍）。即使你不用面对教科书上的取舍问题，所有付出的努力，不管是实现自动测试还是修正BUG，都会换来另外让你花费时间的其他东西。

亲爱的工程师们，请不要问「这个流程是好还是坏？」，而是要问「它适不适合我的场景？」

来看看我的两段职业生涯：

VMWare的初创期，软件要具备可预期的完成日期和高可靠性，因为必须要说服保守的企业用户使用全新的供应商提供的操作系统。（那时候虚拟化听上去像是科幻一样！）

Facebook在初创期需要快速前进，因为先行者优势对基于互联网的产品意味着一切。

两家公司一个高度重视可预期性和可靠性，另一个致力于提高用户参与度，很容易猜测哪个是哪个。可想而知，这两家公司的开发实践毫无共同之处，没有谁对谁错——都为了目标做出了取舍，它们中的任何一家如果采用另一家的产品将会无效甚至是灾难性的。

首先看看顾客是谁

要确定“开发软件的正确方式”，必须理解产品的关键点及如何优化才能实现这些关键点。这不是由个人偏好决定的，归根结底取决于公司的使命，也就是你的公司如何赚钱。

如果你以高价销售软件，那么你的客户很有可能是基于需求来购买的。软件价格越高，您客户的业务越关键，你就越有必要优化软件的可靠性、功能性和可预期的时间表。也许你觉得商业客户希望你的软件做的越快越好，但是他们依赖很多东西–部署、培训、集成-对他们来说可预期性比快速更加重要。更大的交易规模也伴随着更少的客户，这意味着每个客户拥有比你更大的权力，满足他们的需求对创业生存下来更重要。

许多最传统的，守旧的软件开发方法的目标是确保计划的可预测性：认真规范的功能列表和任务估算、依赖性分析和很长的工作时间。持续集成、全面的单元测试和beta测试等更加现代的技术也会帮助大家更早发现技术风险。在VMware工作的七年里，我们所有的努力都基于一个时间表、特性和质量的“三脚凳”。它们中的每一个都必须满足，这带来了高昂的工程造价及非常低的开发效率。我们尝试使用拥有更快的开发周期的新技术，但它们有一个客户无法接受的缺陷：缺乏远见。

一般来说，昂贵的软件意味着可预期性是发布的关键，客户需要你的产品。如果软件价格更低（或免费），那么关注UX，让本不需要你产品的用户很想去使用它。

如果你的客户不是有具体需求的企业怎么办？随着你的要价越来越低（从百万级到万级，到千级，到freemium，到免费），你的市场覆盖面越大越容易涉及较小的企业或消费者。对于这类产品，时间表没有那么重要，因为不管最新功能什么时候实现，人们一般都会接受。单个客户的影响很小，所以你可能不会优先处理小平台或少量用户遇到的bug。

不过不能因为收费低就不再优先考虑质量问题。如果你的产品廉价或免费，人们使用它的原因很可能是想使用而不是必须使用。长期以来，用户体验（UX）在消费级市场比企业级市场重要得多。企业产品供应商也越来越重视伟大UX的价值，但他们追求“消费级用户界面”是有原因的。我们可以找到很多实践来保证 UX 质量，包括强化设计团队，在承诺的交付日期前做原型和迭代，设计、工程和用户测试之间密切合作。

舞台也在这里，如果你在快速增长(一年内80% 的用户是新增用户，他们不会记得你的错误)那么质量上的折衷也许可以接受；如果你经营的是重复业务（经常性收入），你就必须确保当前客户的满意度。

其次，评估您的部署方式以及您愿意承担的风险

您的部署方式也会影响您采用的发布版本(release)，这与科技公司使命不同会影响发布版本一样。在云中部署意味着你可以完全控制软件的运行环境。这样你的词汇表中就不必有“测试矩阵”这个词了，它将大大地降低测试时间和bug修复量。你可以随时更新; 分发是即时和通用的（不受客户影响）。删除的代码实际上消失了。你不必因为担心客户还没有使用最新版本而去修复之前版本存在的bug。如果产品部署到客户的设备上（从本地移动应用程序到操作系统），发布一次版本的一次性和未来成本将(比部署在云端)大大提高。

• 想要可靠性？ 与其做几个星期的压力测试，不如发布产品并逐渐增加负载。当遇到瓶颈时，停下来解决这个问题。
• 想要有效的测试？ 可以用20% 的测试发现80% 的bug ，然后快速找到并修复其它一些 bug。
• 想要设计质量？ 将原型投放到少量用户并观察它如何工作来实现快速反馈迭代。

当然，你不能仅仅因为轻松就选择在云中部署。 一些产品（操作系统或视频游戏机）根本不可能完全存在于云中。如果您为移动设备的消费者打造产品，为了提供最好的用户体验(UX)你很可能会选择一个本机应用程序，因为至少对于消费者而言，丰富的用户体验比工程生产效率重要。我知道这听起来很荒谬，发布移动应用更加类似于发布操作系统而不是web应用。这就是为什么即使移动优先，你也希望所有移动应用的大脑都在服务器上，这样可以轻松修改它。

Facebook艰难的向移动端转型过程说明了潜在的麻烦。Facebook的快速、个性化及设计部署软件的迭代方式深深植根于产品团队文化中。如果在Web层工作，发布的成本非常接近于零，差不多所有的工作方式都基于充分利用这一假设进行了优化。随着公司的重点转移到本机移动应用程序，工程师们利用他们的专业知识专注于未知的流程，如功能和用户界面冻结，功能规格和QA。

对于Facebook工程师来说，向移动转型的难点不在于学习新的编程语言和框架，而在于他们要放弃原来开发软件的假设。我想说基于本机移动应用限制的假设冷静地分析各种实践的优点、分析什么是最好的Facebook的用户社区都是很好的做法。实际发生的情况更像是感恩节晚餐桌上关于宗教或政治的讨论。我们都是家人，但想法完全不同。

这场辩论的核心是关于容忍风险的不同假设。勇于冒险的精神深深烙刻在Facebook文化中 – 毕竟，这家公司带给你的口号“快速移动，破除陈规！”。长期以来，Facebook工程师把拥抱风险作为一个基本的文化特质 -当时，他们没有意识到，基于网络应用而言正确的假设的操作模式应用到移动应用上时是行不通的。

指出自己的软件开发类型意味着必须去考虑自己的风险偏好。

创业者应该积极地承担风险，这是一条完全理性的准则。当你没有任何顾客、收入或者品牌的时候，错误是无关紧要的。你什么都没有，有什么好紧张的？但是一旦有了顾客，你就需要根据造成的痛苦来定义错误的成本。相似类型的操作错误，可能导致基于不同业务及部署模式的两家创业公司中的一家增长率下降5％而另一家增长率下降75％。如果这样，创始人最好采用不同地方式运行公司。

在Twitter的早期，服务中断如此常见，用户创造了术语“失败鲸”（由Twitter的中断页面上的图形启发）作为“又一次中断”的缩写。失败鲸对于Twitter的业务不是致命的打击， 用户的耐心给了他们很长时间来解决它。 是的，我们搞出了很多笑话，但我们没有离开服务。想象一下，如果一个 Salesforce这样的公司存在“失败鲸”的问题。他们的客户遭遇频繁的中断、无法预订收入或拨打销售电话，那么他们很可能不再使用这个软件了。 客户将使用原来计算机内置的 CRM 。当企业依靠您的软件来完成关键性任务操作时，您的错误可能会导致他们非常痛苦。 因此，消费者业务比企业软件业务能够承担更多的风险。

部署模型也有风险。当客户遇到问题时，您解决错误的速度可能与错误有多糟糕一样重要。您可以将热修复程序推送到服务器并立即为每个用户解决问题，之后客户便可以自己安装补丁，您的修复速度要比通过两周的QA窗口和App Store审核流程以实现最小代码更改更为有效。 Twitter作为一个基于网络的产品很幸运，能够解决他们在服务器端的中断问题。想象一下，在基于客户端的消费产品（例如您的Apple iPhone）存在导致间歇性中断的bug，这个bug除了下一个手机版本之外没有其它解决方案，那这个手机可以被扔进垃圾堆了。

明确部署和风险的复杂性：如果你正在将内部运行软件卖给企业以获得大量资金，那么你会要经历痛苦的程度及冗长的更新时间的双重考验。你会发现，同样的错误，企业软件所要花费的成本比向消费者提供免费的基于网络的服务所要花费的成本高两个数量级。

对世界而言，VMware显然比Facebook更厌恶风险。这不是因为黛安·格林和马克·扎克伯格性格不同，也不是因为他们中的一个是正确的，另外一个是错误的。它们是基于不同技术的不同业务，他们以客户容忍风险的程度为指导采用不同方式发布软件。

你的软件发布方式是你文化DNA的一节

现在，您已经清点了您的业务模型，部署模型和风险偏好，您已经有了一个很好的框架来分析自己使用的发布流程。如果你已经存活了足够长的时间来适应产品市场和一些客户，你应该已经很自然的适应了合理的做法。在创业中，就像在自然界中一样，形式追随功能。你可能会惊讶的发现自己一直在浪费能量去实现一些无关紧要的目标（比如消费业务中的计划预测）！

除了基于此框架分析您当前的方法，您还可以使用它作为过滤器，来确定可以听取谁的建议，可以模仿哪个公司的做法，甚至雇佣哪些领导人。

当您面对多种技术或业务模型，您可能会发现此框架特别有用。初创公司可能非常需要同时支持Web和本地移动应用程序，或者多个客户组（例如，面向消费者和企业需要不同应用程序的双边市场）。在理想的情况下，你的发布过程会根据开发中的产品而变化。但你发布的不仅仅是过程，而是文化和身份。更换一个过程很容易，改变文化却是很困难的。对于一个小公司来说，为不同的团队建立不同的文化更加困难。

如果你在公司里发现多种相互冲突的“发布文化”，你正在处理建立和发布软件过程中一个很困难的执行挑战。当人们基于情感而不是理性的立场时，没有简单的答案。积极的一面：你的团队热情高涨！人们很难记住当冲突肆虐时看到的一丝希望，但这是一个工程师非常关心公司的好消息。

深呼吸，提醒他们发布过程来来去去，但公司的使命和价值观是不会改变的。希望团队能够认同最重要的是为用户提供最好的产品这个观点，剩下的都是可协商的。希望这个框架能够帮助到你。

本文由 伯乐在线 - 努力学python翻译，艾凌风校稿。
英文出处：firstround。欢迎加入翻译组http://group.jobbole.com/category/feedback/trans-team/。

作者 Jocelyn Goldfein ，天使投资人、前 Facebook 和 VMware 工程主管，她因帮助工程师团队在高速增长期快速扩展业务而久负盛名。在 First Round 公司上次的 CTO 峰会上，她分享了不同环境下发布软件的经验，并在如何构建自己的发布流程方面为初创公司提供建议。

关键字：产品经理, 软件

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！