|
等等 你会想写出这些假设，并挑选出最重要的。比如说，“客户希望尽早登机”是最重要的。现在请牢记，如果这个假设是错误的，我们之前做的所有工作将会是徒劳。因此，在假设被证实之前，不要投入太多精力。 那么，检验的最低限度是什么呢?对此的原生术语，即最小可行量或MVP，然而它已经成为了一个时髦词，被不真正了解它的人所曲解。大多数人会说这一想 法的最小可行量是一个切实的主干系统，只需让你在检查时多付5美元，或许会在你的登记证上标记一下，然后通知检票员让有标记的乘客先登机。很简单，不是 吗? 也许是，但还有比它更简单的方法。检测这个假定最精确简单的方法就是支付页面增加一个“点击这里提前登机”的按钮。当有人点击时，弹出一条“对不起， 该‘提前登机’的程序无法使用”的错误提示。之后你就可以测算有多少人点击了该按钮。如果有很多人点击它，那么就知道人们是希望提前登机的。如果没有人点 击它，那么说明人们对这个产品没有需求。 但是多少点击量算多呢?可以拿出实际的数据作为参考。“哇，有一千人点击了该按钮”，你说。“真多啊!这是使用豪华包监测服务人数的十倍!” “不，不是的”，跟你抬杠的同事反驳道，“太少人用了，使用终端机服务的人比这个还要多一倍。” 为了避免这种争论，你可以事先从那个同事认可的数字里选一个来作衡量。你们两个必须统一商量好，如果结果数字比选定数字大，那么之前的假设成立;否则不成立。 但是，你应该怎么来作统计呢?总不能真的去地数点击按钮的次数吧。这种情况下可以使用虚荣(虚假?)度量。假设实际上100人中只有1个人想提前登 机。大家都知道，圣诞节的时候，坐飞机的人是平时的3倍。如果你选择在这时进行测试，那么你的按钮点击次数可以轻易地达到2000人次的目标。这不是由于 这个按钮真的很有用，只是由于圣诞节前后太多人坐飞机而已。 其实，你真正应该采用的是，创新度量。这种统计得出的数字，只与你感兴趣的方面有关，其它的东西都不会对结果有影响。就上面所说的例子，我们只统计点击按钮的人数的百分比。假设有3%的人点击了按钮。这个百分比不会因为旅客突然大量增加而改变。 当然，这个百分比反而有可能下降。因为圣诞节的旅客比较匆忙，无暇顾及其他。所以你要相应地调整你的预期目标为：3%常规旅客会点击按钮。这样，即使旅客突然激增，这个统计也比较稳定。 你甚至可以圈定群体来帮助统计。一个群体是指一组事先选定的人。例如，你可以事先选定一组常规旅客，只有他们可以看到按钮。这样的话，突然激增的旅客就不会影响你的统计了，他们都看不到按钮，因为他们并不是你圈定的群体。 另外，你也可以进行类比统计。可能多加一个按钮会使人们更加不想购买升舱服务(可能很贵)。将你事先圈定的群体随机分成人数相等的两份。其中一份可以 看到按钮，另一份看不到。对比这两份人的统计，你就可以看到添加按钮是否有影响。如果实验中只有4%旅客购买升舱服务，但是你圈定的群体中有8%购买了， 那么你就要考虑将这个差异纳入到将来的计划了。 团队 一旦你确立了一个假设，并用最小可行的方法来验证它，一套明确的度量标准类证明它，是时候去实际践行它的时候了。应该从一名产品负责人开始。他们是你的产品的“乔布斯”-他们会为了保证整个产品的完整性而重新对每一个细节进行授权并签发许可。 你最好写一张卡片(3X5大小或者像Asana这样的列表式任务管理系统)，用来描述你的目的与你将用来证明它的度量。 “挑选一帮经常访港的家伙，将他们分为实验组和对照组”。 当我准备登机检票的时候，我能看到这样一个按钮，能提供给我一次让我尽早登机机会的按钮，如果我点击了它，我就会收到一条表明该服务当前无法使用的错误提 示信息。 这证明了我们的顾客想尽早登机的假设。我们认为该假设表明实验组有超过2%的人点击了有可能能让自己尽早登机的按钮。我们同时也监测了他们购买的其他升 级，他们为了保证推广该功能而不会引起严重的广告效应的登机完成率。 第一段提到了被实验的对象。第二段讲述了一个关于改变用户生活经历的故事。第三段解释了我们为什么进行实验以及我们寻找的尺度是什么。 这些都涉及到一堆(或者是在线To List)按照优先级排序的卡片，并把最重要的需要验证的假设放在最前面。你的设计师们，当他们在做他们当前的任务的时候，将从一堆卡片中摘取最靠前的卡 片。他们将与产品负责人一起设计，看起来就像(按钮放在哪?到底要要怎么表达?)一旦产品负责人认可了相关设计并签了字，设计师们将会亲自把卡片交给程序 设计人员，同时和他们一起工作以实现该设计。 从实施或实际使用的经验所带来的实际问题，一旦实施完成，就会导致花费大量的时间进行重新设计，或许这样反复修改能给产品负责人带来更多的反馈建议。 开发 当你着手开发的时候为你的软件编写自动化测试是一项很好的实践，这样在之后未通过(部分测试)时就很容易知道(是哪里出的问题)。你觉得自己搞定的时候就可以运行测试以确保它们全部通过，当然，你得保证测试能同时覆盖到那些有把握的和所有实验性的功能点。 编码是一项费神的活儿，所以找个人来做结对编程通常更加有效：一个码代码，一个边看变指点(一个人写测试然后把键盘甩给另一个人写代码让测试通过有时也蛮有趣的)。 如果你一直找不到人跟你结对，那么至少得保证你能拉一个人过来评估下你做的变更。在往工程里提交代码之前，你应该总是看看diff (比如说运行 git diff HEAD)。 架构 如果你正在开发一项网络服务(比如Web应用)，就应该按照应用开发十二要素来设计。满足这十二要素的应用程序遵循以下12条原则： 将整个应用的代码存储在唯一的版本控制库里。如果软件的不同部分由不同的版本库控制，那么你应该把它们当作不同的应用，其间无为服务。如果多个应用共 用一个版本库，那么你应该找到它们的相同依赖项，将其放入各自的代码库里。你可以使用Git，因为它是目前最流行功能最丰富的版本控制系统。 明确声明所有依赖项。如Ruby 里可以使用Gemfile，Python 使用requirements.txt，等等。本地的话你可以使用类似Bundler或VirtualEnv这样工具隔离开发环境以确保未使用未声明的依赖。 所有配置值应当作环境变量存储。这包括任何不宜公开的信息：密码、密钥以及所有因部署而有所不同的内容(包括数据库地址和管理员Email)。 所有后端系统 (如数据库或内存缓存( in-memory caches))皆视为服务。本地与第三方服务之间不做区别，它们都通过网络访问。 代码部署分三个独立阶段：构建(编译构建软件);发布(加入环境配置并放到服务器上);运行(执行应用)。这几个步骤应该完全独立：服务器不能在运行时改变其配置，因为发布阶段已经完成;发布阶段不能编辑软件，因为此时构建阶段已经结束。 应用应该作为一系列无共享状态的进程执行，任何进程可以在任何时候被干掉。也就是说所有状态都应该存储在后端服务中。 应用应该完全独立，只通过IP端口(通过设置$PORT)与外界通信，而不应寄存于某些大进程中。 应用应该由各种不同进程类型组成，并可以通过启动新实例扩展。例如，当web 堵塞时，你可以通过开启更多的web类型进程来搞定。 进程应该是可任意使用的，你可以在任何时候启动或停止它，而不用担心任何破坏。 开发和产品间的隔阂应该尽可能地的小——相同的支持服务、依赖、团队应该在两处都被使用。 日志应该是无缓冲写入标准输出(stdout)的事件流。不要由应用负责日志的位置，那是基础设备该干的活儿。 管理任务应该当做是一次性的进程。 你应该使用“12-要素”主机系统，如Heroku，因为它可以强制遵守这些约束。 您还应该 引入"Chaos Monkey"来 进一步确保您的系统的稳健性，"Chaos Monkey"是一个自动化的过程，去激活一个系统的不同元素，以确保它们是健壮的响应中断。例如：进程的是一次性的，"Chaos Monkey"会自动杀死一个随机的生产过程，这能避免开发人员依赖持续性的进程，如果他们犯了一个错误，并且一直没有发现，早期捕捉这个错误则能避免这 个错误以及错误引发的其他衍生物最终导致的灾难性的结果。 |
