完美是无用的

我们向加入Semaphore团队的初级程序员传授的最重要的事情之一就是以小迭代的方式进行交付的思维模式。这是一个简单的概念，然而，由于对“小”的主观理解，不可避免地存在误解。因此，在实践中，我们需要通过示例来教导他们“小”的真正含义。

当你缺乏经验时，想要完成并展示自己最好的作品的渴望常常会导致完美主义。在编程中，完美主义表现为“我还没有提交我的拉取请求，因为我还没有完成所有的事情”。

完美主义与开发商业软件的目标相悖——最好是尽快为用户提供有用的东西。完美主义者会制造假想的障碍，最终什么也做不成。

最近，两位初级程序员正在为我们的市场团队开发一个新的报表界面。该界面需要整合给定时间范围内的两个数据源，并呈现分页结果视图。需要该报表的团队从未见过该界面提供的数据。如果报表的第一个版本不包含日期选择器和前 25 条结果之后的分页功能，会不会有什么问题？当然不会。因此，我们鼓励他们发布不包含日期范围和分页功能的界面。初步结果提供了足够的价值和改进思路。市场团队掌握了一些可用的数据，而开发人员则继续处理剩余的任务。

问题的关键在于将任务分解成最小的有用部分。接下来，你需要评估每个部分的复杂性，并与“利益相关者”（客户、委托人、产品经理或功能用户）沟通预期。

假设一位设计师最近更新了影响四个不同屏幕的几个细节。将这些更改集成到四个单独的拉取请求中最好，还是一个？这时就需要考虑复杂性，即完成每个请求所需的时间。如果每个请求都需要一天时间，那么四个单独的拉取请求可能是最好的选择。如果所有请求加起来只需要不到一个小时就能完成，那就把它们合并成一个拉取请求吧。这三个任务是不是很简单，但第四个任务需要休息的设计师的额外投入，而且所需的时间比其他所有任务加起来还要多？最好先让你的用户满意你能尽快完成的任务，然后再单独做最后一项。

提前发布通常会给你带来意想不到的反馈。也许最初的版本非常好，以至于没有人真正需要那些“缺失”的东西。又或者，整个想法并没有真正达到预期，需要重新考虑。目标是学习并帮助他人。继续前进吧。