|
I sencond Working With Legacy Code. A lot of advice comes down to writing tests so you don’t break existing functionality. You should write a lot of tests, particularly high level stuff that tests the entire system because with tightly coupled systems you’ll modify part A but part Q will break. Integration level tests help find this stuff out. You have two problems on your hand. One is understanding what the code is doing from a technical perspective but another is understanding the business rules. If you haven’t already, get a high level view of the system. Maybe it can be divided into 4 chunks, and chunk 1 can be broken down into 8 components, etc. Then start documenting the different components in the codebase. Try to understand what the different components do — how are they called, what’s the input, output, do they mutate objects, etc. Once you have a road map you search for “seams” where you can break things apart. Maybe component A, B and C are tightly coupled, but you can split A into two parts — A1 and A2 — and write something that encapsulates all of them (A1, A2, B, C) pinto a cleaner interface. Try to write wrappers that use existing code, then you can have higher confidence that behavior isn’t changing. If you rewrite low level components there’s no telling what the side effects may be. Lastly, learn the language well. I work on a similar code base but it’s in Python. Knowing “advanced” features of the language has helped. Often a lot of boiler plate code can be eliminated by an advanced language feature. By knowing the “seams” of the system and the language you can bend the system to your will. |