I was recently tasked with rewriting the base CSS for an inventory/project management system, creating a set of reusable components designed to match, using an open/close approach. These were based on a pretty strict specification provided by one of our designers, who unfortunately left.
The implementation went well, but I've run into a bit of a problem. Quite often the team members make changes directly to the base class in the new base CSS file, rather than extending it, creating a new one, or using each system area's dedicated stylesheet file.
One of the more recent changes involved removing a grid-gap property from a rule from the base CSS, affecting a lot more than the single UI element the team member was working on.
Should I approach the team about this?
I haven't mentioned anything yet, but have noticed our QA team putting in more bugs about UI elements looking odd
That sounds like a pretty straight forward and simple conversation.
Do you do code reviews? Have code owners? If you (or a set of people you trust) were required to sign off on changes on the base files that aren't supposed to be changed willy-nilly, you could catch it before it went to main
This sounds like a job for a team wide code review process.
If you don't say anything, it won't get better. Up to you whether that's worth the hassle, based on your team and your situation, of course
You can keep bringing it up. But, in my exp, if you dont have anyone high up that can support your perspective, it's just gonna be an uphill battle. And is likely just going to make the other devs unhappy with you.
It's unfortunate but most devs dont really like anything that's going to cause them more work (e.g. more code reviews, higher quality changes, looking at the bigger impact of their changes etc).
If you don't have someone higher up —maybe the manager of the managers of those problematic engineers—I'd just make more tests around the areas that are breaking and require those tests to pass before merging code changes. Devs may not like to work harder, but they damn sure dont like seeing a bunch of red X's when they open a PR lol 😃
I think this can be resolved with code review (as others have mentioned), but there's also a lack of understanding on how to use the components you have created. Maybe a quick email politely explaining the theory/approach behind these base classes, with some examples of do-s and don't-s could work alongside code review to enforce the change
