this post was submitted on 21 Jan 2024
23 points (100.0% liked)

Web Development

68 readers
2 users here now

Welcome to the web development community! This is a place to post, discuss, get help about, etc. anything related to web development

What is web development?

Web development is the process of creating websites or web applications

Rules/Guidelines

Related Communities

Wormhole

Some webdev blogsNot sure what to post in here? Want some web development related things to read?

Heres a couple blogs that have web development related content

CreditsIcon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
 

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

top 6 comments
sorted by: hot top controversial new old
[–] jjjalljs@ttrpg.network 20 points 10 months ago (1 children)

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

[–] Rokin@lemm.ee 9 points 10 months ago

I agree, code review is the proper solution here

[–] MajorHavoc@programming.dev 13 points 10 months ago

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

[–] 0xCAFE@feddit.de 10 points 10 months ago

Should I approach the team about this?

Yes, certainly. It sounds like some/most members of the team don't understand the stylesheet architecture of your project and it's vital to sort that out ASAP. The more time passes, the harder it will get to get everything back on track.

Try to avoid finger-pointing and this shouldn't be a very hard conversation (assuming they aren't super stubborn).


As a side note, the fact that you first address this issue on the Fediverse and not in your team makes me think that maybe there are some underlying issues regarding trust and open communication. You might want to further look into that. Take it with a large grain of salt though. I don't really know anything about your team so it's likely that I overdramatize the situation.

[–] mark@programming.dev 2 points 10 months ago* (last edited 10 months ago)

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 😃

[–] aufhohemross@lemmy.ml 2 points 10 months ago* (last edited 10 months ago)

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