别名——是时候停下来并发布了
前几天，我写了一篇关于足够好的代码的文章。
这个想法很简单。当代码达到足够好的水平时就停止编码。超过足够好的努力都是浪费的工作。
但是这仍然留下了一个重要的问题：如何定义“足够好”。
学会停下来
没有适用于每种情况的明确的“足够好”定义。
你需要根据你的环境和目标来调整对足够好的理解。
但我可以告诉你一件事...
足够好的门槛可能比你想象的要低。
经常发布好的代码比偶尔发布完美的代码要好得多。
这就是敏捷开发的重要理念。
你还不知道答案。你不知道用户需要什么。所以，写一些足够好的代码来获取一些反馈！
然后，让反馈来驱动后续工作。
有用的启发法
以下是我为了保持简单并快速发布而问自己的问题：
- 我的代码解决了问题吗？
- 它是否简单易读？
- 我是否为功能编写了测试？
如果是，那就完成了！
我不会为未来的需求或花哨的设计模式而烦恼。将来，我会知道更多，也会为自己第一次编写的简单易读的代码感到高兴。
消除完美主义
作为工程师，我们希望事物完美地契合。在处理每个可能的边界情况或未来可能性时，做好清晰的工作会让人满意。
然而，这是一项徒劳的任务。
每个编码决策都有取舍。没有完美的代码。你的职业生涯将不断进行重构。
越早放弃完美主义的幻想，越好。
知道你的代码不必完美实际上是一种解脱！
允许写糟糕的代码？
让我明确一点。这并不是允许你编写糟糕的代码。
每当我谈到"good enough"时，我真正指的是好的代码。你不应该编写难以维护的糟糕代码。有趣的是，每次我写这样的文章时，总有人在评论中试图批评我，认为我在提倡糟糕的代码。
让我明确一次：你应该编写良好、清晰的代码。
它应该简单易于维护。
当代码可用并解决了手头的问题时，你应该停止编写代码。
成为一个务实、解决问题的开发者，而不是一个完美主义者。这就是我的观点。
列表清单
每星期，我都会为软件开发者写一些新的内容。
点赞、关注、转发，与2,000名软件开发者一起学习顶级编码人员的习惯和技能！
