独立程序员如何建立短反馈循环

关于反馈回路

建立纪律

明确具体的顶层目标

确定中级和低级目标的优先级并进行规划

自动化您的工作

预留代码审查时间

留出时间进行流程审查

利用评审结果更新你的目标和流程

过去几年，我一直是一名自由职业开发者。将这段经历与之前在公司工作的经历进行比较，我发现，独自工作的人比团队合作的开发者拥有更少的迭代改进机会。获得改进机会的关键在于“短反馈循环”的概念：这是一个在短时间内不断从观察和以往经验中汲取新知识的过程。这个过程必须由主要独立工作的人来构建，而不是像通常的情况那样，加入团队后才采用。

在这篇文章中，我希望分享我所学到的关于如何作为一名独立程序员快速、持续地提高自己的知识。

关于反馈回路

美国空军上校约翰·博伊德提出了OODA循环的概念，OODA是“观察（observe）、调整（orient）、决定（decision）、行动（act）”的缩写。在军事行动中，OODA描述了一种基于不断获取新信息的决策过程：

观察：获取关于正在发生的情况和当前环境的原始信息。

调整：将原始观察结果与背景联系起来。考虑与当前情况以及先前获得的知识和经验的关联性。

决定：制定实现目标的计划。

行动：执行计划。

由于它是一个循环，行动阶段会直接回到观察阶段。这是至关重要的“反馈”概念，它能够使迭代越来越成功。它广泛应用于军事行动之外——你可能已经意识到它是PDCA（计划-执行-检查-行动）方法的起源。

我喜欢 OODA 循环，因为它简洁地阐述了通用的反馈循环。许多概念和工作方法都建立在反馈循环的理念之上，包括DevOps和敏捷软件开发方法。

开发团队反馈循环

让我们看一下团队​​开发人员的反馈循环的一些组成部分可能是什么样子的：

1. 产品所有者的指导或用户的评论
2. 整个团队的每日站会/站立会议
3. 与开发团队确定优先级
4. 个人编码和测试
5. 同行代码评审
6. 部署和性能监控

这些步骤中隐含着同事和管理层的支持——换句话说，就是有人负责。一个独立的自由开发者如何才能创造类似的问责环境呢？

单独开发人员反馈循环

以下是个人自由开发人员可以实施的一些可能的步骤，以创建简短的反馈循环：

1. 建立纪律
2. 明确具体的顶层目标
3. 确定中级和低级目标的优先级并进行规划
4. 自动化您的工作
5. 预留代码审查时间
6. 留出时间进行流程审查
7. 利用评审结果更新你的目标和流程

下面我将详细介绍每个阶段。

建立纪律

自律本身与其说是一个阶段，不如说是一个先决条件。它能让我们短反馈循环发挥作用。除非我们有能力去做自己不想做的事情，否则本文中的其他内容都毫无用处。自律无疑是一项技能。它就像其他技能一样，可以学习、训练和提升。

为什么纪律如此重要？因为当我们周五晚上加班加点地完成一个项目时，我们不会想写一个好的提交信息。我们也不会想清理代码注释。我们只想看到代码运行起来，就像“你好，git push -f”一样。正是在这样的时刻，纪律让我们不错过练习、学习和改进工作流程的机会。纪律帮助我们避免周五晚上的提交变成周一早上的“大杂烩git reset --hard”。

明确具体的顶层目标

无论是为客户工作还是引导我们自己有史以来最好的新应用程序，如果没有衡量标准，我们就无法衡量任何进展或改进。

当我与客户讨论新项目时，我总是会谈到具体的成果。这可以是在某个日期前完成某个特定功能，或者决定 MVP 在用户眼中是什么样子。这对我和我的客户都有好处。通过书面约定实现的目标和时间，我和我的客户就明确了顶层目标，并且双方都能评估项目的进展情况。当我为自己工作时，我会像对待客户一样对待自己。我会以书面形式做出承诺，描述将要实现的目标以及时间。这可以简单到只是一份本周目标清单，也可以详细到像看板一样。

然而，设定具体目标的意义并非在于不惜一切代价地坚持下去。重要的是，我们要为自己和客户设定一个期望，即在项目过程中，双方会在双方同意的日期重新审视这些目标。这为循环中至关重要的“反馈”环节提供了可能。

确定中级和低级目标的优先级并进行规划

很少有目标能够一步到位。即使是制作花生酱果冻三明治（一个广受欢迎的计算机编程教学示例）这样简单的过程，也可以分解成更小、更精确的指令。虽然我们人类可能不需要计算机程序那样的粒度，但那些被分解成时间限制内、可实现的步骤的目标更容易被理解。🥪

从中级目标开始，逐步具体化每个步骤。例如，如果目标是发布一个新的开源 Web 应用，步骤可能如下：

1. 完成应用程序 JavaScript
2. 创建前端和样式表
3. 进行本地测试
4. 设置云服务器
5. 将应用部署到云端
6. 做测试
7. 将存储库添加到 GitHub
8. 在 Hacker News 上发表文章
9. 利润！！！

上述每个示例都包含许多较小的、低级的目标——我们可以将它们视为待办事项列表项。例如​​，“设置云服务器”可能涉及：

1. 研究云提供商
2. 决定服务并注册
3. 设置服务器/实例
4. 添加集成
5. 测试部署

我们对于块大小和“步骤”构成的参数可能各不相同，并且可能因项目而异。如果你的中层和底层步骤清晰地定义了实现你设定的顶层目标的具体路径，那么你的工作就进展顺利了。之后，评估促成这些中层和底层目标的决策过程，可以帮助我们完善反馈循环。

自动化您的工作

我最近读了一篇很棒的文章，题为《手动工作是个 Bug》。它探讨了成功的开发人员如何记录并最终实现工作自动化的过程。这个想法的美妙之处在于它的简洁性。通过记录我们手动完成的工作，我们能够纠正和改进流程。通过改进流程，我们可以更轻松地将其转化为代码片段和脚本。通过将这些脚本串联起来，我们就能实现工作自动化。

工作自动化不仅仅是为了节省时间。它减少了“还没喝咖啡”的错误，最大限度地减轻了认知负荷，从而提供了更多的创造力空间，并使我们的流程能够在不同的合作伙伴和项目之间重复。它有助于缩短我们的反馈循环，确保我们不会以三种不同的方式重复做同样的事情。

我们可以通过创建自己的个人维基百科来开启自动化之旅。如果我们养成记录每一项手动操作的习惯，无论这些操作当时看起来多么基础，我们就能给自己更多机会发现规律，从而进行整合和改进。

第一次手动操作时，我们会把步骤写下来。第二次则按照步骤操作。这让我们有机会根据第一次的经验教训进行修改和改进。在不断的迭代中，我们可能会用变量替换部分手动命令；我们可能会找到一些方便的 Bash 脚本片段，用于自动完成部分任务。只要我们不断修改和改进我们的个人 wiki，我们就在朝着自动化迈进。

预留代码审查时间

独自工作时，我们很容易犯下混乱的代码。我们会想，谁会看到？我稍后再修复。然而，每次发生这种情况，我们都会养成一个习惯。这是一个坏习惯。

独自工作意味着，当我们做的事情不合理或有待改进时，没有人可能对我们的提交提供反馈。相反，我们必须积极寻找改进的机会。开源社区在这方面非常出色。我们可以获得丰富的信息，包括编码风格、重构代码示例，以及各种各样的代码片段，这些代码片段可以用更少的代码实现我们想要做的事情。只要我们抽出时间去做，我们就能学到所有我们想学的东西。

安排您自己的代码审查，时间安排要适合您和您正在进行的项目。这可以是每次完成修复或功能时，也可以是每天或每周定期进行。如果您有可以提供帮助的人，请预约。此外，聊天室里也有很多乐于助人的人。

研究一下你正在做的工作的基本最佳实践。不过，要给自己设定一个时间限制，并且对你所读到的内容持保留态度。这个领域有很多难以捉摸的陷阱。作为起点，我建议学习“DRY 代码”，并观察Bob 大叔对软件开发专业性的要求。

代码审查清单

这是我的个人代码审查清单，基于一些通用的最佳实践。欢迎将其作为你自己的起点！

维多利亚的代码审查盛会！

[ ] 这解决了一个高优先级的问题。

[ ] 这是一个遵循规范的完整实现。

[ ] 未包含偏离主题的更改，这些更改已添加到待办事项中。

[ ] 变量名有意义，并且没有魔法数字。

[ ] 每次都返回正确且有用的错误消息。

[ ] 没有留下任何调试打印语句。

[ ] 此代码是 DRY 且模块化的。

[ ] 此代码是安全的。私有代码和公共代码已很好地分离。

[ ] 此代码是其自己的文档，或者文档是最新的。

[ ] 一个五岁的孩子可以理解这一点，说真的，它的可读性就是这么强。

[ ] 单元测试成功通过。

[ ] Master 已合并到分支并经过测试。 [

] 格式遵循样式指南。

[ ] 我找不到任何其他边缘情况或已知缺陷。

[ ] 如果此代码公开归功于我，我会很高兴。

[ ] 我完全理解代码的作用以及我所做更改的影响。

[ ] 我确实验证了它确实做到了我所说的。

这是一个在考虑上述几点的情况下清理代码的极好例子。

留出时间进行流程审查

正如我们从代码审查中学习一样，我们也通过审查来完善流程。在整个项目过程中定期进行流程审查最为有益，而不仅仅是在项目完成后进行。对于短期项目，安排流程审查的一个良好起点是在每个项目进行到一半时进行——中途一次，完成后再次进行。长期项目可以在每个项目进行到四分之一时进行一次审查。

流程审查问题

流程审查可以简单到只需列出一个简短的问题：

1. 这段时间我的最高目标是什么？我实现了吗？
2. 这段时间我的中级目标和低级目标是什么？我实现了吗？
3. 如果我的人生目标有所不同，或者更加具体，会不会对我更有帮助？为什么？
4. 我是否成功消除或自动化了障碍？
5. 我有没有遵守我的代码审查计划？为什么？
6. 下次我该如何消除障碍？

专门留出时间进行流程回顾，可以帮助我们认真、诚实地回答这些问题。这让我们能够从回顾中汲取尽可能多的经验，从而缩短反馈周期。

利用评审结果更新你的目标和流程

如果我们不将世界上所有的性能数据付诸实践，它们对我们来说都毫无意义。随着每次代码审查的进行，我们可以完善并补充我们的清单。从每次流程审查中汲取的经验教训，我们可以调整和改进我们的流程。我们越能发明具体且可观察的方法来实践我们的学习成果，我们就越能取得成功。

有意识地运用和实践我们所学的知识，是反馈循环的最后一个关键环节。我们越频繁地吸收新知识，我们的反馈循环就越短，从而让我们能够更快地进步。