REPL驱动的设计

2020-05-28 07:02:17

如果你在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了。