透明

透明是一种抽象的概念，笔者更倾向于将其感知为对代码，对运行时程序的掌控感。软件工程师们常常自嘲，“when things work, nobody knows why”。

即使是很小的项目，简单的代码，也要保证其透明性。通常通过下面手段来保证架构的透明性

• 通过 Lint，单元测试，集成测试等在部署前前置地发现问题
• 简单的数据结构和算法。
• 通过日志告诉程序做了什么
• 通过telemetry接口，让我们可以检阅当前应用程序的(数据)状态。
• 在分布式系统架构，需要有tracing功能，方便调试业务问题。这在多用户复用相同逻辑的Web应用中特别重要。通过一个唯一ID能Track到整个业务流。

Testability | 可测试性原则

研发团队的首要任务是提供稳定的服务，然后是提供符合客户需求的、易用和低成本的产品。但是绝大部分的开发者都知道，在提供稳定服务的同时，面对快速发展的客户业务场景，我们还需要不断拥抱变化。Max Kanat-Alexander 在《简约之美：软件设计之道》（Code Simplicity）中提出的软件设计的 6 条法则：

• 软件的目的是帮助他人；

• 相比降低开发成本，更重要的是降低维护成本；

• 变化定律：软件存在的时间越久，它的某部分需要变化的可能性越大；

• 缺陷定律：软件出现缺陷的可能性，正比于你对它所做修改的程度；

• 简洁定律：软件任一部分的维护难度，正比于该部分的复杂程度；

• 测试定律：你对软件行为的了解程度，等于你真正测试它的程度。

软件的目的就是满足客户的需求，而随着时间的推移，用户需求总会改变；伴随着用户需求的改变，软件也需要适应新的需求而做修改，修改必然会引入缺陷；如果要排除缺陷就必须进行测试。

但目前软件行业的现状大部分面临这样的问题，即无论花多大的成本去测试，真正的用户行为背后的需求总是不可能被完全满足的，缺陷总是会有的，这时我们最后的安全网就是“灰度发布”（又名“金丝雀发布”）。在采用用户真实行为作为终极测试的同时，通过控制变更范围尽可能的减少风险；一旦真的有缺陷可以快速回滚，尽可能以最大程度降低影响。

测试驱动开发