正文
能否通过命令行构建和部署？
团队的新成员能否快速理解代码？
工具和IDE必须可以自动化地执行例行任务、减少阻碍或时间来简化手动任务，从而使我们能够更好地工作和生活。工具绝不能是强制性的，如果代码必须用特定的IDE才能生成或者编译，那绝对不是在秉承云之道，也没有在遵循简单性原则。
任何可以通过命令行完成的工作，都可以使用脚本或者持续集成工具自动化地完成。因此，如果能使用命令行来构建、测试和部署应用程序，那么就可以自动化执行所有这些任务。
这似乎是一个尖锐的观点，大家有权反对。然而，至少在读完这本书之前，可以尝试在所有开发工作中遵循这些准则，它一定不会令你感到失望。
那些声称无须使用云端或无须遵循简单性的人都将对他们创造的或不愿摒弃的复杂性而感到羞愧。
云之道
采用测试驱动进行开发。测试一切，处处测试。
测试是抵御程序偏离期望方式而运行的首要且最好的方法。
几乎每个人都赞同进行测试，但在应该进行什么程度的测试这一点上，很少有团队能达成一致。在解答这个问题之前请先思考：为什么需要测试软件？
当然，我们想要编写完美的软件，希望客户满意，想通过软件赚取大量金钱。但是，测试的核心不是这些。在根本层面上，测试可以给我们信心。
你是否经历过这种时刻：在某种场合下，有人要在一些重要的和有影响力的人面前展示你的应用程序？你是否还记得在关键功能测试之前感受到的恐慌？
恐惧
缺少测试是产生恐惧的根本原因。
感到恐惧是因为担心出现以下情况：应用程序执行的不确定性会影响到整个系统，导致难以估量的压力、系统故障，最坏的情况是在生产系统中出现客户可感知的问题。
我们需要做的是树立信心，以信心取代恐惧。对系统的信心是不断累积起来的，它始于最小的可测试单元。从那一刻开始，随着代码库的扩展，信心不断建立，并通过测试不断完善。
图1.1进行了详细说明。一个类通过了完全的单元测试，我们就对这个类树立了完全的信心，接着对库中所有的类进行单元测试，这样就对整个库树立了完全的信心。相反地，如果无法信任应用程序的构建块，那么对整个应用程序的信心就会降低。从类、库到服务，如果缺乏测试，我们的信心就会呈指数下降。
图1.1 在微服务生态圈中测试信心的区域
只有完全信任构成这个代码库的所有库类，才能对整个服务树立信心。最后，只有当服务生态系统内的每个服务都经过充分测试（无论是内部还是多个服务边界间的集成测试）时，我们才能信任整个服务生态系统。
大家可能经常会遇到这类情况：团队负责人认为不值得在测试上耗费大量时间。进行测试会产生很大的开销，这很容易通过电子表格计算。为了反驳这种观点，可以参考以下的案例。
当在本地构建应用程序时，可以使用所有能想到的工具。可以连接调试器，可以设置和命中断点。在某些情况下，甚至可以暂停一个应用程序，操纵内存中的数据，然后恢复。这给了我们产生信心的错觉，在调试器上花费的时间使得集成和单元测试被认为是不必要的。
再考虑以下场景：我们正在构建的不是软件的一小部分，并且软件部署在离我们只有几英尺的电脑中。想象一下，假如我们实际上构建的是一艘将要发射到外太空的太空船，一旦启动，就无法再接触它，无法抓住螺丝刀再进行最后一刻的调整。如果在远离基地的几百万英里外，如某些部件发生灾难性的故障，那么太空船的整个旅程就将结束。
在云端部署时，无法进行大量的手工控制。它虽不像发射卫星那么复杂，但是失去了对实例的实际控制，不能设置断点，通常也无法进行运行时自我检查。
如果下次再有人挥舞电子表格，声称测试成本太高，我们只需回复和询问他们产品在每个阶段构建完成与完全失败的成本，因为这是测试的实际成本。
回到信心层面，如果对程序正常运行充满信心，那么就可以将这种信心作为发挥其他优势的基石，如持续交付（下面讨论）。
这一切的前提是，我们应该采用测试驱动开发[2]。必须测试所构建的每个服务的一切内容，不管是内部还是外部的，以此建立对服务的信心。
