Discussion :

[Nicopeuzin]

Bonjour!

Au sein de mon entreprise, nous sommes plusieurs à travailler sur un programme et son interface graphique et nous utilisons un SVN pour mettre en commun nos différentes versions à la fin de la journée. Toutefois il y a souvent des conflits et j'aimerais savoir s'il est possible de coder un programme en utilisant plusieurs projet. J'imagine que de gros programmes comme les jeux vidéos par exemple ne sont pas codés en un seul projet! Savez vous comment les développeurs procèdent?

Pour info nous utilisons Qt.

Bien à vous

[ternel]

En fait, si, les gros programmes sont quand même codés dans un seul projet.
La preuve, à la fin, il y a un programme.

Par contre, souvent, on développe des fonctionnalités autonomes, parfois sous forme de bibliothèques (liées statiquement ou non).

S'il y a souvent des conflits, cela vient du fait que plusieurs personnes travaillent sur le même fichier.
Cela peut venir de deux problèmes principaux:

1. Soit les fichiers sources sont trop gros et font trop de choses.
2. Soit plusieurs développeurs travaillent sur la même fonctionnalité

Dans les deux cas, il faut éviter. Quand on respecte scrupuleusement le SRP (Principe de Responsabilité Unique), les choses se découpent facilement.
Appliqué aux développeurs, ca marche aussi: un développeur fait une seule chose en même temps.

Souvent, les développeurs se voient attribuer chacun leur partie du programme.

[Nicopeuzin]

Entendu, enfin tu avouera quand même qu'en programmation orientée objet c'est compliqué de scrupuleusement s'en tenir au même fichier..
Tu peux m'en dire un peu plus sur comment développer des fonctionnalités sous forme de bibliothèques?

[ternel]

Bah, supposons un jeu de stratégie.
Tu pourrais avoir une bibliothèque pour la représentation des données et les règles du jeu, une deuxième pour les IA, une troisième pour le joueur graphique (humain), et une quatrième pour la connectivité réseau.

Même en OO, il est relativement aisé de répartir les classes dans des fichiers séparés. En fait, tu pourrais même mettre chaque fonction membre dans son propre .cpp (ce que je déconseille tout de même)

[koala01]

Salut,

Entendu, enfin tu avouera quand même qu'en programmation orientée objet c'est compliqué de scrupuleusement s'en tenir au même fichier..
Tu peux m'en dire un peu plus sur comment développer des fonctionnalités sous forme de bibliothèques?

En toute honnêteté, si tu en arrives à subir des conflits SVN à cause de modifications apportées par d'autres équipes que la tienne à des fichiers, toutes les explications du monde ne pourront pas résoudre le problème principal ( du moins à ton niveau) qui est qu'aucune des équipe ne travaille effectivement sur un projet particulier. Si bien que la seule solution sensée serait sans doute de fuir cette boite au plus vite!

Maintenant, si tu subis des conflits SVN à cause du travail des gens qui travaillent dans ta propre équipe, j'aurais tendance à dire que c'est un problème d'organisation "un peu moins sévère", auquel le simple fait de faire des commits plus nombreux devrait déjà pouvoir apporter quelques réponses.

En effet, la règle à appliquer pour travailler correctement avec un gestionnaire de version comme SVN est : on commit (dans le tronc, ou, mieux encore, dans la branche "générale" de développement, celle qui regroupe toutes les modifications validées depuis la dernière version présentée, et qui sera intégrée dans le tronc à la prochaine version) quand une tâche est finie. Si cela signifie faire dix commit de correction de bug sur la journée, ou, à l'inverse, créer une branche dans laquelle on commitera "à la fin de la journée" pendant dix jours le temps d'intégrer une nouvelle fonctionnalité, hé bien soit. Qu'il en soit ainsi.

A charge pour chacun de veiller à intégrer "aussi régulièrement que nécessaire" les modifications apportées dans le tronc (ou dans la branche générale de développement) à sa propre branche pour, justement, éviter les conflits.

Cependant, cela ne sera sans doute effectivement pas suffisant pour éviter tous les conflits de version. Tu dois de toutes façons partir du principe que, s'il est effectivement possible de les limiter "au stricte minimum", il n'est absolument pas impossible de les éviter complètement, dés le moment où l'on travaille à "plus de un"

L'étape suivante consiste à veiller à respecter le SRP et l'OCP le plus scrupuleusement possible:

Le SRP (Single Responsability Principle ou principe de la responsabilité unique) pour une raison toute simple : si chaque classe, chaque fonction ne s'occupe effectivement que d'une seule et unique chose, cela limite très fortement le risque que deux personnes veuillent aller y chipoter en même temps, même (et surtout) s'il s'agit de corriger deux bugs totalement différents

L'OCP (Open / Close Principle ou principe "Ouvert / Fermé") pour une raison encore plus simple : si on ne modifie pas le code validé pour rajouter des fonctionnalités, les seules modifications qu'il subit seront... destinées à corriger des bugs. Encore une fois, les chances pour que deux bugs distincts nécessitent de modifier la même fonction sont relativement simple.

En outre, il reste un dernier problème auquel les deux principes que je viens de rappeler ne pourront sans doute rien : des fichiers par trop gros. Je veux parler de fichiers qui contiennent des centaines, voire des milliers de lignes, surtout si ces centaines ou milliers de lignes sont en réalité composés d'un grand nombre de fonctions très courtes.

La réponse à ce problème passe par le respect de la règle implicite de "UNE classe == une unité de compilation (1 ficher d'en-tête + 1 fichier d'implémentation).

Lorsqu'il est question de fonctions libres, la règle est de grouper les fonctions "qui vont bien ensembles". Ainsi, si tu dispose de deux fonctions -- par exemple une fonction manipulant une matrice 2*2 et une manipulant un vecteur 3D -- et que tu ne vas pas systématiquement utiliser l'une "à peu près en même temps" que l'autre, il n'y a aucune raison ni de les déclarer, ni de les implémenter ensemble. Ainsi, la fonction de mon exemple manipulant une matrice 2*2 sera sans doute "parfaitement à sa place" dans une unité de compilation (1 ficher d'en-tête + 1 fichier d'implémentation) regroupant ... toutes les fonctions destinées à la manipulation de matrice 2*2, alors que celle manipulant un vecteur 3D serait tout à fait à sa place dans une unité de compilation destinée aux fonctions... soccupant de la manipulation de vecteur 3D.

Enfin, la modularisation devrait t'inciter à ne regrouper au sein d'une bibliothèque (même si elle n'est créée que par "facilité") que ce qui a trait à un ensemble de fonctionnalités communes.

Par exemple, à faire en sorte de ne regrouper dans une bibliothèque "sounds" que... ce qui permet au son de travailler, alors que l'on ne regrouperait au niveau d'une bibliothèque "graphics" que... ce qui permet d'obtenir un "zoli affichage, exactement comme on le souhaite".

Le "fin du fin" (et l'idéal) étant, bien sur que la bibliothèque sounds et la bibliothèque graphics soient totalement indépendante. Au point que, pour autant que l'on dispose des données métier (sans doute regroupées ensemble dans une bibliothèque "business"), il devrait être possible de supprimer toute la bibliothèque graphics du projet, sans que cela pose "le moindre problème" à l'application (hormis, bien sur, le fait que c'est peut être pas très sympa d'entendre du son sans pouvoir constater l'aspect graphique )

[Nicopeuzin]

Merci pour vos réponses éclairées. Je comprends mieux l'importance du SRP, l'OCP, et le fait de "diviser pour mieux régner"