Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Mikado + Kanban

1.500 Aufrufe

Veröffentlicht am

This is the presentation I will be giving at GLASScon 2.5 on how to combine the Mikado Method with Kanban to help folks manage changes to their legacy software. This has also been proposed for the Saturn Conference as well.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

Mikado + Kanban

  1. 1. M I k a d o Using Japanese to save your Legacy S/W K a n b a n +
  2. 2. Mikado Method  Mikado Game Making a change to your legacy code is not unlike picking out the Mikado from the other sticks in the pile. Removing one impacts the others. And not in a good way… What is the biggest difference?
  3. 3. We can Revertour code!
  4. 4. The Guts of the Mikado Method • Make the ONE change you need/want to make • See what broke – these are pre-requisites (the next set of changes to make before doing this one) • Visualize (add to graph) • REVERT !! Repeat until no breakages occur.
  5. 5. Decouple Content Edit & Publishing Servers Create Standalone Publish Server Reimplement DB Interface Remove Methods from Edit Server Code Separate Storage Interface Discovery Refactor ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Move Check User Permissions Separate Approval Logic Move Publish-Reject Code Change Deployment Properties ✓
  6. 6. For Defects… • Need to use exploratory and regression testing to ID the next items to be graphed • If not present, wrap unit tests around what you are touching • Have testing occur in an environment that mimics as close to production as possible
  7. 7. Real Mikado Power • Comes when you have unit, integration, and acceptance tests • These help reveal necessary refactors by showing failures that the change creates • Safer than exploration to find breakages
  8. 8. Some Restructuring Considerations • Refactor Before Adding Functionality • Separate Bulky Interfaces (limiting the consumers it serves) • Extract Methods/Classes into Common Libraries Let’s look at the first one…
  9. 9. Refactor Before Adding Functionality • Suppose - . . . public static final int FIVE_CARD_POKER = 0; public static final int INDIAN_POKER = 1; . . . Public class CardGameEngine { . . . public void deal (Game game, User user, Dealer dealer) { if (game.getType() == FIVE_CARD_POKER { user.setCards(dealer.deal(5)); } else if (game.getType() == INDIAN_POKER { user.setCards(dealer.deal(1)); } else { // else what? } } • Want to add War (each player is dealt 26 cards) • Could add it to the If-Then-Else logic, but this will get messy, especially if I wanted to add more…
  10. 10. Mikado Graph for Refactor Add War card game Refactor If statements to extract game-specific logic Move 5 Card Poker Logic to FiveCardPoker class Move Indian Poker Logic to IndianPoker class Implement War Logic to War class
  11. 11. Triage ReadyIntake Update Tests FIX Re-Test Deploy DONE Done Done Done ✓✓
  12. 12. T H A N K Y O U あ り が と う ご ざ い ま し た

×