Difference between revisions of "Legacy Code TDD with Mob Programming"

Line 1: Line 1:
 
== Overview ==
 
== Overview ==
Either
+
Either:
 
* 5 days with one team (of about 7 people, though less people is OK) for thorough and 'sticky' learning, behavior changes, and improvement of your code and designs
 
* 5 days with one team (of about 7 people, though less people is OK) for thorough and 'sticky' learning, behavior changes, and improvement of your code and designs
 
* 2.5 days with one team, and then 2.5 days with another team, for an abbreviated version
 
* 2.5 days with one team, and then 2.5 days with another team, for an abbreviated version
 +
  
 
Your Problem: A ton of legacy code (in C, Ruby, C++, Java, JavaScript, ...) without solid automated tests, and with lots of entanglements and dependencies. You want to break these dependencies, transform it to clean code, unit test the old code ("bring it under test") and also do TDD in the context of this legacy code, improve the larger design/architecture, and establish changed/better developer behaviors while coding.
 
Your Problem: A ton of legacy code (in C, Ruby, C++, Java, JavaScript, ...) without solid automated tests, and with lots of entanglements and dependencies. You want to break these dependencies, transform it to clean code, unit test the old code ("bring it under test") and also do TDD in the context of this legacy code, improve the larger design/architecture, and establish changed/better developer behaviors while coding.
 +
  
 
Note that Legacy-code TDD is not the same process as new-code TDD, though there are similarities.  
 
Note that Legacy-code TDD is not the same process as new-code TDD, though there are similarities.  

Revision as of 09:17, 29 June 2015

Overview

Either:

  • 5 days with one team (of about 7 people, though less people is OK) for thorough and 'sticky' learning, behavior changes, and improvement of your code and designs
  • 2.5 days with one team, and then 2.5 days with another team, for an abbreviated version


Your Problem: A ton of legacy code (in C, Ruby, C++, Java, JavaScript, ...) without solid automated tests, and with lots of entanglements and dependencies. You want to break these dependencies, transform it to clean code, unit test the old code ("bring it under test") and also do TDD in the context of this legacy code, improve the larger design/architecture, and establish changed/better developer behaviors while coding.


Note that Legacy-code TDD is not the same process as new-code TDD, though there are similarities.

While working on your real code, I coach and show the team how to bring the legacy code under test so that they can test units in isolation, and apply TDD to legacy code. Developers find it tough to see how to do this without someone experienced directly coaching them, and they invariably say that this coaching is extremely worthwhile.

The style of learning is mob programming, a great way to intensively increase the learning about the code within a team. How does mob programming work? There is computer projector and screen on which the code is displayed. There is only 1 computer. Each team member drives the computer for a short period -- usually 12 minutes. Then it rotates to the next person. Constantly during this period I am guiding the team in how to do legacy-code TDD.


Environment - Room, Tools, Texts

Coaching Environment - TDD