Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software
The posts in this group of categories relate in some way to my book, Beyond Legacy Code (http://BeyondLegacyCode.com). Post related to one of specific nine practices from the book are assigned subcategories. For more information about my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, please visit my publisher’s website
https://pragprog.com/book/dblegacy/beyond-legacy-code or check out my Amazon webpage https://www.amazon.com/Beyond-Legacy-Code-Practices-Software/dp/1680500791
Refactor to Learn an Existing System
One of the best opportunities to refactor code is when you’re starting to get to know it. This not only helps improve the code but it also improves your understanding of the code and helps everyone else who touches the code in the future. There are many kinds of refactorings that one can do to …
Continue reading “Refactor to Learn an Existing System”
Read MoreWhy Practice 9: Refactor Legacy Code
Having put the words “legacy code” in the title of my book, people often confuse my book with Michael Feathers’ book, Working Effectively with Legacy Code. On one hand, it’s great to be in such esteemed company. I love Michael’s book and I refer to it often. It’s full of great techniques for taming legacy …
Continue reading “Why Practice 9: Refactor Legacy Code”
Read MorePractice Good Development Habits
As you can see from my last seven blog posts, doing emergent design is not for beginners. Doing emergent design is an advanced development practice. But it’s not enough to know about good development principles and practices. It’s not enough to know about design patterns. We have to use them. We have to apply them. …
Continue reading “Practice Good Development Habits”
Read MoreBe Merciless
One of the most important characteristics that I find senior developers have is the ability to change their minds and let go of an existing design when it no longer serves its purpose. What I find time and time again is that developers become attached to the current design even in the face of changing …
Continue reading “Be Merciless”
Read MoreFocus on Code Quality
I believe in the Agile Manifesto. I know most of the original authors and they know that I think they’re pretty cool. They got so much right in such a short amount of space and that’s very admirable. But there’s one thing that I think they kind of missed the mark on, so I’m going …
Continue reading “Focus on Code Quality”
Read MoreUnderstand Refactoring
Refactoring code is not just changing the design of code without changing its external behavior, it’s also doing it in small, safe steps that are repeatable. This is what elevates refactoring to a discipline that we can talk about and create best practices around rather than just willy-nilly ways of changing code. It was Martin …
Continue reading “Understand Refactoring”
Read MoreUnderstand Test-Driven Development
Another important aspect of doing emergent design is doing it safely and that means doing it while code is under test. But not just any tests, we have to write behavioral tests that don’t break when we refactor our code to emerge our designs. These are precisely the kind of tests that I’ve been talking …
Continue reading “Understand Test-Driven Development”
Read MoreUnderstand Design Patterns
Doing emergent design is an advanced practice that requires knowledge of a great many skills. One key skill that all professional software developers should acquire as they journey towards mastery is a deep understanding of design patterns, both in concept and in terms of the 23 design patterns called out by the Gang of Four …
Continue reading “Understand Design Patterns”
Read MoreUnderstand Object-Oriented Design
The first “barrier to entry” for doing emergent design, an advanced developer practice for incrementally building software, is to understand object-oriented design and development. In theory, the object-oriented model should be easy to understand but I don’t often see it well-understood in industry. I’ve reviewed millions of lines of code from companies across a range …
Continue reading “Understand Object-Oriented Design”
Read MoreWhy Practice Eight: Implement the Design Last
By now you’ve probably figured out that I am a weirdo and that I like doing things differently than other people. In fact, I am an advocate of doing things backward. But I’m not being random here. As it turns out, the way most people build software includes some of the worst inefficiencies that I …
Continue reading “Why Practice Eight: Implement the Design Last”
Read MoreUse Accurate Examples
I discussed many benefits of using test-first development over these last eight blog posts. I find many benefits to doing test-first development but one stands out to me to be the biggest benefit and that is that the tests that I write concretize abstract requirements. This makes requirements understandable because they are real and tangible …
Continue reading “Use Accurate Examples”
Read MoreAvoid Over-Specifying Tests
The number one problem that I see developers have when practicing test-first development that impedes them from refactoring their code is that they over-specify behavior in their tests. This leads developers to write more tests than are needed, which can become a burden when refactoring code. I am a big advocate of having a complete …
Continue reading “Avoid Over-Specifying Tests”
Read MoreUse Mocks to Test Workflows
Unit testing frameworks are simple but I find them highly valuable. They contain a collection of assertions that I can use to validate a range of values and behaviors in the code that I’m building. I use assertions to verify that values are within bounds, exceptions are called when expected and not called when unexpected, …
Continue reading “Use Mocks to Test Workflows”
Read MoreTest Behaviors, Not Implementations
One of the keys to doing test-first development successfully and having the tests that you create to support you in refactoring code rather than breaking when you refactor code, is to write tests against the behaviors you want to create rather than how you implement those behaviors. This is an important insight but not always …
Continue reading “Test Behaviors, Not Implementations”
Read MoreShow What’s Important
Another aspect of using unit tests as specifications is to clearly show what’s important in each test. We do this primarily by naming things well and calling out generalizations and key concepts in the names of the symbols that we use. Every test has a name but you never call it, the system calls it …
Continue reading “Show What’s Important”
Read MoreUse Helper Methods
What? Helper methods? Whenever I see a class called Helper in code I think that the developer who wrote it wasn’t willing to take the time to discover what objects were really responsible for those behaviors. Although we would like to believe otherwise, in reality, there is no benevolent helper class in the world that …
Continue reading “Use Helper Methods”
Read MoreInstrument Your Tests
Here is the first of seven blog posts based on the section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, called Seven Strategies for Using Tests as Specifications. In this first post, I’ll discuss a technique called instrumentation that I learned from Scott Bain and Amir …
Continue reading “Instrument Your Tests”
Read MoreWhy Practice 7: Specify Behaviors with Tests
Developing software is a complex activity. Having worked with thousands of professional software developers, I recognize that there are many ways to implement any set of requirements and many are equally valid. This is true at least from the computer’s perspective but from the human perspective, we favor software that’s straightforward to understand and modify …
Continue reading “Why Practice 7: Specify Behaviors with Tests”
Read MoreMake Each Test Unique
I want to conclude this series of Seven Strategies for Great Acceptance Tests with the advice to make each test unique. I know this is easier said than done but it does get to the very core of what quality software development it’s all about. When our unit tests test units of behavior, then every …
Continue reading “Make Each Test Unique”
Read MoreSplit Behaviors on Acceptance Criteria
We think about what we build at different layers of abstraction. At the highest level, we have the minimum marketable feature set or MMF, which is composed of a list of features. A feature is some value that someone gets from using the system. This may involve the fulfillment of several things in the system, …
Continue reading “Split Behaviors on Acceptance Criteria”
Read MoreUse Examples
One of my favorite books on acceptance test-driven development is by Gojko Adzic called Specification by Example. This book talks about how you can specify the features of a system through examples cleanly and clearly so that they are straightforward to work through. Examples allow us to quickly flesh out details and drive out inconsistencies …
Continue reading “Use Examples”
Read MoreSpecify Edge Cases
Another huge benefit of Acceptance Test-Driven Development or ATDD is that it helps us flesh out edge cases, exceptions, and alternate paths for a story to follow. I far prefer to specify edge cases and exceptional paths through acceptance tests rather than with use cases because acceptance tests are more articulate and they are executable. …
Continue reading “Specify Edge Cases”
Read More