This fall, my team started a new project and for the first time in a long while, I was working with another developer as I started to write the styles for the interface. In fact, I started the styles, and then went on vacation while they took over.
This project has been an exercise in writing modular CSS, which I love, when working in a team. Having been a solo front-end developer for quite some time, this was a new challenge to me. When you want your CSS to be reusable, how do you have several people working in git branches on different pages without writing completely separate styles?
Surprise: it’s not really about how we write CSS, it’s about the process.
Communication
Communication is the biggest piece of making this work. As we work throughout the day, we talk about the styles we’re writing and where they might be used across the application, so the other person knows how work in progress could impact the parts of the application they’re focused on.
For example, if I change a wrapper to meet the new design spec and want to be consistent across the entire application, I mention that it’s been changed, what’s changed about it, and the branch where I’ve done this. When my coworker normalizes buttons in one branch, they let everyone know that this will be taken care of for the whole team when that branch gets merged into the master branch.
Code review
I’ve worked on teams that did code reviews, but my current team didn’t always do them as we worked. As the team grew, we decided to incorporate code reviews into our process. The best part of a code review is learning from each other. Maybe the way I’ve done a layout works, but could it be better? Are there styles I’m not familiar with that would make it better?
When we review code, we discuss our modules to ensure everyone agrees they’re going to be the best way to move forward. When talking through how to use SVGs in our code, for instance, we discuss when it’s appropriate to use them as background images as opposed to images, or inlining them by putting the SVG code right into the template.
Documentation
Finally, we came up with what’s important to our team when writing CSS and we documented that. We use the ideas from Jonathan Snook’s SMACSS to guide us, along with explaining features of Sass we want to stay away from (such as nesting), so the entire team has an easy reference.
By making this explicit, we can refer back to it for reminders as we review code. In the near future, we also hope to build a style guide to further document our work. That way, we’ll have documented how we want the code written, and we’ll have a more visual documentation of the styles we’re using to retain consistency as we continue working on the application.
As a team grows there are always bumps along the way, but it’s been a great challenge to start documenting our process, thinking about how we write CSS in a more formal way, and reviewing it together to make sure we’re all on the same page. For me, the challenge of going from being the only person writing everything, to adding new team members and working together, has been fantastic.
Source: A List Apart: The Full Feed