![]() Now, that we have our general requirements for the project structure convention, time to go into details. Instead, it should be as simple as breathing. The worst thing a convention can do is to make refactoring so hard and time-consuming that everyone is terrified of it. It should organize things in such a way that refactoring is something that is performed casually on a daily basis. So it becomes very important for our coding convention to not force us to “glue” the code in some permanent place with no way to move it around. And then re-write it completely after a month. ![]() On top of that, we are expected to deliver features fast nowadays. Patterns, frameworks, and best practices are changing constantly. ![]() Last one, but in the modern frontend world, it’s the most important one. Therefore, our coding structure guidelines should provide such a structure, where teams are able to peacefully co-exist within the same repository. The last thing that you want is multiple developers working on the same file, or teams constantly invading each other's areas of responsibility. One of the most important requirements from coding structure guidelines for multiple people, and especially multiple teams, is to solidify a way for developers to operate independently. In the perfect world, same as with code comments, you wouldn’t even need to write it down anywhere - the code and structure itself would be your documentation. For the convention to actually work, it should be so obvious and intuitive, so that people in the team ideally are able to reverse-engineer it by just reading the code. The fact remains: most people are not going to memorise every word of it, if at all. You can probably even convince everyone on the team to read and watch it (although you probably won't). You can write a book and shoot a few movies on “The way of working in our repo”. If the way of working in your repo requires a PhD, a few months of training and deeply philosophical debates over every second PR… Well, it’s probably going to be a really beautiful system, but it won’t exist anywhere other than on paper. ReplicabilityĬode convention should be understandable and easy enough to reproduce by any member of the team, including a recently joined intern with minimal React experience. What I want to talk about a little bit though, before jumping into solutions, is what makes a project structure convention great. I don’t want to go into details on why we need conventions like this in the first place: if you landed on this article you probably already decided that you need it. What do we need from the project structure convention Just remember, same as the Pirate’s Code, all of this is more what you'd call "guidelines" than actual rules.
0 Comments
Leave a Reply. |