大多数开发人员都是团队的一员。然而，在我们职业生涯的某些阶段，我们必须（或者我们必须）独自工作。虽然大部分产品开发涉及能够管理或与团队的其他成员合作，但在单独工作时开发良好实践同样重要。、
Solo通常意味着单独做某事。
包括：
- 一个开源项目，例如包或库
- 个人产品，可以是商业或免费的
- 为客户提供的自由服务
这里的共同点是，没有像公司通常那样的既定规则。
团队工程问题
您是团队的资产。让我们考虑一下您加入团队时可能出现的情况：
- 您加入了一个遵循您习惯的实践的团队。这意味着你将准备好从第一天开始做贡献。
- 您加入了一个遵循不同实践的团队。如果你已经掌握了良好工程实践的一般概念，那么你不应该花太多时间去习惯它，而且你很快就会变得富有成效。
- 你加入了一个不遵循任何良好做法的团队（哦不！）。在这种情况下，根据团队的不同，您可能会将您的知识用于承担并改进其流程。否则......也许只是离开。
无论哪种方式，这都是双赢的。
软件工程不仅仅是编码。将产品从概念发布到正式发布，然后使其保持运行，涉及到许多活动部分。遵循最佳实践将帮助您保持正确并避免挫败感。
如果你喜欢编码（像我一样），那么在处理新事物并开始编码时总会有诱惑。但是我已经看到，随着时间的推移，有一些结构，同时仍然保持独立工作带来的灵活性，帮助我避免在路上的许多颠簸。
让我们考虑一下这些好的做法实践。
坚持工作流程
工作流程是将头脑中的想法转化为成品所涉及的一系列步骤。您的工作流程应涵盖的一些内容包括：
- 当确定更改时，我将遵循哪些流程来实施它？
- 如何向最终用户提供此产品的新版本？
- 如何跟踪对此产品所做的更改？
- 如何跟踪此产品的错误，问题和未来计划？
在没有定义的工作流程的情况下完成任务似乎更快（，但随着项目复杂性的增加，您会发现有明确的定义可以更容易地确定需要完成的工作并专注于它。在团队工作时，工作流成为一个管道，可以帮助每个成员提高工作效率。
实现流程：
- 使用issues （GitHub，Gitlab，BitBucket或托管代码的任何地方）。问题可帮助您跟踪错误，功能请求和项目的主要更改。此外，写出问题标题和描述会迫使您明确思路，并确切地定义问题是什么以及解决方案应该涉及什么。您还可以通过添加Trello和GitHub Projects等项目管理工具来更进一步。
- 使用pull拉取请求。许多开发人员更喜欢在独自工作时直接push。但是，通过拉取请求进行更改会带来好处。更容易看到该功能或错误修复中涉及的所有更改以及它们在合并时如何影响代码库。此外，当pull请求与问题配对时，可以更轻松地观察项目的演变过程，而无需阅读代码并弄清楚。
- 检查您的代码。这可能听起来很奇怪，但您应该检查您的代码，就像它是由不同的人编写的。有些人建议制作PR并离开几分钟或几小时，然后在合并或更新之前回来查看代码。代码审查，远离您的王者IDE，允许您（有点）新鲜的眼睛看到您的代码，帮助您捕获错误并识别您忘记的事情。代码审查也会迫使您质疑自己。为什么我这样实现呢？怎么可能出错？有没有更好的办法？
- 保持有意义的Git历史。尝试像你在团队中一样提交 - 避免大型提交，保持专注，有意义的提交消息。与代码审查一样，编写描述性提交消息会迫使您放慢速度。我在这次提交中想要实现的目标是什么？我是如何尝试实现这一目标的？
在某些情况下，您可以允许自己违反规则。例如，您可能会认为对于非常小的修正（例如纠正错字），可以直接推送到master，以避免减慢速度。
无论您将哪些内容纳入工作流程，都是有意识的关键。成功的产品不仅仅会发生; 他们建立在爱与关怀之上。故意意味着退后一步，看看你面临的痛点，并思考改善它们的方法和工具。
撰写可重用的组件和模块
根据DRY，SOLID和FIRST原则思考。使用较小的封装原子可重用组件构建软件。使用像Bit这样的工具来创建您喜欢的构建块的集合并保持更新。您最终会更快地构建更好的软件。
写文档
很多人都知道，很少有人这样做，更少的人喜欢它。在编写令人兴奋的代码之后，记录代码通常很困难。如何在散文中捕获我的代码的所有复杂性？
人类容易范错误的。我们会忘记事情，我们会生病，或者我们会继续从项目中继续前进。文档确保知识不会被人类束缚。文档还可以帮助开发人员全面了解并保持专注。
- 意识到你不是在写书。文档不一定是文学杰作。没有人给你评分。不要试图解释一切。保持简洁明了。有时您需要几个子弹点。
- 编码前的文档。记录产品的界面 - 它如何从外部起作用。这是一个规范，将在建设时指导您。
- 编码后的文档。再说一遍，就像你是一个局外人一样写。重要的是什么？你需要知道什么来使用它（或有助于它）？规范可能会在构建时发生变化，因此检查编码前编写的任何文档在完成后仍然是正确的，这一点很重要。
- 文档同时编码。这主要适用于在代码中编写文档。关于记录代码的文章很多，所以我不会详细介绍。
- 以unit工作。以上所有原则均适用于unit。例如，单元可以是功能，类，新功能，行为变化，模块或整个产品。如果记录一项工作似乎非常困难，请尝试将其分解为更小的单元（或者，上升到单元的层次结构）。
沟通
沟通主要适用于与小团队或客户合作。
透明度导致问责制。当你知道你必须向某人（无论是你的同事还是你的老板）报告你的工作时，它会帮助你保持专注。这是许多公司举行立场会议的原因之一。
另一个原因是，团队中的一个成员经常遇到一个问题，可以通过与客户或其他团队成员进行沟通来轻松解决。
- 当您遇到无法预料的障碍时，让您的团队和客户知道。
- 为您的客户定期更新项目进度。尽管如此，尽量不要让这些更新变得太技术化。
- 让您的团队知道计划何时发生变化。
- 消除沟通的障碍，这样每个人都可以轻松找出任何人在做什么。查找并使用最适合您的工具 - WhatsApp，电子邮件，Slack等。
基本上，保持反馈循环。它消除了所有相关方之间的大量摩擦。
监控
事情会出错。部署将失败，将出现错误，异常将被抛出，事情将破裂。为监控提供条款非常重要，这样您就可以更好地应对这些故障。监控是反馈回路的另一部分; 它会阻止你在象牙城堡中建造，而不知道你的产品实际上是如何表现的。
- 捕获日志和指标。不要console.log()在必要时感到羞耻。记录太多信息比记录太少更好。但是，请务必避免使用不必要的细节污染日志，以便更轻松地筛选日志。
- 了解日志的位置并设置系统以轻松查看它们。这可能是基本的SSH，如通过SSH连接到服务器以拖尾日志文件，或者像将日志发送到ELK堆栈一样先进。但重要的是，当您编写console.log()（或用于记录的任何方法）时，您知道在哪里查找这些日志。
- 不要吞下错误。虽然您的应用程序应该具有弹性（能够在发生错误时恢复），但最好记录您不期望的错误。例如，如果您正在调用API来获取用户创建的内容（例如推文），那么您应该已准备好处理404 Not Found响应的案例。但是应该记录来自API的不同的意外错误。我一直处于这种情况，因为我没有记录这些错误，我不知道我超出了我的速率限制，导致我的应用程序被列入黑名单访问API。
- 检查您捕获的日志和指标。这可以手动或通过自动方式。我一直处在这样的情况下，我已经实现了一个“简单”修复并部署它并继续我的快乐方式，只为我后来才意识到它无法正常工作。从那时起，我在部署之后采取了监视应用程序日志一段时间的做法，以验证事情是否按预期工作。
监控策略可以采用不同的形式，从简单的控制台日志和文本文件到Sentry，Bugsnag和Elastic APM等外部提供程序。选择一个适合你的堆栈，然后继续。
观察并迭代
这是最佳实践，也是所有其他方面的指南。没有一个适合所有人的通用公式。人们将习惯不同的工作流程，监控策略，文档样式等。这就是为什么始终观察和迭代很重要的原因。
在单独工作时，您通常无法获得高级案例研究和A / B测试的好处，因此您可以从“非正式”来源（例如人们的评论，问题报告和日志）中获取线索。
观察后迭代。迭代是关于根据观察结果对产品进行改进，然后再次观察，等等。在做出观察之后，接下来要做出结论，然后实施它们。但它并没有就此结束。
结论
理想情况下，在结构化产品开发环境中，从产品所有者到开发人员，有许多不同的专业角色扮演重要角色。独自工作时，重要的是要意识到你正在填补这些角色中的许多（可能是全部）角色，因此你可以自由地按照自己的意愿行事。最好利用这种自由来创建一种能够提高工作效率的结构。这可能需要一点额外的时间和精力，但我向你保证这是值得的！