该材料的作者（我们今天出版的译文）说，大多数程序员都是团队工作的。 但是，在职业生涯的某个时刻，开发人员可能需要独自工作。 软件产品工作组织方法的主要范围是专门为团队使用而设计的。 这些方法在组织采用的规则中表达。 这样的规则可以简化工作，帮助程序员快速高效地完成工作。 对于那些独自工作的程序员来说，类似的东西将非常有用。
那一个单独工作的人呢？ 着眼于什么，努力建立清晰有效的工作流程？ 要遵循哪些原则和规则？ 我们建议一起寻找这些问题的答案。
关于孤独的程序员
在这里，谈到“孤独的程序员”，我指的是在非正式，非结构化环境中工作的所有人员。 这可以是单个程序员，也可以是一小群人，例如在空闲时间从事某种项目。 以下是一些示例：
- 开发开源项目，例如程序包或某种库。
- 某人的个人项目，可以是商业的也可以是免费的。
- 自由职业者。
所有这些示例都因以下事实而结合在一起：从事类似工作的程序员的工作通常不受一组特定规则的约束，例如公司中通常存在的规则。
为什么一个程序员应该关心规则？
将这些规则应用于某些项目中的程序员的独立工作时，这些规则很重要，原因有几个。 考虑他们。
▍个人规则和可能的团队合作
一个独立工作井井有条的程序员可以很好地加入某个团队。 在这种情况下，他很有可能会成为这样一支球队的宝贵成员。 即，我们正在谈论以下内容：
- 如果他加入了一个遵循与他相同的规则的团队，那么他将不必浪费时间去研究组织问题。 从头一天开始，他将为生产工作做好准备。
- 如果他成为团队的一员，所采用的规则与他过去所习惯的规则有所不同，那么他就不会花很多时间来学习这些新规则。 毕竟，他习惯于合理地组织自己的工作，并遵循某些总体思想，这些思想肯定与构成团队规则的思想相似。 结果，他可以迅速达到较高的劳动生产率水平。
- 如果他加入了一个完全没有规则的团队，那么，当然，取决于团队，他可以向她提供他对程序员工作组织的构想，这很可能会改善这样一个团队的工作。 如果组织不良的团队成员拒绝更改某些内容，那么这是考虑离开这样一个团队的机会。
结果，无论如何，一个能够合理组织工作的孤独程序员才是赢家。
▍程序员的规则和专业水平
软件开发不仅仅是编写代码的过程。 有许多细节负责将一个想法变成一个完成的项目，然后将其保持在工作状态。 在个人工作流程中引入先进的软件开发技术将帮助单个程序员自信地遵循创建项目的目标，并避免出现一切令人困惑以至于不清楚继续前进的情况。
如果您像我一样喜欢编程，那么您总是会被诱惑去启动一个新项目，并且立即而无需回头，就冲入编写代码的深渊。 但是经验告诉我，如果我有一定的高级工作计划，那么在不损害个人开发不同的灵活性的情况下，它有助于避免很多不同规模的麻烦。
讨论软件开发的最佳实践。
请遵循描述您的工作流程的规则。
“工作流程”是将创意转换为最终产品过程中需要经历的一系列步骤。 以下是管理软件产品工作过程的规则应回答的一些问题：
- 当决定对产品进行更改时，其实施顺序是什么？
- 如何将新版本的产品转让给用户？
- 如何跟踪产品变更？
- 如何组织对错误消息和用户遇到的问题的监视？
- 计划新产品功能的过程是什么？
如果似乎在没有某些特定工作流程的情况下，项目的工作会快得多，为什么还要规范所有这些工作并将其驱动到某种框架中？ 以这种形式想象整个“工作流程”是否更容易：“只需编写代码并将其发送到master分支”？ 实际上，随着项目复杂性的提高，明确的规则的存在简化了该项目工作中需要完成的工作的定义，因此，无需进一步考虑，您就可以专注于这些事项。 在团队中工作时，工作流会变成传送带之类的东西，从而提高了团队中每个成员的效率。
现在，让我们谈谈如何组织软件产品的工作过程。
▍使用任务跟踪器
在这里，您将找到可用于放置代码的平台的机制-GitHub，Gitlab，BitBucket等。 任务有助于跟踪错误消息，向产品添加新功能的请求以及组织有关重要项目更改的信息。 应该注意的是，当您输入任务的标题和描述时，它将迫使您清楚地表达思想，清楚地描述问题和解决问题的可能方法。 可以通过将任务管理工具（例如Trello或GitHub Projects）引入您的工作流程来开发使用任务的想法。
挑战赛▍使用拉取请求
许多开发人员更喜欢使用推送请求将更改直接发送到其项目的主分支（称为主分支）。 但是，使用拉取请求更改项目代码的方法具有一些重要的优点。 首先，此类请求有助于分析有关在项目中引入某些新功能或错误修复的更改，以及它们与主要代码库合并后将如何影响更改。 此外，如果拉取请求与任务跟踪器中的任务相关联，则它们的使用将使您更容易理解项目的开发方式，从而无需在读取代码时就查找出来。
拉取请求详细信息▍执行自定义代码审查
审查本机代码的建议可能听起来很奇怪，但是尽管如此，开发人员仍应像分析其他人编写的那样分析自己的代码。 一些程序员建议提出一个拉取请求，分散一段时间，然后在将其包含在代码中之前对其进行检查。 以程序员的IDE的形式对程序员在通常环境之外执行的代码检查使您可以重新审视代码。 这有助于发现错误并在代码中检测正常情况下可以忽略的内容。 此外，代码审查迫使开发人员向自己提出各种问题：“为什么以这种方式来实现这个机会？ 在这里可能做错了什么？ 有没有更有效的方法来解决这个问题？”
in在存储库中保留有意义的项目历史记录
尝试像在团队中一样进行提交。 即-避免太大的提交，请尝试确保提交的消息清晰并清楚地描述其含义。 就像在代码审查的情况下一样，编写高质量的提交消息会迫使开发人员仔细考虑其行为，向自己提出如下问题：“我试图通过该提交实现什么？ 我要如何实现这一目标？”
在某些情况下，您可以允许自己偏离规则。 例如，您可以决定为了不因琐事而减慢工作速度，您可以在对代码进行非常小的更改（例如修正拼写错误）时，可以将推送请求直接发送到master分支，而无需进行不必要的移动。
无论您的工作流程有哪些规则，最重要的是您所做的一切都是有意地完成的，并非巧合。 成功的项目不是靠自己产生的：它们是在爱与关怀下创建的。 有意采取的行动涉及对情况的某些阶段的分析，对复杂案例的分析以及对例如如何使用哪些工具进行处理的反思。
构建可重用的组件和模块
贯彻
DRY ，
SOLID和
FIRST的原则。 从适合重用的小型封装原子组件构建程序。 使这些组件保持最新状态，并使用适当的平台（例如
Bit）将它们组装为集合。 所有这些将帮助您提高工作速度和质量。
撰写文件
文档...对于许多人来说，这是一个痛处。 许多人知道软件项目需要文档。 撰写出色文档的人已经越来越少，甚至喜欢这样做的人也更少了。 在完成下一个迷人的代码编写阶段后，记录文档的需求通常成为您只想忘记的任务。 如何以纯文本形式表达程序代码的所有复杂性？
而且，顺便提一问，为什么所有这些都是必要的。 事实是人们容易犯错误。 我们可以忘记一些事情。 我们日子不好过。 或者，在某个项目上工作，我们可以简单地继续进行其他工作。 文档使您可以捕获有关代码的知识，否则，这些知识将与某个人联系在一起。 编写代码文档还可以帮助开发人员以比编写代码时更通用的方式查看代码，并更清楚地了解项目的目标。
以下想法将帮助您编写良好的文档。
- 了解您的文档与书本不一样。 该文档不应构成高级文学艺术的范例。 没有人会根据她的艺术价值来评价她。 不要试图解释其中的所有内容。 力求清晰易懂。 有时仅用几句话就足以描述某些内容。
- 在编写代码之前先编写文档。 记录模块的接口，从外部观察者的角度描述模块的工作顺序。 这些文档将扮演产品规格的角色，并在开发过程中为您提供帮助。
- 编写代码后编写文档。 同样，在这里值得坚持“外部观察者”的立场。 在描述的代码片段中什么是重要的？ 您需要了解使用它（或为它的发展做出贡献吗？）。 在开发过程中编写代码之前创建的文档指定的规格可能会发生更改。 因此，重要的是在工作完成后检查此类文档是否符合实际情况。
- 在编写代码的过程中编写文档。 这种文档编制方法主要适用于在开发过程中添加到代码中的注释。 关于此主题的材料很多，因此在此不再赘述。
- 文档和“模块”。 以上所有原则均适用于模块。 在这里，“模块”的概念被广泛地使用。 这可以是函数，类，新机会，程序行为的变化，实际上是某个程序模块或整个项目的变化。 如果要记录这样的“模块”似乎太过困难了，请尝试将它们分解成较小的部分。 或者，如果您更容易考虑更一般的类别，请考虑为项目的较大部分编写文档。
与客户以及与您一起参与产品开发的人员进行沟通
在这里，我们所说的“交流”主要适用于由小团队开发或按订单生产项目的情况。
为什么需要这个？ 事实是，工作的透明性导致其表演者责任的增加。 当您知道必须告诉某人（团队成员或客户代表）某些事情时，它可以帮助您更加小心自己的工作。 这就是为什么许多公司练习召开短期会议，让员工报告其工作情况。
另外，团队中的成员经常面临他很难解决的问题，只需与客户或团队中的另一位成员讨论即可轻松解决。 我已经记不清了，回想起我真正放手的情况，试图理解为什么我写的东西行不通。 原因是团队的另一个成员对项目进行了更改，从而影响了我的代码。 为了理解这一点，将这个问题公开讨论就足够了。
这是与客户和程序员团队成员进行交流的一些准则。
- 如果遇到意外问题，请让团队成员或客户代表知道。
- 定期将项目进度通知客户。 同时，请尝试使此信息不会仅与技术问题联系在一起。
- 通知团队计划变更。
- 尝试组织一个方便的交流环境，例如，该环境允许团队中的任何成员快速了解其他人在做什么。 可以说，您可以使用各种工具来做到这一点-它可以是WhatsApp，电子邮件，Slack或其他任何适合您情况的工具。
总的来说，应该指出的是，您应该尝试确保所有相关方之间的交互都被方便且简单地组织起来，因此，可以说，“反馈循环”可以毫不延迟地进行。 这有助于组织一个健康而富有成效的工作环境。
组织监控系统
在软件开发领域进行监视是一个非常重要的问题。 计算机容易崩溃。 在项目部署期间，会发生错误。 开发人员的疏忽导致了这样一个事实，即似乎已经通过所有可能的检查并成功投入运行的程序会出现异常。 这就是为什么开发人员需要照顾程序监视系统的原因。 这将有助于解决在产品生命周期的不同阶段可能出现的问题。 程序监视数据是上述“反馈循环”的一部分。 监视使程序员能够与现实以及他的程序在其中工作的环境建立联系。
以下是一些有关监视程序行为的建议：
- 保存日志和自动代码分析结果。 随意在需要的地方使用console.log（），最好存放太多的信息，而不要存放太多的信息。 但是，请尝试找到“中间立场”，以使程序的日志中不包含有关其工作的不必要的详细信息。 这将使在日志中查找重要信息变得更加容易。
- 找出应用程序日志的去向，并配置使其易于使用的机制。 上述“机制”的作用可以是任何东西-从使用SSH登录到服务器并查看日志中记录的最新事件，到使用ELK堆栈。 最重要的是要知道console.log（）或任何其他方式在哪里生成应用程序日志。
- 不要忽略异常。 尽管任何开发人员都应努力确保其应用程序稳定，也就是说，在出现错误，“摆脱”意外异常，仅将其“锁定”在某些catch块中的情况下，他可以恢复工作能力。 记录有关意外异常的信息会更好。 例如，如果您使用某种API来加载用户创建的某些数据（例如推文），则应该准备处理错误404。但是，如果您没有处理这些错误，则需要进行记录。 我当时处在没有记录有关意外错误的信息的情况下，我根本不知道自己已经用尽了对一个系统的调用限制。 这导致关闭对我程序的相应API的访问的事实。
- 检查日志。 可以手动组织检查应用程序结果生成的日志，也可以使用某种方式对其进行自动分析。 一旦我不再特别关心日志控制，就解决了程序中的一个小问题并继续冷静地开展业务。 后来发现，我的矫正无效。 从那时起，我一直专注于在部署应用程序日志后检查它们，这使我可以检查其工作的正确性。
监视应用程序活动和跟踪性能指标可以采用多种形式。 以最简单的形式，它可以使用console.log（）命令输出有关程序的数据，将该信息保存在文本文件中，并手动分析这些文件。 监视也可以是一个相当高级的系统，其中包括Sentry，Bugsnag和Elastic APM等专用工具。 最主要的是选择适合自己的并持续使用。
观察项目，从观察结果中得出结论，并加以改进
您看，但不观察，这是一个很大的差异。
亚瑟·柯南·道尔（Arthur Conan Doyle），《波西米亚的丑闻》本节中讨论的内容既可以视为独立建议，也可以视为使用此处介绍的其他建议的方法。 事实是，组织软件产品上的工作没有统一的公式。 不同的人以不同的方式参与软件开发，使用不同的监视方法，以不同的方式编写文档代码等等。 这就是为什么无论您选择的程序的工作规则是什么，重要的是始终努力确保对项目进行监视，并从监视的结果中得出结论，并最终使所有这些导致程序改进。
监视程序涉及对其行为的严格分析，或者说例如其性能指标。 通过观察程序，您可以在所看到的与所了解的系统之间建立联系，最终得出关于正在发生的事情的逻辑结论。 一个人工作通常会被剥夺分析组织中使用的程序的能力（例如A / B测试或对目标受众的研究）。 结果，他不得不从“非正式”来源收集有关其程序寿命的线索，例如用户注释，任务跟踪器中的问题报告以及应用程序日志。
在完成下一阶段的监视程序之后，是时候得出结论并根据这些发现进行改进了。 然后进行下一阶段的观察，然后进行下一次迭代，对收集的数据进行分析，并对程序进行改进。 但是从事一个程序不仅仅是“观察-分析-改进”。
考虑一个条件示例。 , , . , UTC-. , .
, UTC. , , , 5:30 pm, 5:30 pm UTC. , . , . ? , . .
, , , — , . , , , . «5 » «2 ». , , , .
. , . , , , , , . , , .
总结
, , — , . ( ), , , . , , ( , ), , . , , . , , , , .
亲爱的读者们！ , «-»?
