Comments by "Daniel Sandberg" (@ddanielsandberg) on "The REAL SECRET To Refactoring!" video.

  1. 1. If possible, start with writing high-level external application-level/API/functional tests for the current solution. Commit whatever crimes you need to get those running. These tests are your regression defensive line. 2. Next, follow ALL the code-paths towards the parts you want to change, write enough of some kind of tests for each layer you go through to give you confidence that you have understood it right. 3. Once you have reached your target module, write tests around that module's API. 4. Either refactor the module as is (scary), or break out some kind interface/headers/abstractions that specifies the contract of the module and start to write a completely new implementation using TDD in parallel with the old one, while keeping the tests from (3) as long as needed, use build-flags to select which implementation to include in the build and run the tests against (branch by abstraction). I think this pattern is called "lighting the forest". Each test adds a light to your path so that you can safely go on your journey. PS. I haven't done any embedded programming for 20 years, and never tried this kind of refactoring with embedded stuff so YMMV.
    5