The Offspring made a whole song about it, so you know it's important. You gotta keep your concerns separated in your code.
Sounds simple, right? In pseudocode, that would be something like: just, uh, track down each of your concerns, put them in separate corners of the room, and tell them sternly to "stay put." Maybe waggle your finger at them for emphasis.
A lot of people on the wonderfully wide web of the world will tell you that separation of concerns means things like, "Keep your HTML, CSS, and JavaScript separate." Other folks say, "Keep your business logic and your presentation logic separate" (which basically means: have one place where you keep code for stuff that appears on the application and another place for stuff that doesn't appear on the app and is for internal processes, like processing credit card payments or keeping up with employee hours). And then other people--who like to frustrate you with their subtlety--might say something like, "Make each piece of your code do one thing and one thing only," which sounds pretty unrealistic.
The fact of the matter is, the definition of separation of concerns varies wildly depending on who you're asking. But, there's hope! If we rethink ˆhowˆ we're thinking about this, we might find a more useful conclusion.
Let's tackle it like this:
- what are "concerns"?
- what's our goal with separating them?
- how do we separate them to meet that goal?
The answer to number one is going to depend on what your project is. No easy way to give a cookie-cutter answer for this; your "concerns" are delineated by the nature of your specific probject. It might help to think about it in terms of number two: what's our goal with separating these concerns? Our primary goal, the reason for the season of separation, is that our tiny human brains can't hold a lot of info at the same time. Anyone who's ever tried to follow a string of logic through a dozen different files, all named similarly, with multiple functions using multiple callbacks (also all named similarly) knows that this kind of thinking is slippery. We want to separate the concerns to make it easier to follow the logic and think through what's happening--both for ourselves and for anyone else who might ever have to read or change our code later.
If we break up our concerns into smaller problems, our brains can more easily keep track of them. When you consider the problem from this angle, does it necessarily make the most sense to separate based on HTML, CSS, and JS? Maybe not. It might be more reasonable to isolate bits of logic into consumable chunks that try to answer just one problem at a time. (That sounds like it might be closer to what they mean by "Make each piece of your code do one thing and one thing only").
Another reason we separate concerns is so that if we need to change/fix/add to/delete any part of our application, we can just go to that one part and tinker with it, instead of having to mess with all the code and possibly inadvertently break something else we didn't even mean to touch. Again here, I'd suggest that if you, for instance, were tasked with adding something to an application, even if you had your HTML, CSS, and JS separate, you'd still have to visit all three to add your new feature. So maybe a better way to separate is to keep each functional element isolated in the code. Maybe even--dare I suggest it--have your JS and HTML a little mushed up, as in JSX in React?
My favorite reason for separation of concerns, though, and one that argues against everything I just said above, is that when tasks are separated into HTML, CSS, and JS, it lets people specialize and become experts in one area. If one team member is really good at CSS while another is cozy with JS, if those parts of the code are separate, they can divide the tasks, do what they're best at, and conquer all.
In the end, there isn't a clear answer for how to go about separating concerns, but it is clearly important to think about and to try to do. There are a lot of growing, changing, evolving ideas about it, and that's part of what keeps the job exciting.
Top comments (0)