Passionate about building great technology and connecting with people to create positive change. Happy to answer questions about transitioning to tech. Find me on Twitter @lounecl
This is a great and thoughtful approach. I will try spending more time away from the code, rather than just diving in. When working in a much larger codebase, how do you factor that in your solution design?
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
My preferred approach, having got a decent understanding of where behaviour is well-defined, and where it might need to adapt, was to identify boundaries in the existing codebase/deployment (processes/VMs/etc.) architecture where the behaviour is contained (if anywhere!), then isolate those through application of the strangler pattern, to draw out a set of behaviours into a modular feature that can adapt more independently. If behaviour that requires change is very distributed, then we worked on drawing that together first, by applying facades / anti-corruption adapters in areas that connect to the behaviour, then making the changes to the behaviours as required (now in one place). This is an application of Kent Beck's 'first make the change easy, then make the change' :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a great and thoughtful approach. I will try spending more time away from the code, rather than just diving in. When working in a much larger codebase, how do you factor that in your solution design?
Welcome to re-engineering legacy products :)
My preferred approach, having got a decent understanding of where behaviour is well-defined, and where it might need to adapt, was to identify boundaries in the existing codebase/deployment (processes/VMs/etc.) architecture where the behaviour is contained (if anywhere!), then isolate those through application of the strangler pattern, to draw out a set of behaviours into a modular feature that can adapt more independently. If behaviour that requires change is very distributed, then we worked on drawing that together first, by applying facades / anti-corruption adapters in areas that connect to the behaviour, then making the changes to the behaviours as required (now in one place). This is an application of Kent Beck's 'first make the change easy, then make the change' :)