15 年前我给自己的一系列编程建议
我终于感觉自己是一个像样的程序员了，所以我觉得写一些建议会很有趣，比如“什么能让我更快地达到这一点？”我并不是说这对每个人来说都是很好的建议，只是对我来说这是个好建议。 我无法告诉你我在一个团队中待过多少次，并且系统存在一些很容易搞砸的事情，但没有人想过如何让犯这种错误变得更加困难。 当我进行 iOS 开发时，我们使用 CoreData，并在一系列视图中订阅存储中的更改。订阅回调来自触发更改的同一线程。所以有时那是主线程，有时是后台线程。重要的是，在 iOS 开发中，您只能在主线程上进行 UI 更新。因此，新的更改处理程序可能工作正常，但当有人从后台线程触发更改时，或者如果您稍后添加 UI 更新，它就会中断。 这是人们坦然接受的事情，而且经常在团队新人评审中出现。然后偶尔会漏掉，我们会添加一个 DispatchQueue.main.async 当我们看到事故报告时。 我决定修复它，并花了十分钟更新我们的订阅层以在主线程上调用订阅者，这消除了一整类崩溃并减轻了精神负担。 我并不是想说“看看这些白痴，他们没有修复代码库中一个明显的问题，这对我来说很明显”，因为任何人只要花几分钟思考一下，就会发现这个问题很明显。这些问题会持续很长时间，因为没有合适的时间来解决它们。当你刚加入团队时，你不会试图改变任何大的事情，所以你可能会觉得这很奇怪，但你不应该去改变一堆你还在学习的东西。然后当你在团队里待了一段时间后，这些问题就会逐渐淡出人们的视线。 这是一种心态的转变。当这些事情发生时，你只需要偶尔提醒自己，你有能力让你和你的团队的生活更轻松。 评估你在质量和速度之间做出的权衡，确保它适合你的环境 实施速度和对正确性的信心之间总是存在着权衡。所以你应该问问自己：在当前环境下发布错误是否合适？如果这个问题的答案不会影响你的工作方式，那么你就太不灵活了。 在我的第一份工作中，我从事的是数据处理方面的绿地项目，该项目拥有良好的系统来追溯重新处理数据。发布错误的影响非常小。对这种环境的正确反应是稍微依赖护栏，尽可能加快速度。你不需要 100% 的测试覆盖率或广泛的 QA 流程，这会减慢开发速度。 在我的第二家公司，我开发了一款数千万人使用的产品，其中涉及大量高价值的财务数据和个人身份信息。即使是一个小错误也需要事后分析。我以蜗牛般的速度发布功能，但我认为那一年我可能没有发布任何错误。 通常情况下，你不会在第二家公司工作。不过，我见过很多开发人员在这种编程方面犯了错误。在错误不是任务关键的情况下（例如 99% 的网络应用程序），快速交付和快速修复错误比花时间确保在第一次尝试时交付原始功能更能让你走得更远。 花时间磨斧头几乎总是值得的 你将要重命名事物、进行类型定义、查找引用等 很多；你应该能很快地做到这一点。你应该知道编辑器中的所有主要快捷键。你应该是一个自信而快速的打字员。你应该很了解你的操作系统。你应该精通 shell。你应该知道如何有效地使用浏览器开发工具。 我已经知道人们会在评论中这样说：“你不能花一整天时间调整你的 neovim 配置，有时你也需要砍掉大树”。不过，我认为我从未见过有人真的做得过分；我在新工程师身上看到的最大绿旗之一是在选择和熟练使用他们的工具时要小心谨慎。 如果你不能轻易解释为什么某件事很难，那么这就是偶然的复杂性，可能值得解决 我职业生涯中最喜欢的经理习惯于在我说某件事难以实现时向我施压。通常他的回答是“这难道不是在我们 Y 时发送 X 的问题吗”，或者“这难道不是就像我们几个月前做的 Z 一样吗？”我想说的是，这是非常高层次的反对意见，而不是我们正在处理的实际函数和类的层次，我试图解释这一点。 我认为传统观点认为，管理者简化这类事情很烦人。但当他逼迫我时，我意识到，我所解释的大多数复杂性都是偶然的复杂性，而这种偶然的复杂性往往是可以解决的。这不仅会使当前的问题变得微不足道，还会使未来的变革变得更容易。 尝试更深一层地解决错误 想象一下。仪表板中有一个 React 组件，它处理 User 从当前登录用户的状态中检索对象。您会在 Sentry 中看到一个错误报告，其中 user 曾是 […]