I have a few questions for those of you who work as, or work with, front-end/UI developers (your role is writing markup, CSS and JS) in medium to large Web development teams with a back-end/front-end split.
I'm curious because the last two questions are something I've not been able to answer effectively. I've always worked in UI teams of 2-3. Back-end code is fairly easy to parallelise - changesets are usually small, discrete and across many files, and thus easy to merge and keep under control. But UI work usually involves many small changes in a couple of big, intricate files that makes merging a nightmare - line-by-line diff tools are not really the friend of CSS.
CSS is especially problematic. Writing CSS well means using the cascade effectively. But with many developers it's very difficult to manage. !important rules start appearing everywhere, styles get duplicated and lengthy selectors get written to override code elsewhere. This means the cascade becomes meaningless and code bloats massively.
Is it better to:
Apologies for the mind-splurge. Really I'm just looking for some ideas on how to make larger front-end teams work, as that's the way things are moving for me. I'm not so confident they do if you want to maintain standards, which is why I'd like to hear some of you say "yes, they do!", or perhaps throw out some ideas about how we front-end developers can maintain an efficient workflow when other front-end developers are [getting in the way] working with us.
- How many other UI developers do you work with?
- How many other devs -back-end/qa/etc.- do you work with?
- Do you think there's a limit to the size of the UI team within a development team?
- How have you found it best to manage working on front-end code in parallel?
I'm curious because the last two questions are something I've not been able to answer effectively. I've always worked in UI teams of 2-3. Back-end code is fairly easy to parallelise - changesets are usually small, discrete and across many files, and thus easy to merge and keep under control. But UI work usually involves many small changes in a couple of big, intricate files that makes merging a nightmare - line-by-line diff tools are not really the friend of CSS.
CSS is especially problematic. Writing CSS well means using the cascade effectively. But with many developers it's very difficult to manage. !important rules start appearing everywhere, styles get duplicated and lengthy selectors get written to override code elsewhere. This means the cascade becomes meaningless and code bloats massively.
Is it better to:
- Work with a CSS framework to put all the initial work in place
- Ignore the cascade, and write completely new styles for each new feature of a site
- Do you split CSS into separate files to make management easier?
- Be incredibly anal and rigid about coding standards - stick religiously to a style guide?
- Split people into separate markup, css and js roles?
Apologies for the mind-splurge. Really I'm just looking for some ideas on how to make larger front-end teams work, as that's the way things are moving for me. I'm not so confident they do if you want to maintain standards, which is why I'd like to hear some of you say "yes, they do!", or perhaps throw out some ideas about how we front-end developers can maintain an efficient workflow when other front-end developers are [getting in the way] working with us.