Good points. I think documentation is a very important thing here to keep consistency over time. I usually find myself mantaining 3 or 4 projects at a time, and it's hard to be focused on each one, and knowing exactly what was the approach on every one. The projects were developed in different times, and used what seemed the best approach at that moment. It's like writing 3 novels at a time and you have to remember which style are you using on every one. I'm using 1st person in one novel, but 3rd person in the other one.
In my case, I work on projects that applies to some clients, and each client needs its own customization. When applying to new client you need to do some adjustments to fit that needs, but keeping in mind to mantain the codebase clean and not mess up the other clients need. Time is usually a big enemy. As soon as you make bad decisions on your code sets a dangerous tipping point from there.
Documentantation it's a key point for the general structure as well. One of my main problems when back to one project is to understand/remember what was related to what and its internal relations.
Code reviews seems important too. For small teams and few time available it's hard sometimes to set a slot for this. Maybe I'd should set more priority on those.
Thank you for sharing your thoughts!
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.
Thank you Casey!
Good points. I think documentation is a very important thing here to keep consistency over time. I usually find myself mantaining 3 or 4 projects at a time, and it's hard to be focused on each one, and knowing exactly what was the approach on every one. The projects were developed in different times, and used what seemed the best approach at that moment. It's like writing 3 novels at a time and you have to remember which style are you using on every one. I'm using 1st person in one novel, but 3rd person in the other one.
In my case, I work on projects that applies to some clients, and each client needs its own customization. When applying to new client you need to do some adjustments to fit that needs, but keeping in mind to mantain the codebase clean and not mess up the other clients need. Time is usually a big enemy. As soon as you make bad decisions on your code sets a dangerous tipping point from there.
Documentantation it's a key point for the general structure as well. One of my main problems when back to one project is to understand/remember what was related to what and its internal relations.
Code reviews seems important too. For small teams and few time available it's hard sometimes to set a slot for this. Maybe I'd should set more priority on those.
Thank you for sharing your thoughts!