Refactoring, Simplicity are applicable in ideal situations, what about the real life? Delivery time & production will most likely not wait for you to complete these steps. These steps I consider as performance upgrades and are to be performed once the initial build without these is ready. So that the teams can move forward and not wait.
Achieving perfection, is the greatest enemy of the developer, as there is no such thing as perfect code. There is always room for improvement. Thus these two rules should be applied sparsely initially. In later builds with time they should be.
This is not something always we can take care of. But with time, instead of spending time over refactoring code, we should learn to write refactored code in the first place.
If suppose Use Cases change and you need to alter the solution, ensure you refactor right away, despite the time factor. Because leaving one broken window in your code base will cause a lot more broken windows as time passes and ends up depletes the quality.
Choosing to postpone the effort to enforce DRY and other similar principles is a choice that must be made based on the project goals. And to be clear: you are postponing the effort, not removing it from the project. Writing sloppy code creates technical debt that is eventually paid for in the slowness of future progress and/or the likelihood of bugs showing up as more changes are made.
Yes, timelines are real. It's also true that you can spend too much time chasing perfection with perfection will never be achieved. But the principles in this article are not about perfection, and there needs to be an understanding of how ignoring them will negatively impact a project in the long run.
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.
Refactoring, Simplicity are applicable in ideal situations, what about the real life? Delivery time & production will most likely not wait for you to complete these steps. These steps I consider as performance upgrades and are to be performed once the initial build without these is ready. So that the teams can move forward and not wait.
Achieving perfection, is the greatest enemy of the developer, as there is no such thing as perfect code. There is always room for improvement. Thus these two rules should be applied sparsely initially. In later builds with time they should be.
This is not something always we can take care of. But with time, instead of spending time over refactoring code, we should learn to write refactored code in the first place.
If suppose Use Cases change and you need to alter the solution, ensure you refactor right away, despite the time factor. Because leaving one broken window in your code base will cause a lot more broken windows as time passes and ends up depletes the quality.
Refer : Broken Window Theory - Programming
Choosing to postpone the effort to enforce DRY and other similar principles is a choice that must be made based on the project goals. And to be clear: you are postponing the effort, not removing it from the project. Writing sloppy code creates technical debt that is eventually paid for in the slowness of future progress and/or the likelihood of bugs showing up as more changes are made.
Yes, timelines are real. It's also true that you can spend too much time chasing perfection with perfection will never be achieved. But the principles in this article are not about perfection, and there needs to be an understanding of how ignoring them will negatively impact a project in the long run.