| Based on my years of experience in working with a millions-of-locs over decades codebase: Be aware of the abstraction fallacy: developers are often guided by this insane notion that they can get rid of accidental complexity by wrapping it away behind an abstraction layer. You can't. It's better to suck up to the complexities of the existing system, and prefer explicit, procedural copy-and-pasting than trying to invent your own abstraction layer on top. The problem with the after-the-fact abstraction layer is that if the original team members are not available, you are likely not in possession of the whole theory of the software. Hence it is not likely you can in the beginning choose the right abstractions. The correct way - if possible - to simplify existing code is to refactor the code itself. The specific anti-pattern you will reach by following the false abstraction strategy is the lasagna architecture:
https://herbertograca.com/2017/08/03/layered-architecture/ Two literary works that helped me enormously to grok working with legacy code and programming in particular: * Peter Naur's paper "Programming as theory building" - this was an amazing eye opener to me. It specifically highlights several problems that may arise when working with legacy code when the original developers have left the building. * Michael Feathers: Working Effectively With Legacy Code - not to be read necessarily as a "how to" recipe book, but rather as a collection of philosphies and techniques to utilize when faced with a huge in-production codebase. It can be read as a recipe book if the examples match your situation, but that's not the point. |