拥抱混乱的编程

您是否曾在会议中讨论过可能会或可能不会发生的问题？随着您向前迭代，解决方案必然会发生变化。也许您的团队正在兜圈子，假设可能影响问题定义的未来结果。听起来很熟悉？

讨论问题，而不是解决方案

首先，我们必须弄清楚一件事。做什么，怎么做，这是两件不同的事情。我完全赞成详细的、结构化的问题定义—— 准备好的定义 如果你喜欢 Scrum。然而，讨论后者，这确实让我非常担心。

让它燃烧吧，我说。

让它燃烧，看着它死去，然后让它复活。当您的团队从会议室回来，仍在讨论要做什么时，您已经有足够的时间来构建和测试您的临时想法。它可能会起作用。可能不会。运气好的话，你已经学到了一些东西，足以继续前进。

彻底的解决方案计划的问题在于结果必然会发生变化。也许生产数据库没有标准化，或者第三方 API 的速率限制比您以前想象的要低得多。无论如何，这些失误是必然会发生的。您无法对此进行计划，甚至可以通过详细的计划和改进来正确地完成其中一些，但不足以保证该过程。过度工程本质上是不好的，任何体面的程序员都会生病，就像过度思考在生活中是不好的，会导致不存在的问题。与过度思考者类似的是谨慎者。与选择沉思而不是行动的谨慎开发人员合作将使您处于不稳定的境地。我不太关心解决方案本身。据我所知，这可能很糟糕。然而，由于不作为而阻塞进程，这将限制吞吐量并留下一个陈旧的主分支。停止理论并开始做。

好吧，那么它是无政府状态吗？

不，没有深思熟虑的行为可以说与过度思考一样糟糕，也许更糟。问题出在过程中。成为一个混乱的程序员并不是要放弃你的义务并成为一个十足的牛仔。它是关于在允许快速迭代的过程中提供解决方案。不要说服我你的解决方案是合理的——告诉我。向我证明你的解决方案成立。这样做的方法是测试。确保您拥有可以验证您的意图的回归测试、集成测试和单元测试。创建一个拉取请求，对其进行审核，并在一小时内将其合并。或者，如果您是受让人，请将审查作为优先事项。审查别人的代码可能很糟糕，但下一次将由你来审查。请不要仅仅因为您决定代码审查可以等待而阻止流程，因为这就是您获得陈旧主分支的方式。

最后的话

培养允许失败的环境。对自己的错误负责。承担责任并解决自己的烂摊子。

尝试、失败、修复、学习——重复。谨慎和计划有它的时间，但快速迭代是值得努力的。那是混乱的编程。

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明

本文链接：https://www.qanswer.top/11054/28390209