TCR变体(测试&&提交||还原)

肯特·贝克(Kent Beck)在他的帖子中建议“测试&&提交|| 还原。’ 这是一个简化。 本文探讨了哪些可用的变体以及如何实现TCR。

注意 :TCR对您来说是新手? 查看 这篇文章 ,其中提供了背景,上下文和示例。

原始版本的架构为’test && commit || 还原。’ 为了回答有关特定命令的问题,Kent建议:

  $ ./test && git commit -am工作||  git reset —很难 

最初的近似存在一些缺陷,您在实现某些东西后就会立即认识到:只要您的项目未编译,它就会还原,并且一旦当前测试失败,该测试就会被删除。

在伪代码中:

  if(test()。success) 
承诺()
其他
还原()

第一种选择解决了编译问题。

  $ ./buildIt &&(./test && git commit -am working || git reset — hard) 

此版本尝试首先构建软件。 如果失败,则不执行任何操作-不提交,不还原。 编译问题已解决。

有一些细节很有趣。 例如,Gradle已在其构建过程中进行了测试。 因此,您在构建命令中执行了“ -x文本”。 您也不会损失性能(至少对于Gradle而言),因为测试使用内置的工件-无需做任何额外的工作。

在伪代码中:

  if(build()。失败) 
returnif(test()。success)
承诺()
其他
还原()

最初建议的第二个问题是您的单元测试始终被删除。 这个想法是,不要重设“ test”文件夹,而只重设“ src”文件夹。 获取“重置”命令无法执行此操作。 因此,我们使用’checkout’:

  #git checkout HEAD — src / main / $ ./buildIt &&(./test && git commit -am working || git checkout HEAD — src / main /) 

将其放在其脚本中称为revert是值得的(阅读起来要漂亮得多)。

在伪代码中:

  if(build()。失败) 
returnif(test()。success)
承诺()
其他
恢复('src / main')

如果由于一个小错误而不得不一次又一次地重写恢复的生产代码,那么重写您的生产代码将变得很烦人。 为了引入一种“复制粘贴”内存,我们可以使用Git的内置工具(“存储”)。

  ## git stash drop 0 2&> / dev / null;  git add -A && git stash push $ ./buildIt &&(git stash drop 0 2&> / dev / null; git add -A && git stash push) 

TCR启动并还原我们的代码后,我们仍然可以输入

  $ git stash适用 

找回错误的代码。 您可以争辩说,这会伤害TCR的想法,但有时您想制作此版本。

将命令拆分为不同的脚本是一个好主意。 维护它们变得很高兴(主要是尝试不同的还原策略)

  $ cat ./测试 
./scripts/buildIt &&(./scripts/runTests && ./scripts/commit || ./scripts/revert)$树脚本
脚本/
├──buildIt
├── 提交
├── 恢复
└──runTests $ cat脚本/ buildIt
./gradlew build -x test $猫脚本/提交
git commit -am working $ cat脚本/还原
#git reset --hard
git checkout HEAD-src / main / $ cat脚本/ runTests
./gradlew测试

“您能走多低?”手动触发TCR会记住TDD。 但是,如果我们想进一步缩短反馈周期,我们可以做更多的事情。 这种方法适用于Google文档(这是我们的圣杯)的方向:

 虽然真实 

./tcr
已完成$猫tcr
./buildIt &&(./test && git commit -am working || git checkout HEAD — src / main /)

那么,为什么叫“伙伴”呢? 您必须尝试一下。 当您进行编码时,就像有人坐在您旁边,并且一旦发现错误,他就会使您回到绿色状态。 在此斐波那契帖子中的示例中,将加号替换为减号。 幽灵手立即将其变回原样。 与好友一起,您将感受到TCR的真正精神。

伪代码:

  while(true){ 
tcr()
}函数tcr(){
if(build()。失败)
returnif(test()。success)
承诺()
其他
还原()
}

Alejandro Marcu指出,无限循环是对资源的浪费。 “监视伙伴”带来了优化,因为它引入了文件系统监视(例如Linux中的ionotify):

 虽然真实 

inotifywait -r -e修改。
./tcr
已完成$猫tcr
./buildIt &&(./test && git commit -am working || git checkout HEAD — src / main /)

ionotifywait -r src阻止,直到src目录中发生更改。 其余部分与“好友”中的相同。 伪代码看起来很熟悉:

  while(true){ 
block_until_change_in_directory('src')
tcr()
}函数tcr(){
if(build()。失败)
returnif(test()。success)
承诺()
其他
还原()
}

您可以通过YouTube上的“手表好友”观看亚历杭德罗实现示例。

如此处更多说明,TCR主要包括两个部分:

  1. ‘test && commit’:可以与push / pull一起使用以与您的同事同步。 它成为协作工具。
  2. ‘test && revert’:与TDD一样,它改变了您的编码方式并更好地支持TDD的思想(此处也包括提交,但仅作为实现细节)。

在协作者中,我们添加并运行了另一个脚本以及另一个变体(肯特·贝克(Kent Beck)将其作为“廉价的林宝”的一部分提出:

 虽然真实 

git pull --rebase
git push origin master
完成

该脚本使同步变得透明-就像Google文档一样。 我们马上运行“ ./tcr”。 (无论您选择哪种变体),第二个Git命令将其推送,并且在您同事的每个工作场所中,第一个命令将同步他们的代码。

在伪代码中:

 异步{ 
while(true){
Git.pull('rebase')
Git.push('origin','master')
}
} ./ tcr

一个特别强大的变体是“协作者”和“好友”在一起。


git pull --rebase
git push origin master
完成##打开新的Tabwhile true

./tcr
完成

我更喜欢将“ The Relaxed”与“ The Split”作为“ ./tcr”的实现。

在伪代码中:

 异步{ 
while(true){
Git.pull('rebase')
Git.push('origin','master')
}
}函数tcr(){...}异步{
while(true){
tcr()
}
}

讲故事的人

只要我不确定这确实有效,我就创建了另一篇文章。 但是感觉一下。

tl; dr而不是仅重置代码,“讲故事的人”以一种“人为”的方式进行通信,因此,就像一对人在我的项目上远程工作一样。

尝试所有这些,玩耍。 您可能会找到一个更好的版本。 请确保,您让我知道。