Front end guidelines
This kind of follows on from Heydon’s article about writing code in big teams. Brad is embarking on a new project with a team of developers and they’re doing something out of left field to start with…. they’re talking to each other (weird right?). Before starting anything they set up a series of ‘rules’ for how to build the site, and then try applying those ‘rules’ to a small module to see if everyone has the same idea about what the rules mean. They don’t. This is a perfect time to realise this in a distributed team… BEFORE you start the project. A few iterations on this approach and everyone will be singing from the same hymn sheet.
Before starting anything they set up a series of ‘rules’ for how to build the site, and then try applying those ‘rules’ to a small module to see if everyone has the same idea about what the rules mean.
They don’t. This is a perfect time to realise this in a distributed team… BEFORE you start the project. A few iterations on this approach and everyone will be singing from the same hymn sheet.
Brad also awesomely put the guidelines up on Github.
The nascent frontend guidelines should be updated based on the reviews and discussions around the exercise. Your frontend guidelines can and should be referenced, revisited, and revised throughout the course of the project.It should be an evolutionary, living thing rather than a static file that doesn’t truly represent the way the team is writing code.
An excerpt from Front end guidelines
