Revue de code et reporting de l'activité

Chaque semaine, Eric prend du temps afin d’analyser le code que j’ai fourni et m’envoie par mail une critique constructive. Les conseils sont en générale constituée d’une liste de bonnes pratiques que je n’ai pas appliquées, comme les conventions de nommage ou le manque de commentaire du code, le mauvais placement d’une fonctionnalité technique ou la mauvaise utilisation des outils à notre disposition.

Ces revues de codes m’ont été très importantes tout au long du stage. C’est une des raison pour lesquelles j’ai choisi une grosse entreprise comme Sopra Steria pour effectuer mon alternance, par rapport à d’autres sociétés beaucoup plus petites qui me proposaient un salaire plus intéressant, mais m’auraient livré à moi-même face au code. Cette façon de faire m’a permis de monter en compétence quand à la qualité de mon code. J’ai aussi pu apprendre des bonnes pratiques afin de permettre à un code d’être maintenable plusieurs années après sa création.

Chaque semaine je dois rendre des comptes à Eric et lui fournir un rapport de mon activité de la semaine passée que l’on appelle en interne un “V1”.

Exemple d’un V1 :

Lorsqu’une tâche est toujours en cours de développement, le V1 doit aussi comporter un RAE (reste à effectuer) dans lequel nous devons estimer le temps restant à l’achèvement de la tâche. Les premières semaines, mon manque de connaissance de l’architecture rendait mes RAE complètement aléatoires. C’est un problème qui s’est résolu après la maîtrise de l’architecture de l’application. Maintenant que j’ai la visibilité de ce que je dois modifier afin d’arriver à mon but, mes RAE sont devenus plus précis avec une marge d’erreur d’une demi journée vers la fin du stage.

Cet exemple de V1 est tiré d’une des dernières semaines de mon stage, lors de laquelle l’architecture du projet a été maîtrisée et les fonctionnalités ont été livrées dans les temps.