In my opinion there are no absolutes when it comes to stuff like this, every project will require different levels of refactoring depending on a myriad of different variables, some of them out of your control (third party API changes etc.). Some projects may be more 'set it and forget it' in that they may perform without ever requiring refactoring.
As for my opinion on scheduling refactoring, I feel like at the start of a project if you spend more time with technical planning (mapping out database tables, deciding on an approach as well as language and framework etc.) and some pair programming this can really help nail a solid code base which won't be littered with // TODOs. In theory this project will require less refactoring than a project that has been planned and developed by a single developer whilst rushing and skipping code reviews etc.
If you are inheriting a project then I would certainly budget some time in for refactoring. If a project needs significant refactoring I may suggest a refactoring sprint or something similar where we focus on refactoring the required code and stop any new features temporarily. If a codebase doesn't need that level of refactoring but could benefit from a refresh then I would just budget that in with each issues estimate, for example if I estimate 3 hours to solve a task I would say 4 hours to give me an opportunity to refactor some of the portions of code this issue also touches or relies on.
Obviously all of the above is in an ideal world where clients are happy to pay for refactoring time and understand that it should benefit their business in the long term. Unfortunately this isn't always the case and sometimes as developers we do just have to work with what we have and push through and ensure our code is as robust as possible despite the sub-par code we may be encountering.
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.
In my opinion there are no absolutes when it comes to stuff like this, every project will require different levels of refactoring depending on a myriad of different variables, some of them out of your control (third party API changes etc.). Some projects may be more 'set it and forget it' in that they may perform without ever requiring refactoring.
As for my opinion on scheduling refactoring, I feel like at the start of a project if you spend more time with technical planning (mapping out database tables, deciding on an approach as well as language and framework etc.) and some pair programming this can really help nail a solid code base which won't be littered with
// TODOs. In theory this project will require less refactoring than a project that has been planned and developed by a single developer whilst rushing and skipping code reviews etc.If you are inheriting a project then I would certainly budget some time in for refactoring. If a project needs significant refactoring I may suggest a refactoring sprint or something similar where we focus on refactoring the required code and stop any new features temporarily. If a codebase doesn't need that level of refactoring but could benefit from a refresh then I would just budget that in with each issues estimate, for example if I estimate 3 hours to solve a task I would say 4 hours to give me an opportunity to refactor some of the portions of code this issue also touches or relies on.
Obviously all of the above is in an ideal world where clients are happy to pay for refactoring time and understand that it should benefit their business in the long term. Unfortunately this isn't always the case and sometimes as developers we do just have to work with what we have and push through and ensure our code is as robust as possible despite the sub-par code we may be encountering.