This is a follow up to my previous question that was flagged as a duplicate, and I do not know what would work better as the title.
Here is a link to the previous question: Legacy code: what to do in regards to maintenance and moving forward?
And the link to the proposed duplicate: What is the most effective way to add functionality to unfamiliar, structurally unsound code?
Here are some brief points from the discussions and answers of the original question:
- Premise was to discuss maintaining and modifying legacy code
- the legacy code is in a way where many of the object are quite large and bridge heavily into the idea of God objects; Performing functionality on numerous entities and coupling them in a way that has proved difficult to add or define/pull out some use case
- The main arguments were being consistent with the legacy code ideas of an object vs. making something new (in terms of modifying existing code or new code)
- Team-wise there is no architecture, and the healthy discussions around the eventual goal are not happening
- The development process is more reactive than anything else, so the idea of dealing with legacy code as a team changes constantly
- From a sort of professionalism/management chain perspective, there was a lot of feedback simply because this area ended up being the overall root problem in my actual environment
I do want to give due diligence in discussing the software side of the problem, since that was the intended purpose of the way I tried wording the previous question. (The separation and wording is mainly myself being green and attempting to be vague, so that I am not talking specifics)
Now addressing the duplicate in respect to my question, I do see where this is a valid duplicate, but I am unsure about how to implement the selected answer. The summary that I gather is, "For smaller changes, then stay consistent. For larger changes, take the opportunity to refactor the area affected by the request. Do not refactor without a reason that is in line with some request from a work item, user story, etc."
For my scenario, I get lost on how to implement/incorporate the answer when it comes to tightly coupled functionality that came about (deployed as production code) unintentionally or requirements previously may have had them tied together. Other than the code base, there is a lack in documentation on business rules and many of the previous requirements.
As for consistency or refactoring as a discussion point in the development process, how does that answer apply when the new/modified functionality changes or breaks existing functionality that is not part of the request?
To me, it feels like the scenario lends itself to something like the Open/Close Principle, but I do not know if the code base is in a state that can support the principle well enough (testing, documentation, etc.). So my idea of any takeaway discussion points, could be centered around the God object and defining if the thing being open/close is the God object itself or some grouping of functionality defined as logical objects.
My understanding of the principle - the previous functionality is Open until the new piece is made, then the previous functionality can/should be closed. (Not too sure if I am grasping the idea of that principle correctly)
I am trying to be careful with my wording, so please feel free to request/do an edit that makes more sense. I do have a sense that I am wording things like I want to ignore the management/leadership piece, and that could make the content unclear. For an answer, I am looking at this question from a development/developer/programmer perspective, so that I could get an understanding of the possible role(s) developers play in this scenario, in respect to weighing in their opinions/ideas.
As previously stated, my original question has already branched out on the management/leadership side to this scenario. This separation that I am pushing could stem from being green/new and not having a grasp on if these pieces can/cannot be separated.