实践背后的原则：理解我们为什么会做我们所做的事情

原则和实践是两回事。原则是普遍适用的真理，而实践则是原则的具体应用，会因情况而异。

理解二者之间的区别是通往智慧的重要一步。当你理解了行为背后的原则，你就能明白我们为何会做我们所做的事。你不仅理解了规则，也明白了何时应该打破规则。理解行为背后的原则能帮助你更加灵活，并在日常决策中做出明智的判断。

让我们来探讨软件工程领域的一些原则和实践。

测试与验证

为代码编写测试通常被认为是一种良好的实践。如果我们都同意应该编写测试，那么接下来可能会问到以下问题：

1. 多少代码覆盖率才算足够？

2. 我应该编写什么级别的测试？单元测试、集成测试还是端到端测试？

3. 什么情况下可以不编写测试？

这些都是很好的问题。业内专家已经发表了他们的看法，我也有我的看法，我相信你们也有自己的看法。总的来说，我对这三个问题的回答是：

1. 力争达到 100% 的代码覆盖率，但不要过于执着。有时候，为了那最后 5% 的覆盖率而付出的代价可能并不值得。但如果你不打算测试某些内容，你应该有一个充分的理由来解释为什么不这样做。

2. 尽可能将测试层级下移到测试金字塔的底部。大多数功能都可以在单元测试和集成测试层面进行测试，这些测试的优点是易于编写且运行速度快。而像电商网站的结账流程或Web应用程序的登录等关键工作流程，则应该使用端到端测试进行验证。

3. 在某些情况下，不为代码编写测试可能是合理的。例如，如果你只修改了一行 CSS 代码，除了通过查看 UI 进行快速手动验证之外，可能没有其他好的测试方法。如果你在一个没有现有测试基础架构的遗留代码库中进行小幅更改，并且该代码库中的代码很少更改，那么不编写自动化测试可能也无妨。

以上是一些关于测试的通用实践以及我的一些简要看法，但这些实践背后的原则是什么呢？我想到的一些原则（排名不分先后）包括：

1. 我们应该尽可能降低部署风险。（编写自动化测试、提高测试覆盖率、进行代码审查以及实施持续集成流水线是我们践行这一原则的方式。）

2. 我们应该优先选择自动化重复性任务，而不是手动完成。（编写自动化测试就是我们践行这一原则的方式。）

3. 我们应该优先采用快速反馈循环，以便迅速发现错误。（编写自动化测试、将测试层级下移以及使用持续集成流水线就是我们实现这一原则的方式。）

4. 我们应该把时间花在最重要的事情上，从而最大限度地为企业创造价值。（例如，不必执着于达到 100% 的测试覆盖率，或者对于难以验证的小改动，可以酌情决定不编写测试，这或许就是我们践行这一原则的方式。）

特性分支

对于拥有大量开发人员的代码库，一种典型的协作策略是使用特性分支。主分支作为代码库的权威来源，开发人员在编写新代码时从主分支创建特性分支。当开发人员准备将代码合并回主分支时，他会创建一个合并请求，进行代码审查，根据反馈进行必要的修改，然后合并代码。

创建合并请求时，一个好习惯是确保你的特性分支与主分支的最新代码保持同步。例如，如果你的特性分支比主分支落后 10 个提交，那么这 10 个提交中的更改可能会影响你正在开发的功能。

通常情况下，如果其他人也修改了你修改过的相同代码行，你就会遇到合并冲突，并且无论如何都必须从 master 分支拉取最新版本到你的分支中来解决这些冲突。

但有时问题会更加隐蔽，某些更改会影响你功能的实际效果，而这些更改实际上并未直接修改你正在处理的文件，也没有导致合并冲突。如果你在代码距离主分支还有 10 个提交时就合并了代码，那么一旦两组更改都合并到主分支上，你可能会遇到功能失效或测试失败等棘手问题。

那么，如果你的特性分支落后主分支几个提交，就一定会有问题吗？不一定。如果缺失的提交没有涉及到你正在处理的代码区域，即使你比主分支稍落后一些，合并应该也没问题。或者，如果你正在开发一个大型单体应用，整个工程团队都在使用它，而且开发人员每天都会提交数百次代码，那么保持与最新代码同步很可能是徒劳的。只要你在合并时代码保持相对的更新，就应该没问题。

那么，让我们再次回顾一下这种做法背后的原则。为什么我们要让特性分支与主分支保持同步，与最新版本保持同步呢？一些原则包括：

1. 我们应该尽可能降低部署风险。（这与上一节的第一条原则相同。确保我们的特性分支也包含主分支中当前已有的其他更改，有助于我们避免意外情况，这也是我们实现这一原则的一种方法。）

2. 我们应该避免那些很容易预防的错误。（我们不想在两个各自独立运行良好的分支合并后出现问题时，还要费力排查故障原因。我们也不想在合并到主分支后，因为原本可以轻松发现问题而导致功能损坏，最终不得不亡羊补牢。保持特性分支的更新是践行这一原则的方法之一。）

沟通和Slack礼仪

我们再来看一个例子。这次我们将讨论一个技术性不那么强，但对组织中个人如何协作至关重要的话题：沟通。

许多公司使用 Slack 进行即时通讯。Slack 允许您在公共频道、私密频道或私信中发送消息。公共频道中的消息对所有人可见，私密频道中的消息只有受邀加入该频道的人才能查看，而私信只有对话双方才能查看。

假设你遇到一个问题，想向另一个团队咨询。你应该把信息发送到哪里？

一般来说，你应该优先使用公共频道，而不是私人频道和私信。

在公共频道发布消息有诸多好处。它允许任何感兴趣的人参与对话。它确保合适的人员参与其中，并减少了在各种私人频道和私信中与不同群体多次重复相同对话的需要。此外，由于问题会分享给整个团队，而不是只有某个人知道，因此也减轻了回答问题的负担。更重要的是，Slack 的搜索功能可以让其他人将来搜索相同的问题并找到所需的答案。

并非所有信息都应该在公共频道中发布。有些对话可能更私密，例如讨论招聘决定或薪酬调整，或者涉及个人隐私。这类信息更适合通过私密频道和私信发送。

所以，我们应该尽可能在公共渠道发布内容。这是惯例。现在让我们来看看这种做法背后的原则：

1. 我们应该让合适的人参与到任何对话中。（如果你直接给一个人发消息，可能需要花一些时间才能找到合适的人或团队进行沟通。或者，即使你找到了可以提供帮助的人，团队其他成员也可能需要了解情况。在公共频道发布问题是让每个人都了解最新进展并贯彻这一原则的一种方法。）

2. 我们应该尊重同事的时间。（如果你直接给某人发消息，就等于把回复的责任全部推给了他们。这个人可能很忙，可能不在办公室，甚至可能根本不知道答案。在公共频道发布问题可以让有能力且有空的团队成员来回答，这也是践行这一原则的一种方法。）

3. 我们应该进行高效沟通。（我数不清有多少次，为了最终达成共识，我不得不连续四次与四个不同的团队重复同样的对话。在公共频道发布问题可以避免这种重复，也是践行这一原则的一种方法。）

4. 我们应该让人们更容易找到相关信息。（Slack 的搜索功能使 Slack 成为一个很棒的非正式文档工具。使用 Slack 和 wiki 页面是实现这一原则的两种方法。）

避免陷入货物崇拜

我们已经探讨了一些方法及其背后的原则。如果这些方法对你无效，那也没关系！

实践的妙处在于其本质上的灵活性。它们可能因公司、国家或文化而异。但如果你重视并理解这些实践背后的原则，你就能制定出适合自身独特情况的实践方案。

另一方面，要警惕那些不理解其背后原理就盲目遵循既定做法的人。对软件开发策略或设计模式教条化会导致僵化、低效，以及盲目照搬。你应该始终能够解释你这样做的原因。

实践会改变，但原则永存。理解二者之间的区别是一项重要的技能。