Difference between revisions of "TCR: Test and Commit or Revert"

From CitconWiki
Jump to navigationJump to search
m (formatting)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
 +
'''Slides''': https://speakerdeck.com/islomar/tcr-workshop?slide=5
  
 +
'''Code (including the commits we made in the session)''': https://github.com/alexconlin/tcr-workshop
  
 +
'''Kent Beck's original blog post on the topic''': https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864
  
'''Hanselminutes - Fresh Talk and Tech for Developers''' : ''test && commit || revert with Kent Beck'', December 20, 2018 <br />
+
'''Hanselminutes - Fresh Talk and Tech for Developers''': ''test && commit || revert with Kent Beck'', December 20, 2018 <br />
 
https://overcast.fm/+BVNcXTjM
 
https://overcast.fm/+BVNcXTjM
 +
 +
Other notes: [[User:Robpark]]
 +
* Do you squash all these little commits?
 +
* Context matters .. if open source project for pr submission then yes .. if for internal work on a team, you should probably merge every commit every time.
 +
* We (as from the example repo) hacked the rules to only revert the prod code not the test code
 +
* There’s also another viable modification to simply revert (everything) every n minutes where n <= 5
 +
* Makes you think .. do you need to over design? .. under think? .. or be calm and not worry so much about the revert  ;) ... the point I believe we mostly equally concluded was look to make small changes and small commits and small merges wherever possible
 +
* The one downside with a “simple” problem is we actually never had a revert (other than as a test ) yes, we were that good at Fibonacci ;)

Latest revision as of 11:10, 20 May 2019

Slides: https://speakerdeck.com/islomar/tcr-workshop?slide=5

Code (including the commits we made in the session): https://github.com/alexconlin/tcr-workshop

Kent Beck's original blog post on the topic: https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864

Hanselminutes - Fresh Talk and Tech for Developers: test && commit || revert with Kent Beck, December 20, 2018
https://overcast.fm/+BVNcXTjM

Other notes: User:Robpark

  • Do you squash all these little commits?
  • Context matters .. if open source project for pr submission then yes .. if for internal work on a team, you should probably merge every commit every time.
  • We (as from the example repo) hacked the rules to only revert the prod code not the test code
  • There’s also another viable modification to simply revert (everything) every n minutes where n <= 5
  • Makes you think .. do you need to over design? .. under think? .. or be calm and not worry so much about the revert ;) ... the point I believe we mostly equally concluded was look to make small changes and small commits and small merges wherever possible
  • The one downside with a “simple” problem is we actually never had a revert (other than as a test ) yes, we were that good at Fibonacci ;)