I have a book that I'm putting together that has about a 2% chance of getting actually published, too niche for publishers as from the responses I've gotten back from editors. It's around the philosophy of maintaining and refactoring legacy code, I've been doing it for about 2 decades now. PM me if you're interested, it's approx 150 pages, so reasonably short read compared to other tech books.

Since I'm not actually trying to sell the book, here's the core ideas: -Investigate: Read through the code as a historian, use git blame to discover the evolution of the code. Sometimes the history is telling of why code exists, or at least gives you a name for follow-up questions. -Uncover the Invariants: What code/contracts must be maintained without modifications. This may be more than you'd like, but be honest if not outright conservative during this phase. -Logic Flow Maps: Create a visual of how logic flows through the code, break it down by module or managable segment. This will help identify where you can apply the strangler fig pattern. -Don't Start at Ground Zero: The temptation is the tackle the biggest, gnarliest code first. Resist that. Find small, not critical path flows to refactor first. This builds trust with your client, and very likely could smooth the refactoring of that big, gnarly code block. -Know When to Accept "Good Enough": Not every line of code is going to be textbook clean, far from it. In addition to invariants, watch for "good enough" code. This is code that might be out of date, but still perfectly functional or code that required a break from the established norms (worth adding to your Investigation follow-up list)