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 :)
I worked away from the code on modelling the problem to be solved, understanding the domain and the humans that do/will interact with the software.. Then on returning to the weeds, I had a much better view of why code should be structured in particular ways, and when procedural logic was appropriate (it often is for completing well-defined business tasks - do not throw process/procedures away!) or when a more flexible, isolated structured helped with uncertainty, at the cost of complexity of course :)
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.
I worked away from the code on modelling the problem to be solved, understanding the domain and the humans that do/will interact with the software.. Then on returning to the weeds, I had a much better view of why code should be structured in particular ways, and when procedural logic was appropriate (it often is for completing well-defined business tasks - do not throw process/procedures away!) or when a more flexible, isolated structured helped with uncertainty, at the cost of complexity of course :)
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' :)