[Tutoriel] Guide Mapmaking : Développement Collaboratif

Cet article fait partie d’une série servant à enseigner l’art du développement sur Minecraft. Vous pourrez retrouver l’introduction et le sommaire en cliquant ici.

Développer en solo, c’est bien, développer en équipe, c’est mieux. Maintenant que vous maîtrisez les rudiments du développement, il est grand temps de se poser la question : comment développer à plusieurs ?

Pour cela on va se concentrer sur différents points :

Les réflexes à prendre
Les astuces d’écriture pour simplifier le partage des fichiers de code
Les logiciels de développement collaboratifs
Travailler chacun de son côté/tous en groupe sur un serveur commun

Réflexes à prendre

Cette partie est valable, peu importe le langage utilisé ou le projet sur lequel vous travaillez. Tout comme, dans les langages parlés, vous mettez de la ponctuation, tournez vos phrases d’une certaine façon, faites des gestes ou expressions faciales pour bien faire comprendre ce que vous cherchez à exprimer, dans les langage de développement, vous devrez également travailler la communication.

Pour cela, tous les langages permettent de laisser des commentaires dans les fichiers de code. Ces commentaires sont extrêmement important, aussi bien pour vous que pour les personnes à qui vous partagerez votre code.

“Tkt, je bosse en solo, personne ne verra mon code”

NON ! Un jour ou l’autre, quelqu’un verra votre code, que vous le vouliez ou non, et même pour vous, cela vous évitera de perdre une quantité phénoménale de temps à résoudre des erreurs qui n’auraient pas eu lieu si vous n’aviez pas tenté de retenir par cœur le fonctionnement de tout votre programme ! … Où en étais-je ? Ah oui ! Ainsi, chaque fonction doit contenir au moins un commentaire expliquant son utilité et comment l’utiliser. Ajoutez à cela un commentaire par “bloc” de code, dans l’idéal et un bloc de code ne dépasse jamais les 4 à 5 lignes. Certains trouveront que c’est trop de commentaire et que c’est inutile, mais c’est là toute la différence entre les développeurs qui savent travailler en équipe de ceux qui ne savent pas. Il est toujours possible de compenser ce manque de communication par des compétences chez chacun des membres du projet mais cela demande bien plus d’effort et de temps. Nous sommes bien placés pour vous en parler, nous autres mapmakers sommes mauvais en communication et ça nous fait souvent perdre beaucoup de temps inutilement alors qu’un simple commentaire peut très souvent tout arranger. Lire du code sans commentaire est au mieux très compliqué et désagréable, même pour un développeur aguerri, et au pire source de confusion et donc d’erreurs/conflits pouvant faire perdre un temps considérable.

Pour les mcfunctions, les commentaires s’écrivent après avoir inséré un “#” en début de ligne. Toute la ligne est alors dédiée au commentaire, inutile d’y écrire du code, il ne sera pas considéré par le jeu.

En plus des commentaires, il faut apprendre à diviser son code. Un fichier a rarement d’utilité à dépasser les 15 lignes de code. L’idéal dans le développement est que chaque fonction soit la plus simple possible pour que toutes les fonctions, une fois assemblées, forment un code propre, simple à comprendre et très facile à débugger. Au delà de simplement diviser le code en plusieurs fichiers, il sera aussi très judicieux d’”aérer” votre code. Le retour à la ligne est gratuit, n’hésitez pas à en abuser, deux lignes de code collées signifient que ces deux lignes sont totalement inséparables. Avoir plusieurs lignes de codes sans espace entre chaque c’est le meilleur moyen d’avoir une migraine lorsque vous essayerez de trouver une erreur ou lorsque vous essayerez de comprendre le code écrit.

En bref, prenez le réflexe de commenter, séparer les fichiers et aérer au maximum. On ne le répétera jamais assez tellement ce point à d’importance.

Trucs et astuces

Dans la plupart des langages, les fonctions peuvent êtres appelées avec des “paramètres”. Ces paramètres servent à modifier le comportement de la fonction afin d’avoir un résultat différent (mais cohérent selon l’objectif de la fonction). Malheureusement, les mcfunction n’ont pas ce système de paramètre. Néanmoins, on peut toujours le simuler. Pour cela, il suffit de créer un certain nombre (en général, 10 suffit largement) de “variables temporaires”. Ces variables, parfois appelées “variables de buffer” ou juste “buffer”, servent à stocker des données en attente d’être traitées.

Par “en attente”, on ne parle pas là de temps mais de nombre d’instructions. Par exemple, dans une préparation de cuisine, si vous préparez la pâte d’une quiche, il faudra à un moment la mettre en attente pendant que vous vous occupez de traiter le reste des ingrédients, puis vous récupérez votre pâte pour la manipuler. C’est exactement pareil en développement, des données peuvent être mises de côté en attendant de traiter autre chose, puis récupérées par la suite pour être utilisées.

Ici, on utilisera ces variable pour y stocker des nombres (les variables sont bien entendu des objectifs de scoreboard) puis appeler une fonction qui utilisera ces variables. Là, certains se posent la question “ben à quoi ça sert de se prendre la tête avec des variables temporaires blablabla ?”

Et bien, simplement, vos variables temporaires vous savez comment elles s’appellent et elles ne changent jamais. Ainsi, si vous développez une fonction cosinus() et que vous la donnez à un collègue, ce dernier saura quelle variable modifier pour utiliser votre fonction (le nom des variables temporaire doit être simple et évocateur, exemple: “var1”, “var2” etc…). Ainsi, chacun peut utiliser ces variables sans devoir se soucier de comment les autres ont écrit leur code et quelles variables ils ont utilisé. Et le top, c’est qu’il n’y a aucun risque de conflit de ces variables, vu que plusieurs personnes les utilisent ; car à chaque début d’utilisation d’une de ces variables, il faut avant tout la “set” (définir sa valeur) comme on le souhaite. Ces variables ne sont pas là pour stocker des données sur du long terme car peuvent être modifiées en permanence, leur contenu est temporaire et n’est qu’une copie d’une autre variable.

De plus, si vous créez une map ou n’importe quel projet nécessitant un aspect de développement assez important, un dossier “utils” regroupant des fonctions assez générales peut permettre de gagner beaucoup de temps. Par exemple, un dossier /utils/math/ qui contiendrait toutes les fonctions permettant de faire des calculs mathématiques permettrait à tous les développeurs du projet de simplement faire appel à ces fonctions au lieu de devoir les développer à chaque fois.

Logiciels

Comment faire en sorte que tout le monde possède la dernière version du projet tout en permettant à chacun de pouvoir le modifier ?

Pour cela, quelques logiciels existent. Le premier, si vous développez directement sur un serveur, sera simplement un logiciel de transfert de fichier comme FileZilla ou WinSCP. Ils ne sont pas fait pour ça, mais si chacun des membres développe directement sur le serveur, les conflits ne devraient pas arriver (sauf si deux personnes modifient le même fichier au même moment).

Si vous souhaitez modifier le même fichier en même temps, nous vous conseillons de copier son contenu sur un site comme https://codeshare.io ou bien dans un simple google doc.

Enfin, si vous souhaitez réaliser un gros projet et avoir les meilleurs outils pour y arriver, vous pourrez utiliser Github (ou un équivalent). Ce site, doublé d’un logiciel est le saint graal des développeurs. Il permet de mettre en commun un projet, gérer différentes version, enregistrer chaque modifications par chacun des membres, organiser les tâches etc. Pour ce dernier outils, vous devrez sans doute suivre un petit cours afin de le manipuler: https://openclassrooms.com/fr/courses/2342361-gerez-votre-code-avec-git-et-github