Harry Roberts talks about some methods for getting comfy with a new ("specifically CSS") code base. Harry's done this a lot as someone who parachutes into new code bases regularly as a consultant. But I think this is also quite interesting for people starting a new job. So much web development work is working on existing sites, not green fielding new ones.
Code reviews are a big part of writing software, especially when working within a team. It is important to have an agreed-upon etiquette for reviewing code within a team. A code review is a critique and a critique can often feel more personal than the code writing itself. A sloppy, under-researched, or insensitive code critique can cause difficulties between team members, reduce overall team productivity, and diminish code quality over time. This post will briefly define code reviews, describe some common mistakes, and provide some quick tips for improving a code review process.
I recently did an experiment where I created the same vector illustration in three different applications, exported the illustration as SVG in each application, then wrote a post comparing the exported code.
While I loved the banter and insights that came in the comments, I was surprised that the bulk of conversation was centered on the file size of the compiled SVG.
GitHub has improved their code reviewing tools:
Effective code review catches bugs before they’re deployed, improves code consistency, and helps educate new developers. We’re adding new features to make code review on GitHub faster and more flexible.
A few include a handy timeline indicator showing what you might’ve missed after reviewing a pull request, and a way to filter filters in a pull request by type (e.g. maybe you just want to look at the CSS files).