TDD for Embedded C
2018-08-31 17:47:13 UTC
Most useful learnings:
Seeing how step-by-step test development leads to code that is easier to test and only has the things we need was eye-opening. Definitely made me reconsider how I write code. The instructor-provided exercises were useful.
Concepts v exercises:
Presentation v discussion:
Too much discussion
Reviewing ALL the feedback as a class grew repetitive. The first exercise was clear in my opinion, but the second exercise's "almost real" nature made me get stuck on the gaps in its application to reality. The third exercise with the datasheet was the best, in my opinion. Very clear goal in terms of testing.
In addition, reviewing our own legacy code did not seem to be well-prepared on our part. It didn't seem like we came in with a clear plan for what to review and with who.
Second example somewhat unclear. Higher bar needs to be placed on what legacy code should be reviewed and how it will be reviewed.
Answers to participant questions often felt weirdly defensive rather than presenting a reason-based argument. However, James is likely attacked by a multitude of devs for every session, so I definitely understand the need to stand ground.
Answers were often "i don't know how to answer that", which is fine because there is no one-size-fits-all, but I believe the devs were hoping for some sort of guiding opinion from experience.
Yep... except there's soooooo much legacy code
Challenges to applying:
It's hard to get over the feeling of writing tests slowing everything down. The class showed me it's probably faster to write tests first, but it's against my natural desire to "get the feature done". More tickets are created per day than are finished, which induces panic to get things done faster.
Legacy code workshop:
Recommend to others:
Only if improved