构建无可指责的工作环境

我曾经在一家软件开发公司工作过。那是一家普通的公司：没什么特别糟糕的地方，但也没什么特别出彩的地方。它和其他类似的公司一样，也存在同样的问题：

最终结果令客户失望。

当然，管理层里的每个人都迫切地想知道，到底是什么原因（或者“谁”）造成的。在工作中，听到这样的话是很正常的：“项目失败是因为你写了低质量的代码，现在客户正在离我们远去。”

这有什么帮助吗？没有。在那里工作愉快吗？没有。所以，我一觉醒来就决定不再在这家公司工作了。

最丑陋的是，我是这家公司的创始人。

我们能否一致认为责备是没有用的？

在进一步描述我们如何改变环境，以及它如何影响我们的结果之前，我想先明确一点：责怪别人是行不通的。为什么？

我们可以做什么呢？我们可以用另一种方式构建我们的流程！

你能想象出问题的情况吗？比如你的生产环境因为依赖项版本不匹配而停止工作，或者因为你在string变量中犯了一个愚蠢的拼写错误。

这种情况经常发生，这并不奇怪。

所以，我们必须做好准备来应对这种情况。我们必须制定一套可行的规则和实践，以避免可能出现的错误，并处理那些我们未能及早发现的错误。

但怎么做呢？

通常很难定义需要几天甚至几周才能完成的大任务。这类任务没有明确的范围和“完成”标准。

所以，事情就容易出错了。由于任务范围太广，两个人对任务的理解会有所不同。他们会对任务的不同部分给出不同的优先级排序。最终，很容易就会有人说：“你做得不好，你没拿到任务。”

此外，代码的审查和质量控制也会变得非常困难。我们都知道，审查 1000 多行代码非常困难。

我坚持任务应该小（不超过4小时），并且要有明确的范围。最好有五个小而明确的任务，而不是一个大任务。

这减少了误解的可能性，并使双方能够轻松跟踪进度、控制截止日期并把握项目脉搏。

代码中的错误越早发现，对项目就越有利。这张图说明了允许错误流入生产环境的代价（包括时间和金钱）。

糟糕的代码不应该进入master分支，甚至不应该被人工审核。我们可以自动化处理！静态分析、linting、各种测试以及其他指标都应该在之前通过。如果代码出现问题，你的代码就不会进入分支master，审核人员也不会审核它，直到所有检查都通过为止。

这样就创建了清晰透明的质量规则，这些规则必须得到遵守。这已经成为法律。

但错误终究还是会发生！这真是令人悲伤的现实。但如何对待错误是你的选择。你可以因此而愤怒沮丧，也可以从中汲取教训。

我更愿意从自己和他人的错误中吸取教训。这怎么可能呢？

每当生产过程中出现问题时，你都需要追踪质量门是如何导致问题发生的。我们忽略了什么？

在你的团队找到答案后，你应该自动执行此检查，以确保下次不会再发生类似问题。创建一个 linting 规则或编写回归测试。

以下是我们如何做到这一点的一些真实示例。

python每当我们的项目出现问题时，我们都会向CI 流程django添加一条新规则，或者为我们公司的 linter编写一条新的 linting 规则。这样，我们就能保证类似的问题不会再次发生。

这对我们的前端 javascript/项目也同样适用vue。

有时候，你失去客户并不是因为你的代码不好，而是因为你没能与客户建立起清晰的沟通渠道。然后，你会被指责所有不好的事情！

我们过去在这方面遇到过很多问题。漫长的迭代和反馈周期让我们精疲力竭。我们没能足够快地解决错误和新的需求。

这个问题的答案很简单：

我们通过几种有用的做法实现了所有这些目标：

我们会尽快收集客户的反馈。客户始终了解项目的进展情况：哪些工作已经完成，哪些工作正在进行中。

这样一来，责怪谁就变得困难重重，毫无意义，大家齐心协力，共同打造出优秀的产品。说到底，这才是我们追求的目标，不是吗？

“不责备，只纠正”的方法彻底改变了我们的工作方式。

自从我们实践这些措施以来，我们从未失败过任何一个项目。我们也没有因为冲突而失去过任何一名工程师。

当然，本文并未涵盖我们日常生活中使用的所有功能和技巧，但您可以在RSDP（可重复软件开发流程）主页上阅读更多有关我们工作方式的信息。您也可以在 GitHub 上关注我，了解我们构建的工具。