Only write CSS in CSS files, don’t write JavaScript in your HTML files, and other things like that. Then we got more advanced.
Separating responsibilities in your code is not only a best practice, it will help keep your sanity when you need to find where a problem is originating. There are quite a few specific reasons you want to use this practice and here are a few of them
Testing becomes easier to manage because you can trace through the call stack to find the root of your problem. It’s especially useful when you’re trying to find out if the front-end or the back-end is where you need to focus. When you have to debug your code, it’s a lot better to have a few lines to change in one file than to have to update the same line of code across multiple files.
Speaking of which, separating responsibilities also helps you maintain your code base. When you have a specific folder to hold all of the custom types you need for the outputs of your APIs you can add a new variable without needing to rummage through files. Changing the entire layout of your site can be done without going in every file in the project. That helps you make those big and small changes that come up in any project.
Then there’s code dependency and injection benefits. You’ll be able to see and control where in the code values are used, where those values come from, and how they are handled. If there is data that will be updated in the database that needs to be bound to an HTML element, separation of code lets you deal with those changes securely.
Having separate responsibilities lets you limit how much back-end access the front-end has. By using particular API calls that process the database values before they hit the front-end, you can keep user information protected. You can go even deeper into code separation.
Inside of the API calls you can change the access level of the functions you write. You can also do this on the front-end in JavaScript using the same access modifiers. You can have private functions that can’t be called outside of a class. Most commonly used are your public functions that can be called anywhere the class is implemented.
Separation of responsibilities can be handled in a way that is specific to a project. You can stay as simple as keeping each language in a different file or you can go as complex as writing a different file for every single thing you do. Just remember that separation of responsibilities also gives you a certain level of abstraction. Make sure you aren’t putting too many layers between the actual code and the face you’ve put on it.
It’s a subtle art that you gradually learn over time, but sometimes you aren’t aware that it’s happening. When you’re thinking about how to separate those responsibilities, try to think long-term and big picture. If you see a big feature or something that will potentially need to scale up in the future, go ahead and plan for it.
Learning about the separation of code responsibilities is how you get better at understanding the overall architecture of a web project. Once you learn when to separate responsibilities and you know why you need to do it, you’re one step closer to that coveted senior web developer status.
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding