Update modular-code.md #95
Conversation
Erin, Tim & Keerthi revised various sections. Team - please review!
|
I changed the headline formatting of this file as part of #131. So if that branch get merged, we will likely see a bunch merge conflicts with this branch. |
|
Oh well - this PR is nearly two years old 🤷♂ |
lenucksi
added
the
2-structured
ErinMB
requested review from
cewilliams,
gruetter,
lenucksi and
nyeates
as code owners
|
I've merged the |
|
Great! Will take a look. |
|
None of my discussions are resolved. I already signed off, though. I don't think that my comments should block merge. |
patterns/1-initial/modular-code.md
Outdated
| * Might be a fear that if not done properly, quality might be impacted. | ||
| * Developers might not have incentive to write modular code (due to their tight schedules and lack of a mandate). | ||
| * You might be dealing with legacy systems (can't be simply refactored or rewritten). | ||
| * Requirements might be different for writing modular code. | ||
| * Architectural constraints might impact modularity. | ||
| * Developers who develop monolithic code bases might lack the perspective of how modularity might improve how they work. | ||
| * If there is frequent turnover of team members, modularization may not be a priority. |
There was a problem hiding this comment.
Just to clarify: modularization might not be a priority for developers, if they think they are going to leave the team, soon? I would argue it's definitively a priority from an organisations perspective, because modular code should be more understandable and maintainable and that in turn helps when new team members are onboarded.
There was a problem hiding this comment.
WDYT, @MaineC and @NewMexicoKid ?
| * Might be a fear that if not done properly, quality might be impacted. | ||
| * Developers might not have incentive to write modular code (due to their tight schedules and lack of a mandate). | ||
| * You might be dealing with legacy systems (can't be simply refactored or rewritten). | ||
| * Requirements might be different for writing modular code. | ||
| * Architectural constraints might impact modularity. | ||
| * Developers who develop monolithic code bases might lack the perspective of how modularity might improve how they work. | ||
| * If there is frequent turnover of team members, modularization may not be a priority. | ||
| * Level of communication between teams can impact ability/inclination to modularize. |
There was a problem hiding this comment.
I believe this also needs some clarification.
There was a problem hiding this comment.
Given that this PR is open for 2.5 years already, I suspect that it might not have a shepherd any more. 😢
Therefore my suggestion would be for anybody of any Trusted Committer here that is still part of the conversation to resolve the comments to the best of their knowledge, and then merge the PR.
That way we capture at least some of the value that this PR, without keeping it open for an unnecessarily long amount of time.
Once the PR is merged, others can take this pattern forward, as it is currently still in "Initial" state i.e. a pretty immature pattern anyways.
Co-authored-by: Sebastian Spier <github@spier.hu>
Co-authored-by: Sebastian Spier <github@spier.hu>
Co-authored-by: Sebastian Spier <github@spier.hu>
lenucksi
added
📖 Type - Content Work
There was a problem hiding this comment.
This looks fine to me for its current placement in 1-initial.
Looking for a reaction to @gruetter's review comments in #95 (review) by @NewMexicoKid and @MaineC and will then merge once those are resolved.
Co-authored-by: Sebastian Spier <github@spier.hu>
|
I worked in most of the feedback from this PR, and left the threads open that I could not resolve myself. Even though there are open questions from @gruetter I am merging this PR now, as it already contains a number of improvements over the pattern currently in the mainline. |
Erin, Tim & Keerthi revised various sections. Team - please review!