I've been coding for more than 15 years now. I've worked on many different technologies and tryied some different patterns. I always find struggling with the code when the project reach some level of complexity and size. No matter if using MVC, modules, components, event driven. At some points and as soon projects need evolution during the time, it gets messed up in some way.
During the years I've seen that the more design at the beginning the longer it keeps neat, but at some point always get messed up in some way.
I don't mean totally uncontrolled code, or unreadable one, but it's hard to know what parts interacts with each other, what code is related in some manner to another one, ...I always find myself wanting to refactor the project almost from scratch.
I'd like to have an honest opionion from your experiences and if you really find a way to keep the things totally under control.
Is always design before already code the main reason to keep your code clean?
Did you find your tool/framework that sincerely allows you to keep it neater?
Thank you!
Top comments (7)
Large apps will always be hard to navigate - just because they are big...
All apps will get messy over-time too. I think the key is to write your apps as simple as possible (which sometimes does require a complex strategy) and in a way that individual pieces are easy to replace.
That's why I prefer to avoid sharing code as much as possible. That way, most parts of the app are isolated and can be replaced without affecting other parts.
Using something like Clean Architecture or something like a vertical slice architecture really helps.
Thank you James,
When you reffer to avoid sharing code, do you mean sharing code between modules in the same app, or not code shareable code in mind for future projects?
Does it means that is better to write two almost identical functions in two modules to not share between both or not to use a module for common functions?
I'll take a look to your link!
Thank you!!
Generally, I mean sharing code between modules or assemblies, etc.
At face value that might sound strange to many, but I've seen this hinder large projects because they are all coupled together due to these shared "common" libraries.
This is what something like microservices totally avoids - which is one of the main reasons these services are easily replaced, etc.
When using PHP, I consider how I can split a large codebase into smaller libraries or packages using Composer, where each package performs a specific task. That way you make it more maintainable as well as reusable for other projects.
You can do the same with JavaScript, making use of npm to store your JavaScript libraries and packages.
Thank you C.S. Rhymes!
This seems a good idea. I recently discover that you can create your own npm packages easily. I will dive into it! Thanks!
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!