A few tips for coding with several people

What does it mean to code with several people? As developers, you're geeks who work alone from home, aren't you?

Well, not quite. In fact, if we just coded alone, we wouldn't get very far as developers. Helping each other and working together are the pillars of the IT world.

So today we're going to take a look at the main forms that exist, and why they're useful in your apprenticeship or career as a developer?

Peer-programming

One of the best-known and most natural forms of mutual aid and joint "coding" is peer programming. Behind this Anglicism is simply the principle of 2 people (mainly) coding on the same computer.

One of the developers takes on the task of writing the lines of code, while the other supervises, guides and advises.

As you can imagine, this practice is not very widespread in the corporate world, for the simple reason that it gives the impression of paying 2 people to do 1 job...?

On the other hand, between friends, and especially between developers, it's a relatively common practice, and a good way of discovering tips and new technologies.

Of course, it's not 2000 any more, so pair-programming can also be done remotely, by video, chat or anything else you like. There's no need for everyone to sit down at the same workstation!

Versioning and branches

Ah Git! Here it is again. If you haven't yet read my previous articles on it, I invite you to do so here and here?

But what can this little tool enable several of us to do?

Well, a lot. So far, I've talked about it in the context of solo use, but if one day you find yourself having to develop a project with 2, 3 or more people, it's really going to come in handy.

Versioning

You already talked about this in the other article!

Yes indeed, but what I want to make clear here is that versioning really comes into its own in a multi-partner project.

Imagine a morning at 9 a.m. (yeah, we're not going to get up early just yet), you switch on your machine and start coding on project X (not the film). It's great, you make good progress all day long and by evening you're proud of your work.
But in the meantime, your colleague Michel has also been working all day on project X (still not the film). How are you going to update the project at the same time without one person's work taking precedence over the other?

Spoiler: you can't right now. Unless you go through every line of code modified by one and the other so that your two versions match perfectly.

Wouldn't that be a bit long? Well, that's exactly what Git will do for you.

Thanks to versioning, you'll be working on two different versions, and all you have to do at the end of the day is make a push to update the entire project.

That's great, but what if there's a bug on the production site during the day? Everyone's code is no longer the same as that in production.

Exactly, and that's where branches come into their own.

Branches

In an ideal world, this morning at 9 a.m. you would both have "drawn a branch", for example with your name.

A diagram would be easier to visualize:

The idea here is to each have your own development environment, i.e. not linked to your main branch/project.

When the sales rep comes running to warn you of a major bug "on the prod", all you have to do in this case is switch from your development branch to the main branch. This is done with the "checkout" command.

git checkout master

At this point, the code in your IDE reverts to that of the main branch, and you can quickly patch the bug. Then a new checkout to your dev branch allows you to resume your work.

Magic, isn't it?

Conventions

All this is really practical and saves an enormous amount of time. But there's one point that's very important for project coherence and team cohesion. That's conventions.

Indeed, it's important that all developers agree on how to write their code in a project.
If everyone adds their own personal touch, things will quickly become a merry b*****?

Technical stack

We could separate the technical stack on one side (i.e. all the software, libraries and programming languages used in a project) for example:

Languages: PHP, HTML/CSS, Javascript, SQL
Frameworks: Symfony, React
Deployment: Gitlab, CI/CD, Docker

Naming conventions

On the other hand, we could then determine the concrete way of coding, such as naming our variables.

The camelCase consists, among other things, in writing a capital letter for each word: validButton, cancelButton...
The snake_case consists in separating them with an underscore "_": valid_button, cancel_button

Indentation

Who hasn't complained about code made from a single block and rendered unreadable by a lack of indentation? This is precisely the kind of practice you should introduce and define at the start of a project involving several people.

Do we use tabs, spaces, 3 or 4?
Do you put the opening brace of a function/condition on the same line or below it?

An example of well-indented code

Overall, these are the most important conventions defined at the start of a project, but there may be many more! An exhaustive list is not possible, as the parameters and conditions of a project may differ.
The important thing is to set them and, above all, to stick to them all the way through. ?

Conclusion

And there you have it! I hope all these tips and resources will help you better prepare your projects with other developers. Remember, we're not much without each other - witness Stackoverflow and Github?