Difference between revisions of "TCR: Test and Commit or Revert"
From CitconWiki
Jump to navigationJump to searchAlexconlin (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 10: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 ;)