Comparison
Branch by abstractionvsSeam
Branch by abstraction
you put an interface in front of the old code, added the new one behind the same interface, and switched with a flag.
Making a large change on the main branch by introducing an abstraction over the existing implementation, building the replacement behind it, and switching over. It exists because the alternative — a long-lived branch for a big migration — reliably ends in a merge nobody can review. The abstraction is temporary and should be removed once the old path is gone, which is the step most teams forget.
Full entry →Seam
you needed to test the payment path and there was nowhere to slip a fake in without editing the code you were testing.
A place where you can change behaviour without editing the code at that place — a parameter, an interface, a configuration point. Seams are what make legacy code testable, because they are where a real dependency can be replaced with a fake. Finding or creating a seam is usually the first move when changing code nobody dares touch, and the absence of seams is exactly what makes such code frightening.
Full entry →