M K Using Japanese to save your I a Legacy S/W k n + a b d - - PowerPoint PPT Presentation

m k
SMART_READER_LITE
LIVE PREVIEW

M K Using Japanese to save your I a Legacy S/W k n + a b d - - PowerPoint PPT Presentation

M K Using Japanese to save your I a Legacy S/W k n + a b d a o n 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


slide-1
SLIDE 1

M I k a d

  • Using Japanese to save your

Legacy S/W

K a n b a n

+

slide-2
SLIDE 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?

slide-3
SLIDE 3

We can

Revert

  • ur

code!

slide-4
SLIDE 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

  • ne)
  • Visualize (add to graph)
  • REVERT !!

Repeat until no breakages occur.

slide-5
SLIDE 5

Decouple Content Edit & Publishing Servers

Create Standalone Publish Server Reimplement DB Interface Remove Methods from Edit Server Code Separate Storage Interface

D i s c o v e r y R e f a c t o r

฀ ฀ ฀ ฀ ฀ ฀ ฀ ฀

Move Check User Permissions Separate Approval Logic Move Publish-Reject Code Change Deployment Properties

slide-6
SLIDE 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

slide-7
SLIDE 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
slide-8
SLIDE 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…

slide-9
SLIDE 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…

slide-10
SLIDE 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

slide-11
SLIDE 11

Triage Ready Intake Update Tests FIX Re-Test Deploy DONE Done Done Done

฀ ฀

slide-12
SLIDE 12

T H A N K Y O U

あ り が と う ご ざ い ま し た