Please enable JavaScript.

Coggle requires JavaScript to display documents.

Surviving to a legacy codebase How we take back control of legacy…

- - - - the words and the language you'll hear from the users and the subject matters...
  - - - "Tidying up works through a series of small, safe steps."
    - - "You have a lot more to lose by a mistake than you have to win by any individual success"
  - - - Decide deliberately which battle you want to fight now and which battles it's better to fight later on
        
        you cannot win all these battles at once!
      - Use a TODO list
      - Visualize what you left behind
- - - - as you rest, it settles, no matter if you aren’t looking at it
  - - - Tidying up works through a series of small, safe steps
    - - you have a lot more to lose by a mistake than you have to win by any individual success
    - - Unlike feature development, where it sometimes makes sense to land only when a chunk of work is done, tidying up is time based
      - Commit after each single tidy!
    - - If I tidy, run the tests, and encounter a failed test, then if I can fix it immediately I do. If I try to fix it and fail, I immediately revert to the last known good state
      - test && commit || revert
    - - sometimes I want to see how things might play out, I perform a sequence of tidyings and revert. The second time will go much faster!
    - - This can be tough when you run across the chance to tidy in the midst of writing new code
      - Either finish and then tidy or revert, tidy, and make your changes
- - - - It doesn't matter how well written it is
      - it doesn't matter how pretty or object-oriented or well-encapsulated it is.
  - - - That stuff that other people wrote. They've all since left the company, so there's nobody left who knows how it works. It really needs to be refactored properly (preferably rewritten), but there's no time, and everything's using it.
      - Worse, the people who wrote it originally might still be in the company. They're too busy (and it was too long ago for them to remember) to answer questions on how it works, and they've got too much ego invested in it to countenance anyone rewriting it.
        (from http://wiki.c2.com/?LegacyCode)
- - - - as code coverage grows, your courage raises too
  - - - we build up our knowledge of what the code actually does
      - we can run our tests and find out immediately whether we’ve changed behavior
    - - When a system goes into production it becomes its own specification
  - - - coarse-grained
      - ...then Unit / Component Tests
        
        fine-grained
        
        faster
        
        harder to write initially
      - slower
      - easier to write without touching the existing code
      - more fragile
        
        more sensible to many movable parts
      - black-box
  - - - Why would you want to commit so often?
        Well you are working with a system that could be very hard to change and very hard to understand. Mistakes can come out from any small change. You want to have a very easy to use undo button with all the changes.
        You would not like to be in the situation where some tests stop passing and you do not know what you did. Always when something is wrong, you can undo and continue from a clear state. This is a kind of backtracking in a maze of possible decisions.
- - - - audience poll
  - - - give context
        
        link to Legacy Code definitions
        
        our way of surviving
  - - - fix a bug
        
        broken dice
        
        players with the same name can join
        
        is that a bug if it's used in production?
        
        find-a-bug game!
      - add the next killing feature!
        
        game can be started by almost two players, so that we avoid waiting more users to reach four players...