A key thing I've come to grips with recently is that any sufficiently large project is going to have messy code in it. But that doesn't necessarily mean it's a messy codebase.
The key is to try and keep the core architecture clean enough that smaller, messy modules don't impact anything else. Part of this is definitely starting from a good foundation, but even without that you can have a "clean" codebase, and this alone doesn't make your codebase clean. What makes it clean is doing work to ensure that the core architecture stays clean, refactoring that core logic and "happy path", giving it good interfaces, documentation, etc.
Code reviews are really important here, and the one(s) giving reviews needs to stay strong and not compromise the quality of the core architecture for a quick fix. Getting a new feature or bugfix out the door is not a good enough reason to be significantly changing that core layer or not properly using the abstractions in place. Every PR doesn't need to be the best code ever written, but it should at least be written in the right files and behind the right interfaces so that it can hide a lot of the mess.
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.
A key thing I've come to grips with recently is that any sufficiently large project is going to have messy code in it. But that doesn't necessarily mean it's a messy codebase.
The key is to try and keep the core architecture clean enough that smaller, messy modules don't impact anything else. Part of this is definitely starting from a good foundation, but even without that you can have a "clean" codebase, and this alone doesn't make your codebase clean. What makes it clean is doing work to ensure that the core architecture stays clean, refactoring that core logic and "happy path", giving it good interfaces, documentation, etc.
Code reviews are really important here, and the one(s) giving reviews needs to stay strong and not compromise the quality of the core architecture for a quick fix. Getting a new feature or bugfix out the door is not a good enough reason to be significantly changing that core layer or not properly using the abstractions in place. Every PR doesn't need to be the best code ever written, but it should at least be written in the right files and behind the right interfaces so that it can hide a lot of the mess.
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!