TDD for Embedded C
2015-09-22 13:30:53 UTC
Most useful learnings:
Being much more conscious of the single responsibility principle for the software modules and the interactions among them while writing the code in order to avoid spaghetti code for the future.
Concepts v exercises:
Presentation v discussion:
I'd suggest that the trainer sits down with the pairs more closely who were not performing quite well with the exercises.
I'd also suggest that when the trainer has a good idea about the individual's performance after the first couple of pair programming exercise, trainer matches the pairs for the following exercises more efficiently depending on their individual performance.
Instead of enforcing 1 exercise per discussion topic or subject, there might be 1 or 2 more options which the attendees would agree and choose to work on. Sometimes, a certain example would make much more sense than the other depending on the engineers' past experience.
He is kind and professional. He knows the challenges we have in the industry very well. He is truly an expert on the subject of TDD in embedded C.
For the new code, it sounds completely feasible and we will and must do it.
For the existing code, we can't afford it for the majority of the cases as we are in bug fixing process already and are fast approaching to the project deadline. I personally believe I need some confidence in TDD before refactoring the legacy production code properly.
Challenges to applying:
Time-wise, the way we start writing software and converting the legacy code should be communicated to the stakeholders very well to avoid short-term disappointments.
Legacy code workshop:
Recommend to others: