【外评】36 个提高开发人员工作效率的技巧

我是一个技术一般的开发人员。不多也不少。我之所以知道这一点，是因为在过去的 20 年里，我与许多杰出的开发人员共事过，见识过优秀开发人员的模样。我不是那样的人。尽管我没有什么特殊才能，大学计算机科学成绩单也令人怀疑，但在过去一年里，我发现自己比我职业生涯中合作过的大多数团队都更有生产力。当然，这主要是因为我没有大型组织的繁文缛节来摧残我的灵魂，但我怀疑这还不止于此。我决定反思一下，以防我以后进入工作效率低下的时期，到那时，我至少会有这份清单来提醒自己哪些方法是有效的。

这些方法没有特定的顺序，编号只是附带的。它们可能对你无效。但对我有用。

我做正确的事无需征得同意，决策速度很快。我将决策分为可逆决策和不可逆转决策–大多数决策都是可逆的，而且逆转决策的成本并不高。一般来说，将所有决定推迟到最近负责任的时刻。
我不需要通过几个中间人就能得到基本问题的答案–任何问题的答案通常只需要一次对话。如果不知何故变成了两次对话，我会努力将其缩减为一次，因为我不喜欢 “盖茨”。
肯特-贝克（Kent Beck）说过一句话：”先修改容易，后容易修改”（Make the change easy, then make the easy change），我对此深以为然。我把它理解为 “进行重构，让改变变得简单”。它能让代码更简洁，避免大规模重构。
我做过很多不同的尝试，我很清楚我写的一些代码永远不会投入生产，但我知道这些经历会带来更高质量的结果。
我不会花时间琢磨视觉设计决策。我偶尔会把我的软件给专业设计师看，让他们点评。
我对所有东西都有管理权限，从来不需要等待别人授予我使用某些工具的权限。
我通过直接与客户而不是自称代表客户的人交谈来验证我的假设。
我可以在多个堆栈中编程，不需要等待别人完成 “自己的部分”，就能实现功能。
我是在与人交谈后自己写下要求，而不是在问题中交给我。因此，流程是 “人→我的头脑→纸”。而不是人→纸→我的头脑。我发现让这些要求在你的身体里 “旅行 “会有帮助。
我不使用 Jira，而是使用 GitHub 问题，这样可以让所有问题更贴近我的代码。我不花时间写用户故事，我只写下足够让我开始思考问题的内容–这通常需要 1-2 分钟。
我将生产日志（和 Sentry）视为积压问题的主要输入，这有助于稳步提高系统的稳定性。我发现自己花在生产问题上的时间越来越少，从而可以腾出时间来做更有价值的工作。
我不会事无巨细地编写测试，尤其是那些由框架承担重任的工作。我认为框架已经经过了很好的测试。
我实践测试驱动开发，以帮助我思考一个好的应用程序接口应该是什么样的。
我与每个需要集成我代码的团队都保持着健康的关系，尽管我们有时会在某些事情上产生分歧。与人保持良好的关系可以减少焦虑和对提问的恐惧。
我尽量写得简洁明了，让对方容易理解我的观点。SCQA 和金字塔原则对我帮助很大，尤其是我发现自己越来越多地使用 Slack 和 Discord 等工具进行交流。
我不会随意承诺日期，给自己施加压力。当有人要求一个日期时，我会问他们拖延的代价是什么。他们从来没有好的答案。
当我在两个选择之间犹豫不决时，我会选择其中一个，即使后来不得不改变主意，我也不会自责。我发现优柔寡断的代价往往高于错误决定的代价。
当我遇到困难时，我会和我的妻子大声讨论（感谢她的倾听，萨娜）。
我不会把自己局限在工程框框里，我会做需要做的事情（我别无选择）。我可能做得很烂，但我会努力确认自己是否做得很烂。我通常都能胜任，虽然从未出类拔萃。
我把新学到的知识应用到旧的解决方案中，也就是说，即使工作已经 “完成”，我也会不断迭代，因为根本就没有 “完成 “这回事。就像一个作家，我对自己写的旧代码很挑剔，所以即使功能已经完成并稳定了，我还是会回头更新一些东西。
我很少使用分支（一些重大升级是罕见的例外），每当我最终使用分支时，我通常都会后悔。
我认为任何改进都不会太小。提取方法 “重构。为变量取一个更好的名字。将文件移动到更合理的位置。我痴迷于做这些事情，而这些事情的价值很快就会增加。
我实现了数据库迁移的自动化，而且没有看门人管理数据存储。我爱 Ecto，再也无法想象协调数据库变更的情景了。
我避免使用端到端测试（如 Cypress、Playwright），因为它们不值得花费维护成本，也不能为我提供关于软件是否正常运行的任何有价值的反馈。
我没有测试环境。我曾想过建立一个测试环境，但仅仅为了保持同步就浪费了我很多时间。我更喜欢通过创建测试账户在生产环境中进行测试。性能和渗透测试可能会有问题，但我更愿意在本地进行测试。
我使用spoofing技术来诊断和重现大多数客户问题。
得益于一些优秀的工具，我的可观察性达到了很高的水平–感谢 Posthog 和 Better Stack.。
我随时关注我正在使用的主要库（如 NextJS）的频道（如 Discord），尤其是 #help 频道，因为人们总是会问一些适用于我的问题。我发现大多数人都希望得到帮助，问题说得好，就等于解决了一半。
我认为 “面向未来 “就是创造可改变的设计，而不是创造复杂的设计。这与 “YAGNI “密切相关，只不过在决定不需要之前，我会先评估未来可能发生的变化所带来的成本。这并不总是那么容易，但这种思想实验是值得的。
我使用 MermaidJS 和 Notion 创建架构图（主要是序列图），帮助我思考和记录事情，这样我就能知道为什么在特定时间做出了特定的决定。
我使用 Git 友好型 API 客户端 (Bruno)，它允许我检查我的 API 测试调用，这样我就能记住我在第一次编写 API 时是如何让它工作的。
我使用 Prettier，这样我的所有代码在所有版本库中看起来都是一致的。使用 Elixir 时，我喜欢混合格式。两者都可以配置为预提交钩子。
当我遇到困难时，我会离开。这听起来很老套，但离开会让你对事情有全新的认识。因为我经常独自工作，所以离开是我的第二意见。
我尝试遵循肯特-贝克（Kent Beck）的四条设计规则，尤其是 “揭示意图”。我尝试从 getCheckoutFields(userId) 改为 getActiveCheckoutFieldsForAccountByUserId(userId)。这样做并不费力，而且当我稍后回来查看这段代码时，还能节省时间。
我每周至少会参考一次敏捷原则–它们是永恒的，是接地气的。敏捷工业综合体可能已经败坏了敏捷，但敏捷仍在继续。
人工智能很有用–我一直在用它来改进代码，并且正在试用亚马逊的 CodeWhisperer。到目前为止，它是一个净积极因素，我认为它只会变得更好。