InfoQ|得了谷歌的病，技术选型：没有谷歌的命( 二 ) 作者|Gareth译者|无名策划|蔡芳芳、Tin

你可以决定什么时候开始遵循最佳实践
谷歌的系统必须全天候在线，他们的系统设计水平达到了极致。当你还没有达到谷歌的规模时，不用完全遵循这个规则。
当然，开发人员也不能打破所有的规则。毕竟，你将公司愿景的控制权交给了写代码的人，并且相信他们能够开发出高规格的系统。
我们以自动化测试为例。自动化测试意味着开发人员除了写代码实现功能，还需要写代码来检查功能是否正常。我在面试技术人员时总是会问到测试方法，如果对方告诉我他们不相信测试，那面试就结束了。
但从另一方面看，做正确的事情是很耗时的。如果你所在的是一家年轻的公司，你的产品在不断变化，旧功能不断被新功能取代，你会发现代码库里的大部分代码过不了多久就会被丢弃。
最好的策略是使用混合策略。有时候你确实要非常严格，比如我们的账单和支付系统一直都要经过全面测试。但在早期，纯粹用于向用户展示内容的代码都没有经过自动化测试。用户会向我们反馈问题，然后我们再解决。此外，我们知道用户体验会快速发生变化，测试只会碍手碍脚。
处于这两个极端之间的一切都由团队成员来做出判断。理想的初创公司工程师应该知道遵循最佳实践的重要性，但也知道何时何地可以打破规则。
向未来借时间
留着系统的一部分不做测试，是一种典型的技术债务：为了速度而抄捷径，并且知道需要在未来的某个时间点回过头来解决遗留问题。
你和开发人员之间应该会存在一种“健康”的紧张关系。他们会说“我们想要仔细开发这个功能，这样它就能用上10年” ，而你会说“快做好，这样我们就能知道是否有人真的想要这个功能” 。每次你赢了，就欠下了技术债。随着抄捷径次数增多，技术债就会堆积起来。
相关的讨论需要公开进行。公司应该使用问题跟踪软件来记录想要开发的功能和因为抄捷径而遗留下来的问题。当你在未来回过头来想解决遗留问题时，这些记录就变得至关重要。
出点故障也没事
如果Gmail宕机十分钟，好像整个世界都会陷入恐慌。相比之下，初创公司用户基数小，产品也相对简单，所以可以承担一定程度的风险。快速迭代可能会破坏一些东西，但结果尚可承受。
但如果你一直靠近风头，冒着偶尔翻船的风险，就必须有一个可以快速纠正航向的系统。
CI/CD工具能够获取代码、构建产品、执行测试，并将产品部署到服务器上。这样只需要一个步骤就可以快速轻松地发布新版本。如果你选对了工具，还可以进行“回滚” 。在部署新版本时，先看看它是否有bug ，如果有，就恢复到以前的状态。你可以自由地做出修改，更好地应对负面后果。
如果你面临的是更严重的宕机风险，该怎么办？这取决于你的产品，你可能还是要冒险一试。如果公司规模足够小，在出现故障时，你可以亲自联系关键用户。如果你能够恰到好处地解释故障缘由，你甚至会发现早期用户为能够成为新产品的用户而感到庆幸。
你可以惹恼用户
规模小意味着你需要笃定地考虑一些事情的优先级。很快，你会发现自己会优先考虑某些用户的幸福感。
在Housekeep ，我们很早就意识到，提升清洁工的幸福感是我们最重要的目标。一个沮丧的清洁工离开我们的平台，可能会让20个或更多的客户感到挫败。
同时，我们必须为客户提供“足够好”的在线体验。只要得到好的服务，一般客户就可以忍受不完善的用户界面。
我们的内部用户充当了炮灰，我们为他们开发的工具很粗糙，系统体验也不好。不过我们“逃过一劫” ，部分原因是因为我们坐在他们旁边，他们可以看到我们正在努力解决问题。
我们的客服和运营团队具有极高的容忍度。他们知道我们在帮他们解决问题，他们遇到的系统问题正是我们要解决的问题。