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

• 原文连接：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小时前”)。时间的准确性已不复存在，但它让个人用户工做变得简单得多。

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

结论

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

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