Difference between revisions of "TCR: Test and Commit or Revert"
From CitconWiki
Jump to navigationJump to search| Alexconlin (talk | contribs)  (Add slides and link to code) | |||
| Line 7: | Line 7: | ||
| '''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 ;)
