「译」当你独自开发时，你可以这么做

• 原文地址：Good Engineering Practices while Working Solo
• 原文作者：Shalvah
• 译文出自：阿里云翻译小组
• 译文链接：github.com/dawn-plex/t…
• 译者：靖鑫
• 校对者：也树，灵沼

发个小广告，阿里云中台招前端/Java，P6及以上，base 北京/杭州，hc 非常多，机会难得，帮你过寒冬，如果有兴趣的朋友也欢迎联系 yeshu.lrt@alibaba-inc.com 进行沟通。

进入正题，本次分享的是一篇不那么干的干货。

当你独自研发（Working solo）时，你该如何充分发挥自己？

大部分开发者都在自己的团队里工作，不过有些时候，我们也会不得不独自研发，固然大量产品研发离不开团队的管理和协作，但是在个人研发时，遵循一些工程实践方法同样重要。

什么是 Working solo

Solo 一般指独自做某件事，但是在本文里，它特指一个人或一个小组在非办公环境下进行项目研发，例如：

• 开源项目，例如一个 package 或 library
• 个人项目，可以是收费或免费的
• 自由职业者

上述示例的共同点是：你在开发时，并不会受到像公司里那样的约束。

为什么需要关注工程实践

原因之一是你将会成为团队不可或缺的财富。

我们设想一下你加入一个团队时最初的场景：

• 你所加入的团队遵循的实践规范和你之前的一致，那么你会很快融入这个团队。
• 两者不一致情况下，如果你之前遵循了最佳实践，那么用不了多久你也会融入。
• 最糟糕情况是，如果你所在团队没有遵循最佳实践，你可以推广你的经验来改善团队流程，要不然只能离开了。

不管怎么说，我们期望的还是双赢。

另外一个原因是你还会成为一名更优秀的开发者。

软件工程可不止编程，一个产品从概念到上线需要考虑很多事情，遵循最佳实践可以帮助你走上正轨，少一些挫折。如果你钟情编码，那么当你做一些新事情时，总会有一种诱惑让你跳过其他事情直接埋头编码。但是随着时间的推移，我发现，遵循一些最佳实践会让我们在享受独自工作带来的灵活性的时候，同时帮助我们规避掉一些障碍。

现在，让我们考虑一下下文提到的一些最佳实践吧。

遵循一个工作流程

一个工作流包含许多步骤，这些步骤包含在将想法转变为产品的过程中，下面是一些你的工作流中需要考虑的事情：

• 当决定要变更时，我该遵循什么流程来实现它？
• 我该如何发布一个新版本给到使用者？
• 我该如何追踪产品所做的修改？
• 我该如何追踪Bug、问题以及未来的研发计划？

为什么要做上述思考呢？不需要任何工作流（直接编写代码，然后推送到 master 分支）看起来是最快的方法，但是随着项目规模和复杂度的扩大，你会发现，有了清晰的定义，就可以更容易确定做什么和关注什么。当在团队中工作时，工作流会帮助每个成员更具生产力。

你可以这么做：

• 使用 issues（GitHub、Gitlab、BitBucket 或者你自己的代码托管平台）。Issues 可以帮助你追踪 Bug ，功能需求和重要变更。另外，编写 issue 标题和描述会强迫你细化头脑中的想法，定义好解决方案包含的内容，你可以使用诸如 Trello 和 Github 这样的团队管理工具来进一步实践它。
• 使用 pull request 。许多开发者自己工作的时候倾向于直接推送到 master 分支，然而，通过 pull request 来创建变更有许多好处，它可以很容易地看到一个 feature 或 bugfix 中的所有变动，以及合并时对基线产生的影响。当一个 pull request 关联了 issues 后，我们会更清晰地看到项目的演变过程，而非通过阅读源码的方式。
• Review Code 。这听起来可能有点奇怪，不过我们的确需要 review 别人代码一样 review 自己的代码。有人建议可以先提交一个 pull request ，然后离开一段时间，随后在合并功能前，在远离 IED的情况下，保持新鲜感地开始 review 自己的代码，这会帮助我们捕捉错误，发现我们所遗忘的事情。 Review Code 还会迫使我们思考为什么要用这种方式实现？什么情况下会出错？有没有更好的实现方式？
• 维护有意义的 Git History ，尝试做像你在团队里做的 commit ，避免大量 commit ，保持语义化的 commit message 。就像 code review 那样，编写具体的 commit message 会迫使你放慢节奏，开始思考：我在这个 commit 里实现了什么，我是如何尝试实现它的？

在某些情况下，你可以允许自己打破上述约定，例如你或许会决定对于一些很小的修改（例如拼写错误）可以直接推送至 master分支，避免整体节奏变慢。

不管你将哪些建议融入到你的工作流里，重点都会是是这种意识的建立。一个成功的产品的不会凭空发生，他们一定是建立在爱和呵护上的，保持这种意识意味着你会放慢节奏，观察你遇到的痛点，并且开始思考用某些方法和工具来改善它。

构造可重用的组件和模块

遵循 DRY ，SOLID 和 FIRST 原则进行思考。使用较小的，封装的可重用模块来构建你的软件。使用像 Bit 这样的工具来创建你喜欢的模块集合并且保持更新，你会从中受益，开发也会愈加快速 。

编写文档

文档是老生常谈的话题，但是却很少有人坚持做它。在兴奋地编码之后，记录它通常是一件难事，我该如何通过文档来记录代码的复杂逻辑？

坚持写文档的原因很多，我们会犯错，会生病，会忘记许多事情，会调整项目，文档可以确保项目知识不会束缚于一个人，也可以帮助开发者全面了解项目后然后保持专注。

你可以这么做：

• 你不是在写本书，文档并不是文学作品，没有人会为它评分，不用尝试解释一切，保持简洁明了，很多时候，点几个重点就可以了。
• 在编码前写文档，定义产品的接口，描述它如何使用，它会如同一个规范指导你进行编码。
• 在编码后写文档，按照使用者的视角去思考什么是重要的，如何去使用它或者如何做贡献；编码过程中接口定义可能会发生变化，在编码完成后确保它的正确性是非常重要的。
• 编码过程中写文档，这块通常是指为代码编写文档，此类文章很多，本文不做展开。
• 从单元维度编写文档，上述原则均适用此，一个单元可能是一个函数，一个类，一个新功能，一个变更，一个模块或者一个完整的项目。如果描述一项工作十分困难，尝试将它拆解为更细粒度的单元来描述（或者提升到更高的层次上）。

沟通

沟通主要适用于与小团队或客户合作。

为什么要遵循它？因为透明制产生责任制，当你必须要向某人报告时，它会帮助你保持专注，这就是许多公司开站会的原因之一。

另外一个原因是，团队中成员遇到的问题往往可以通过与客户或其他团队沟通来解决，我已经记不清楚我抱怨过多少次我的变更没有在线上生效了，直到另外一个团队的同事告诉我，他的变更可能会和我的冲突，从而导致失效。

你可以这么做：

• 当你遇到未知障碍时，让你的团队和客户知道。
• 为你的客户定时更新项目进度，尝试让这些更新不要过于技术化。
• 让你的团队知晓变更计划时间。
• 消除沟通的障碍，确保每个人都可以很容易知道别人在做什么，挑选适合你们的沟通工具。

本质上，确保及时反馈，这会消除大部分合作者之间的分歧。

监控

所有的事情都可能会发生错误，部署出错，编码错误，异常抛出。准备好监控方案非常重要，它可以帮助你更好地掌控这些错误。监控也是反馈的重要部分，它避免你构建一个象牙塔，而不知晓你的产品的真实运行情况。

你可以这么做：

• 捕获日志，必要时不要不好意思编写 console.log() ，记录更多的信息总比记录少的好，但是务必记住，不要记录不必要的细节污染日志，以便更容易的筛选日志。

• 知晓日志存在哪里，并且配置一个方便查阅的系统。最基础的查看日志的方法是通过 SSH 工具访问你的服务器，并且调用 tail 命令查看你的日志，或者传送你的日志到日志采集系统里。无论哪种方法，重要的是当你编写了日志后，你清楚去哪里查看它。

• 不要忽略错误。虽然你的应用应该具有弹性（在发生错误时自动恢复），但是依然要在发生异常时记录错误日志。举一个例子，如果你正在调用一个 API 来获取用户的信息，并且你已经准备好处理 404 异常，同时也应该记录来自该 API 的其它错误，有一次我遇到这种场景时，并没有去记录错误，从而导致我无法感知到调用失败的具体原因——因为接口调用超过限制导致我的应用被加入到 API 的黑名单里。

• 检查你捕获的日志，这可以通过人工或者自动的方法来完成，曾经我遇到我发布了一个简单的修复，但是后来我才意识到它并未按照预期运行。从那时起，我通过在发布后监控应用日志的方式，来确保程序运行符合预期。

监控方案可以有很多种形式，可以是简单的控制台 log ，也可以以文件形式存在于第三方服务商（例如 Sentry， Bugsnag 和 Elastic APM ），挑选一种适合你的，然后使用它。

观察和迭代

这是一个最佳实践，并且也是其他实践的落地指南。没有一个适合所有人的公式。人们习惯不同的工作流，监控策略，文档风格，这便是为什么要持续观察和迭代的原因。

观察主要指批判性地观察用户的行为和表现。通过观察，你可以将所闻所知结合起来，推断出一些结论。当独自研发时，你通常无法受益于高级的用例研究或者 A/B Test ，所以你可以采取一些非正式的方法，例如用户评论，issue 报告和日志。观察之后便开始迭代，迭代是根据你观察的结果来改进你的产品，随后再次进行观察。在观察之后，下一件事情是得出结论，然后实现它们，但是这绝不是终点。

举一个例子，我的一个 APP 包含了一个项目列表，并且按照 UTC 格式显示了它们的创建时间，然而这对许多用户来说，显示的时间是错误的，这给他们带来了许多困扰。我决定通过在时间展示后面增加 UTC 字符来修复这个问题，效果还不错，但是这时我意识到，为什么不能根据用户自己的时区来展示时间呢？据此我调整了时间展示策略，并将它们调整为用户所在区域的时间，效果更好了。在与部分用户交流后，我了解到对他们来说，最重要的不是展示精确的时间，而是告诉他们这一项存在多长时间了，于是后来我调整时间展示为相对时间，例如“5分钟前”，“2小时前”，虽然没那么精确了，但是对用户来说更加易用了。

这也适用于你的内部流程，没有什么方法是一成不变的，当您选择实践方案时，重要的是观察其是否有效，并且在其基础上迭代，持续做出变化直到你找到适合你的方案。

总结

理想情况下，在结构化的产品研发环境里，从产品所有者到开发人员，有许多不同专业的人扮演着重要角色。当独立进行研发时，重要的是我们自身要尽可能填充这些角色，因此你可以按照你自己的意愿来做这些事情，最佳情况下，你可以利用这种自由来创建让你效率更高的结构，这会花费一些时间和精力，但绝对物超所值。