REPL驱动的设计

如果你在Facebook上关注我，你就会知道我每天都在发布冠状病毒的统计数据。我使用Johns Hopkins GitHub存储库中的每日更新来生成这些统计数据。

起初，我只是手工将数据复制到电子表格中。但这很快就变得单调乏味了。

然后，在3月下旬，我编写了一个小Clojure程序来提取和处理数据。每天早上我都会启动回购，然后运行我的小程序。它读取文件、计算数学并打印结果。

但在过去的几周里，我对这个程序做了相当多的小修改；而且它已经有了很大的增长。在进行这些调整时，我选择使用不同的规程：REPL驱动的设计。

REPL驱动的设计在Clojure圈子里非常流行。它也很有诱惑力。我们的想法是，您可以在REPL中尝试一些实验，以确保您有正确的想法。然后使用这些想法在代码中编写一个函数。最后，通过在REPL调用该函数来测试该函数。

事实证明，这是一种非常令人满意的工作方式。周期时间-代码实验和REPL测试之间的时间-几乎与TDD一样小。这使人们对解决方案充满信心。它似乎还节省了模拟和创建假数据所需的时间，因为至少在我的情况下，我可以在REPL测试中使用真实的生产数据。因此，总体而言，我感觉自己比TDD走得更快。

但后来，在4月下旬，我想做一些比往常更复杂的事情。这需要对我的基本结构进行设计更改。突然我发现自己充满了恐惧。我无法确保这些设计更改不会以某种方式破坏系统。如果我做了这些更改，我将不得不检查每一个输出，以确保它们都没有损坏。因此，我推迟了改革，直到我可以鼓起勇气，把需要的专门时间放在一边。

这个变化并不太痛苦。Clojure是一种易于使用的语言。但验证并不是微不足道的，这导致我在部署程序时发现了一个小错误-4天后我捕捉到的一个小错误。这个错误迫使我回去更正我生成的数据和图表。

为什么我需要修改设计？因为我没有嘲笑和创造假数据。我的函数只是直接从repo文件中读取。没有办法给他们传递假数据。我需要进行的设计更改与嘲笑和伪造数据所需的设计更改完全相同。

如果我坚持TDD原则，我就会自动进行设计更改，就不会面临恐惧、延迟和错误。

具有讽刺意味的是，TDD会强迫我进行的设计更改正是我最终需要的设计更改？不用谢。为了传递孤立的输入和收集孤立的输出，TDD强加给我们的解耦几乎总是强调灵活性和促进变化的设计。

所以我已经吸取了教训。REPL驱动的开发感觉比TDD更容易、更快；但事实并非如此。下一次，我又回到TDD了。