DevTernity 2018: Surviving Legacy Code
Contact
- J. B. Rainsberger
- https://www.twitter.com/jbrains
- https://ask.jbrains.ca Ask me a question.
- https://tell.jbrains.ca Tell me something that you’d like me to know.
- https://blog.thecodewhisperer.com Read about programming topics.
- https://blog.jbrains.ca Read about software development topics, but not (directly) programming.
- https://www.jbrains.ca
Some Useful Discussion Groups
Literally 20 years of wisdom in the archives of each group!
Code
- https://github.com/jbrains/trivia Legacy code base for you to practise on.
References and Further Reading
The Fundamentals
- J. B. Rainsberger, “The Four Elements of Simple Design”. Describing the rules that I follow in order to guide the evolution of my designs.
- J. B. Rainsberger, “Putting An Age-Old Battle To Rest”. Describing more about how the two primary rules of simple design work together.
- Corey Haines, Understanding the Four Rules of Simple Design. Corey wrote the book that I perhaps should have written: many, many examples of how to use the four elements of simple design to improve design before it becomes a problem.
Tricks and Principles
- J. B. Rainsberger, “Relative Include Paths and the Slow, Certain March Towards Legacy Code”. Slowly move relative paths up the call stack in order to make it easier to run your code on any machine.
- Tom DeMarco and Tim Lister, Waltzing with Bears. Risk management for software development.
- J. B. Rainsberger, “Surviving Legacy Code with Golden Master and Sampling”.
- J. B. Rainsberger, “How Not To Write Golden Master Tests”. An example of a questionable implementation of golden master.
- Emily Bache, Screencast showing Approval Testing and Mutation Testing. Here, Emily announces her new video series, starting with Approval Testing (a way to do Golden Master) and Mutation Testing (a small form of chaos engineering).
The Dependency Inversion Principle
You can find a series of articles at https://blog.thecodewhisperer.com/series#dependency-inversion-principle-dip.
- J. B. Rainsberger, “Demystifying the Dependency Inversion Principle”. An overview of the DIP and practical examples of how to use it.
- J. B. Rainsberger, “Keep Dependency Injection Simple”. You don’t need a container to do dependency injection. No, really. You don’t need a container.
- J. B. Rainsberger, “Relative Include Paths and the Slow, Certain March Towards Legacy Code”. A common pattern that I see programmers fall into. They don’t even see it happening. It usually results in legacy code.
Test Doubles (also known as Mock Objects)
- Matteo Vaccari, “How I learned to love mocks”. A very good example of how to use test doubles and especially a very good example of how to go from “This test feels weird” to “Refactor that”.
- J. B. Rainsberger, “Beyond Mock Objects”. I like test doubles, but I like it even more when I don’t need them.
- J. B. Rainsberger, “Injecting Dependencies, Partially-Applied Functions, and It Really Doesn’t Matter”. You can take advantage of the isomorphism between collaborators and function parameters to give yourself extra freedom to write your tests more flexibly. This allows you to defer certain design decisions until you have more evidence for them. This helps you avoid designing yourself into a corner.
The Classics
- Martin Fowler and others, Refactoring: Improving the Design of Existing Code.
- Michael Feathers, Working Effectively with Legacy Code. Still the gold standard for learning elementary refactoring techniques that meet the special challenges of legacy code.
- Joshua Kerievsky, Refactoring to Patterns. The link between design patterns and evolutionary design.
- Dale Emery, “Motivation”.
- J. B. Rainsberger, “The Two-Minute Rule”. When a request for work finds you, if you can complete it in two minutes, then do it now; otherwise, schedule it for later.
- J. B. Rainsberger, “Getting Started with Getting Things Done”.
- David Allen, Getting Things Done.
- J. B. Rainsberger, “The Eternal Struggle Between Business and Programmers”.
- Tom DeMarco and Tim Lister, Waltzing with Bears.
- Gene Kim, Kevin Behr, and George Spafford. The Phoenix Project.
- Roger Martin, The Responsibility Virus.
“Advanced” Topics
- J. B. Rainsberger, “The Myth of Advanced TDD”. That thing that you believe is “advanced TDD” would probably lead you in a worse direction, and not a better one.
- Simon Harris, “Functional programming in object oriented languages”. You don’t need to learn Haskell to adopt a more “functional” style in your OO code. On the contrary, I encourage you to adopt a more functional style in your OO code in order to make it safer. I have experienced TDD this way: it has slowly and patiently led me in the direction of more functional code, and this seems to have happened to more people than just me.