Loosely related to this, how would you approach this situation Jason:
We decided to use a certain design pattern, but now we realize we need to shift the approach, perhaps add a constraint we did not have before. Maybe we were not using the pattern correctly at first, or we have a new vision on our needs.
Do you try and update all the existing code right away? Do you start writing the new code under the new approach and try to update the old stuff as you go? How do you discuss this with the team and share knowledge about shifting design guidelines?
I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
Ideally, you wouldn't have decided on a design pattern upfront. Instead, you would have deferred the decision until you felt the pain and at that point realized the appropriate design pattern.
In the real-world, I understand this isn't always possible. So, given you have chosen a design pattern and have now found it's not the right one, I would swap it out. Nothing is sacred.
If code you have written no longer fits, don't be afraid to replace it throughout the code. If it works mostly and needs adjustments, practice YAGNI and do the simplest thing that could possibly work (you mentioned adding a constraint).
YAGNI is just one principle of extreme programming. Unless accompanied by lean process it can be jarring. So definitely be sure there is a way to share these sweeping design decisions. So long as there is, they shouldn't be feared.
Feel free to get more specific. I love this stuff…
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.
Loosely related to this, how would you approach this situation Jason:
We decided to use a certain design pattern, but now we realize we need to shift the approach, perhaps add a constraint we did not have before. Maybe we were not using the pattern correctly at first, or we have a new vision on our needs.
Do you try and update all the existing code right away? Do you start writing the new code under the new approach and try to update the old stuff as you go? How do you discuss this with the team and share knowledge about shifting design guidelines?
Ideally, you wouldn't have decided on a design pattern upfront. Instead, you would have deferred the decision until you felt the pain and at that point realized the appropriate design pattern.
In the real-world, I understand this isn't always possible. So, given you have chosen a design pattern and have now found it's not the right one, I would swap it out. Nothing is sacred.
If code you have written no longer fits, don't be afraid to replace it throughout the code. If it works mostly and needs adjustments, practice YAGNI and do the simplest thing that could possibly work (you mentioned adding a constraint).
YAGNI is just one principle of extreme programming. Unless accompanied by lean process it can be jarring. So definitely be sure there is a way to share these sweeping design decisions. So long as there is, they shouldn't be feared.
Feel free to get more specific. I love this stuff…