[译] 独自开发时一些良好的工程实践

• 原文链接：Good Engineering Practices while Working Solo
• 原文作者：Shalvah
• 译者：Alisa

当你不得不独自面对开发工作的时候，你是如何充分利用这一点的呢?

大多数开发者是作为团队的一员来进行开发工作。然而，在我们职业生涯的某个阶段，我们都会(或将会)经历独自工作。虽然很多产品开发都需要能够管理或与团队的其他成员一起工作，但在独自工作时养成良好的实践也同样重要。

关于“独自工作”的简单介绍

Solo通常是指独自做某事。但是在这里我们指的是在非正式的、非结构化的环境中由一小部分人所做的任何事情。可能只有你，或者你和其他一些人。例如包括:

• 一个开源项目，如包或库
• 一款个人产品，可以是商业的，也可以是免费的
• 为客户提供的自由职业

这里的共同之处在于，没有像在公司那样的既定规则。

我为什么要为我的工程实践而烦恼呢?

以下是它们重要的几个原因：

你会成为你团队的财富。

让我们考虑一下当你加入一个团队时可能出现的情况:

• 你加入一个遵循你习惯的开发实践的团队。太棒了！这意味着你将从第一天就准备好为团队做出贡献。
• 你加入了一个遵循一系列不同实践的团队。如果你已经掌握了良好工程实践的一般概念，那么你应该不会花太长时间来适应它，并且你很快就会变得高效。
• 你加入的团队没有遵循任何好的实践(哦，不！)在这种情况下，根据团队的不同，你可能能够运用你的知识并改进他们的流程。否则...也许只能离开。

不管怎样，这都是双赢。

你会成为一名更好的开发人员

软件工程不仅仅是编码。将产品从概念引入到发布过程中涉及到很多活动的部分，然后让它继续运行下去。反复灌输最佳实践将帮助你保持正轨，避免受挫。

如果你热爱编程(就像我一样)，那么在开发新东西时，总有一种诱惑会让你马上开始编写代码。但随着时间的推移，我发现，在保持独自工作的灵活性的同时，适当地建立某种结构，可以帮助我避免前进道路上的许多障碍。

让我们考虑其中一些好的实践。

遵循工作流

工作流是将你头脑中的想法转化成成品所涉及的一系列步骤。你的工作流程应该包括以下内容:

• 当决定更改时，我要遵循什么流程来实现它?
• 我如何向最终用户交付该产品的新版本?
• 我如何跟踪对该产品所做的更改?
• 我如何跟踪这个产品的缺陷、问题和未来计划?

为什么？ 在没有定义工作流的情况下,完成工作似乎更快(“只需编写代码并推送到master分支”)，但是随着项目复变得越来越复杂，你会发现对工作流有明确的定义可以更容易地确定需要做什么，并且专注于它。在团队中工作时，工作流成为帮助每个成员提高生产力的管道。

你可以做什么：

• 使用issues(问题) (GitHub、Gitlab、BitBucket或任何托管你代码的地方)。Issues帮助你跟踪缺陷、功能请求和对项目的主要更改。此外，写下一个问题的标题和描述会迫使你在头脑中清晰地表达你的想法，并准确地定义问题是什么以及解决方案应该包括什么。通过添加Trello和GitHub Projects等项目管理工具，你还可以更进一步。

• 使用pull requests(拉取请求)。许多开发者在独自开发时更喜欢直接把代码推到master。然而，通过pull requests进行更改有很多好处。这样操作更容易看到新功能或bug修复中涉及的所有更改，以及合并时它们如何影响代码库。此外，当pull requests与issues同时出现时，可以更容易地观察项目是如何演变的，而不必阅读代码就能找出问题所在。

• 复查你的代码。 这听起来可能很奇怪，但是你应该像检查其他人编写的代码那样检查自己的代码。有些人建议做一个PR，离开几分钟或几个小时，然后在合并或更新之前再回来查看代码。==代码复查，脱离你的IDE，让你用(某种程度上)新鲜的眼光看你的代码，帮助你发现错误和识别你忘掉的东西。代码复查还会迫使你质疑自己。为什么我要用这种方式实现呢?会出什么问题呢?还有更好的办法吗?==

• 保持有意义的Git历史。 尝试像在团队中那样提交代码——要避免一次提交大量代码，保持提交集中，提交信息有意义。与代码评审一样，编写描述性提交信息会迫使你放慢速度。我在这次提交中想要达到什么目的？我是怎么做到的呢？

在某些情况下，你可以允许自己违反规则。例如，您可能会决定，对于实在很小的问题修复(例如纠正一个错别字)，直接推到master也是是可以的，以避免拖慢进度。

编写可重用的组件和模块

思考要遵循DRY、SOLID、FIRST的原则。用更小的、封装的、可重用的组件来构建软件。使用像Bit这样的工具来创建你最喜欢的构建块的集合，并保持更新。最终你将能更快地构建更好的软件。

编写文档

呃，文档。许多人都知道，很少有人会写，喜欢它的人更少。在经历了兴奋的编码过程之后，编写文档通常是一件困难的事情。我该怎么用文字抓住代码的所有复杂之处?

为什么？ 人类是不可靠的。我们会遗忘，我们会有生病的时候，或者我们会离开一个项目。文档能确保知识不受某一个人的束缚。文档还可以帮助开发人员全面了解项目并保持专注。

你可以做什么：

• 要清楚你不是在写书。 文档不是要写成文学著作。没有人给你打分。不要试图去解释所有的东西。保持简洁明了。有时候你只需要罗列几个要点就足够了。
• 编码前做记录。 记录产品的界面-它将如何从外部开始运作。它将作为规范，在构建软件的过程中给你一些指引。
• 编码后做记录。 再次强调，写作时要像一个旁观者一样。什么是重要的？你需要知道什么才能使用它(或贡献它)？在开发过程中，规范可能会发生变化，因此在编码完成后，检查一下编码前所写的文档，是否仍然是正确的非常重要。
• 编码时做记录。 这主要适用于用代码编写文档。有很多关于代码文档化的文章，所以我不会详细讨论这个问题。
• 划分单元来工作。 以上所有的原则都适用于划分单元。例如，一个单元可以是一个函数、一个类、一个新功能、行为的改变、一个模块或整个产品。如果记录一件工作看起来非常困难，那么尝试将它分解成更小的单元(或者，在单元的基础上再往上提升层次)。

沟通

沟通主要适用于与小团队或为客户提供服务。

为什么？ 透明度关系到责任。当你知道你必须向某人报告你的交易时(无论是你的同事还是你的老板)，这有助于你保持专注。这也是许多公司召开站立会议的原因之一。

另一个原因是，当团队中的成员遇到问题时，可以通过与客户或其它团队成员沟通得到轻松解决。我已经记不清有多少次我沮丧地大喊，“我的更改没有显示出来”，结果另一个团队成员告诉我，“哦，我想我做的一些修改，可能导致了你的修改无效”。

你可以做什么：

• 当你遇到无法预料的困难时，要让你的团队和客户知晓。
• 定期向客户汇报项目进展情况。不过，尽量不要太技术化。
• 当计划有变化时，要让你的团队知道。
• 消除沟通的障碍，这样每个人都能容易地知道其他人在做什么。找到并使用最适合你们的工具——WhatsApp、电子邮件、Slack等等。

本质上，保持反馈环节的活力。它消除了相关的各方之间的许多摩擦。

监控

为什么？ 总会有一些事情会出错的。部署可能会失败，人会犯错，异常可能会被抛出，流程会被打破。重要的是要做好监控的准备，以便您能够更好地处理这些故障。监控是反馈环节的另一部分;它阻止你在不知道产品实际性能的情况下，在象牙塔中进行构建。

你可以做什么

• 记录日志和指标。 不必羞于在必要的地方console.log()。记录得信息多总比太少好。但是，一定要避免让不必要的细节污染日志，以便能更容易地进行筛选。
• 要知道日志的位置，并建立一个系统以便于查看。 这可以是像SSHing到服务器跟踪日志文件这样基本的操作，也可以是像将日志发送到ELK堆栈这样高级的操作。但重要的是，当你调用console.log()(或其他用于记录日志的方法)时，你要知道在哪里查找这些日志。
• 不要吞下错误。 虽然你的应用程序应该是可复原的(在出现错误时能够恢复)，但记录你没有预料到的错误是个好主意。例如，如果你正在调用一个API来获取用户创建的内容(例如tweet)，那你应该做好需要处理404 Not Found的准备。但是来自API的另外的意外错误，你应该记录。我曾经遇到过这样的情况，因为我没有记录这些错误，我不知道我已经超出了访问的速率限制，导致我的应用程序被列入了访问API的黑名单。
• 检查你捕获的日志和指标。 这可以是手动的，也可以是自动的。我曾经遇到过这样的情况:我实现了一个“简单的”修复，然后部署了它，接着继续我的愉快之旅，但后来我才意识到它没起作用。从那时起，我开始在部署之后一段时间内监控应用程序日志，以验证事情是否如预期的那样进行。

监控策略可以采用不同的形式，从简单的控制台输出日志、文本文件到第三方应用(如Sentry、Bugsnag和Elastic APM)。选择一个适合你的来使用吧。

观察和迭代

这是一个最佳实践，也是所有其他实践的指南。没有适合所有人的通用公式。人们习惯于不同的工作流、监控策略、文档样式等等。这就是为什么保持观察和迭代是如此重要。

你看到了，但你没有观察。区别很明显。
-夏洛克·福尔摩斯，波希米亚的丑闻

观察包括批判性地观察行为或表现。通过观察，你将所见与所知联系起来，并从中推理出事实。当独自工作时，你通常无法从高级案例研究和A/B测试中获益，因此你可以从“非正式”来源(如人们的评论、问题报告和日志)中获取线索。

观察之后就是迭代。迭代是针对观察结果对产品进行改进，然后再进行观察，以此类推。观察之后，下一件事是得出结论，然后实施它们。但这还没有结束。

一个示例场景：我有一个应用程序，它显示项目列表和它们的创建时间。但时间是UTC时间，所以对于很多使用我的应用的人来说，显示的时间是错误的，这经常让他们感到困惑。

我决定通过显示“UTC”来解决这个问题(例如，显示“5:30 pm UTC”)。这个方法很有效，而且不容易混淆。但我最终意识到，我为什么要让用户自己转换到当地时区呢？因此我将其更改为将显示的时间转换为用户的时区。这样好多了。

在与使用我应用的用户交谈之后，我意识到对他们来说最重要的事情是大致地知道一个条目存在的时间，而没必要是确切的时间。为了响应这个观察结果，我做出了一个更新，将所有时间更改为相对时间(“5分钟前”、“2小时前”)。时间的准确性已不复存在，但它让我的用户工作变得简单得多。

这也适用于你的内部流程。这些指导方针都不是一成不变的。在选择实践时，重要的是观察哪些有效，哪些无效，并以此为基础进行迭代。不断做出改变，直到找到适合自己的。

结论

理想情况下，在结构化的产品开发环境中，有许多不同的专门的角色起着重要作用，从产品所有者到开发人员。当你独自工作时，重要的是你要意识到，你正在填补许多(也可能是所有)这些角色，所以可以按照自己的意愿来行事。最好利用这种自由来创造一个让你更有效率的结构。这可能需要一点额外的时间和精力，但我向你保证这是值得的！

感谢您的阅读，请随意评论和提问！

转载于:https://juejin.im/post/5c4f1148e51d451bfb35b783