别名——是时候停下来并发布了

前几天，我写了一篇关于足够好的代码的文章。

这个想法很简单。当代码达到足够好的水平时就停止编码。超过足够好的努力都是浪费的工作。

但是这仍然留下了一个重要的问题：如何定义“足够好”。

学会停下来

没有适用于每种情况的明确的“足够好”定义。

你需要根据你的环境和目标来调整对足够好的理解。

但我可以告诉你一件事...

足够好的门槛可能比你想象的要低。

经常发布好的代码比偶尔发布完美的代码要好得多。

这就是敏捷开发的重要理念。

你还不知道答案。你不知道用户需要什么。所以，写一些足够好的代码来获取一些反馈！

然后，让反馈来驱动后续工作。

有用的启发法

以下是我为了保持简单并快速发布而问自己的问题：

• 我的代码解决了问题吗？
• 它是否简单易读？
• 我是否为功能编写了测试？

如果是，那就完成了！

我不会为未来的需求或花哨的设计模式而烦恼。将来，我会知道更多，也会为自己第一次编写的简单易读的代码感到高兴。

消除完美主义

作为工程师，我们希望事物完美地契合。在处理每个可能的边界情况或未来可能性时，做好清晰的工作会让人满意。

然而，这是一项徒劳的任务。

每个编码决策都有取舍。没有完美的代码。你的职业生涯将不断进行重构。

越早放弃完美主义的幻想，越好。

知道你的代码不必完美实际上是一种解脱！

允许写糟糕的代码？

让我明确一点。这并不是允许你编写糟糕的代码。

每当我谈到"good enough"时，我真正指的是好的代码。你不应该编写难以维护的糟糕代码。有趣的是，每次我写这样的文章时，总有人在评论中试图批评我，认为我在提倡糟糕的代码。

让我明确一次：你应该编写良好、清晰的代码。

它应该简单易于维护。

当代码可用并解决了手头的问题时，你应该停止编写代码。

成为一个务实、解决问题的开发者，而不是一个完美主义者。这就是我的观点。

列表清单

每星期，我都会为软件开发者写一些新的内容。

点赞、关注、转发，与2,000名软件开发者一起学习顶级编码人员的习惯和技能！