« Développement collaboratif » : différence entre les versions
m (→Dissertation) |
|||
(4 versions intermédiaires par un autre utilisateur non affichées) | |||
Ligne 17 : | Ligne 17 : | ||
==Procédures== | ==Procédures== | ||
..à compléter un jour.. | ..à compléter un jour, il existe des modèles de développement collaboratif.. | ||
===Méthodes=== | |||
Une bonne pratique est d'insérer des commentaires dans les fichiers de vos applications. Ces commentaires servent à définir l'utilité générale d'un fichier, donner des indications de développement et d'utilisation du ''programme'' qu'il contient. | |||
Une méthode fréquemment rencontré est de commenter votre code à l'aide d'un DocBlock. Voici un exemple pour une fonction : | |||
<pre> | |||
/** | |||
* Description : Exemple d'un DocBlock pour une fonction. | |||
* Vous pouvez littéralement spécifier ce qui vous plaît ici. | |||
* | |||
* @param string $argument1 Variable à inclure lors de l'appel de la fonction, elle doit être de type 'string'. | |||
* @param array $argument2 Doit être une liste (array) pour que la fonction s'éxécute correctement. | |||
* @return boolean true Cette fonction va toujours retourner true si xxxx sinon elle renverra false. | |||
*/ | |||
function doThis($argument1, $argument2 = array()) { | |||
return true; | |||
}</pre> | |||
À l'aide de ces descriptions, on explique ce que la fonction demande, et ce qu'elle renvoit comme données. De cette façon, il est plus simple de ''décrypter'' l'utilisation de cette fonction par les autres programmeurs. | |||
Voici une liste des arguments qui peuvent être incluent dans un DocBlock pour un document PHP : | |||
[http://2tbsp.com/system/files/phpdoc_cheatsheet.pdf phpDoc cheatsheet] | |||
Pour aller plus loin dans la documentation de PHP : | |||
[http://manual.phpdoc.org/HTMLframesConverter/default/phpDocumentor/tutorial_elements.pkg.html phpDocumentor Manual] | |||
==Outils== | ==Outils== | ||
Ligne 40 : | Ligne 64 : | ||
===Les serveurs de fichiers=== | ===Les serveurs de fichiers=== | ||
;[[Subversion]] - de son petit nom '''''SVN''''' | ;[[Subversion]] - de son petit nom '''''SVN''''' | ||
:Évolue assez rapidement, est aujourd'hui le standard en matière de serveur de fichiers de développement. | :*Évolue assez rapidement, est aujourd'hui le standard en matière de serveur de fichiers de développement. | ||
:Offre un numéro de version ''global'' du projet. | :*Offre un numéro de version ''global'' du projet. | ||
;[[Concurrent Versions System]] - de son petit nom '''''CVS''''' | ;[[Concurrent Versions System]] - de son petit nom '''''CVS''''' | ||
:Est encore utilisé dans plusieurs projets qui ont la vie dure, mais la plupart des projets transitent tranquillement vers le SVN | :*Est encore utilisé dans plusieurs projets qui ont la vie dure, mais la plupart des projets transitent tranquillement vers le SVN | ||
:Offre un numéro de version ''par fichier'' | :*Offre un numéro de version ''par fichier'' | ||
====Comparaison de SVN et CVS==== | ====Comparaison de SVN et CVS==== | ||
Ligne 54 : | Ligne 78 : | ||
|'''CVS''' || Par fichier || | |'''CVS''' || Par fichier || | ||
|} | |} | ||
====Intégration des outils dans les [[:en:IDE | IDE]]==== | ====Intégration des outils dans les [[:en:IDE | IDE]]==== | ||
Ligne 106 : | Ligne 104 : | ||
Rien de bien différent que de travailler avec un bon vieux FTP me direz-vous. Erreur, car lors de la mise à jour, il y a une vérification des deux copies des fichiers et si un autre à travailler sur le même fichier, il sera prévenu du risque d'écrasement et devra scinder les modifications apporté par l'autre pour pouvoir mettre à jour la version ''primaire''. | Rien de bien différent que de travailler avec un bon vieux FTP me direz-vous. Erreur, car lors de la mise à jour, il y a une vérification des deux copies des fichiers et si un autre à travailler sur le même fichier, il sera prévenu du risque d'écrasement et devra scinder les modifications apporté par l'autre pour pouvoir mettre à jour la version ''primaire''. | ||
[[en:Revision control system tutorial]] |
Dernière version du 15 octobre 2008 à 18:29
Cet article est en construction: un auteur est en train de le modifier.
En principe, le ou les auteurs en question devraient bientôt présenter une meilleure version.
Citation de Kant :
- ...l'on ne peut point considérer sans admiration combien, dans l'intelligence commune de l'humanité, la faculté de juger en matière pratique l'emporte de tout point sur la faculté de juger en matière théorique.
...pas terrible, faudrait trouver mieux...
Qu'est-ce que le développement collaboratif ?
Il s'agit d'une organisation spécifique du travail de groupe sur un ensemble de fichier qui forment a priori un projet spécifique.
On peut retrouver cette organisation sous diverses formes: procédures, outils, etc. Toutes s'employant à cadrer le travail de développement afin que le projet grandisse dans la bonne direction et que les actions de chacun ne nuisent pas au travail des autres.
Quand utiliser un outil de développement collaboratif ?
Dés le moment où vous avez l'intention de travailler sur un projet ! En effet, que ce travail soit fait en loup solitaire ou en groupe, il est toujours très pratique d'avoir accès aux versions antérieurs des fichiers d'un projet, ne serait-ce que pour éviter de perdre des fichiers par erreur.
De plus, l'utilisation d'un serveur de fichiers vous force à adopter une méthode de travail sûre, vous devez spécifier les fichiers du projet et les mettre à jour lorsque vous y effectuez une modification. C'est en quelque sorte une sauvegarde externe de votre travail.
Procédures
..à compléter un jour, il existe des modèles de développement collaboratif..
Méthodes
Une bonne pratique est d'insérer des commentaires dans les fichiers de vos applications. Ces commentaires servent à définir l'utilité générale d'un fichier, donner des indications de développement et d'utilisation du programme qu'il contient.
Une méthode fréquemment rencontré est de commenter votre code à l'aide d'un DocBlock. Voici un exemple pour une fonction :
/** * Description : Exemple d'un DocBlock pour une fonction. * Vous pouvez littéralement spécifier ce qui vous plaît ici. * * @param string $argument1 Variable à inclure lors de l'appel de la fonction, elle doit être de type 'string'. * @param array $argument2 Doit être une liste (array) pour que la fonction s'éxécute correctement. * @return boolean true Cette fonction va toujours retourner true si xxxx sinon elle renverra false. */ function doThis($argument1, $argument2 = array()) { return true; }
À l'aide de ces descriptions, on explique ce que la fonction demande, et ce qu'elle renvoit comme données. De cette façon, il est plus simple de décrypter l'utilisation de cette fonction par les autres programmeurs.
Voici une liste des arguments qui peuvent être incluent dans un DocBlock pour un document PHP : phpDoc cheatsheet
Pour aller plus loin dans la documentation de PHP : phpDocumentor Manual
Outils
Les outils les plus utilisés qui ont été développés sont en fait des serveurs de fichiers. Il ne s'agit pas de simple serveur, ces derniers conservent un historique de chaque version de chaque fichier qui aura été inséré dans le serveur. De cette façon, les développeurs auront l'occasion de vérifier chaque modification de chaque fichier d'un projet.
Quelques définitions
- Dépôt (ou repository)
- Il s'agit d'un serveur de fichiers, chacune des versions de chaque fichier y sera enregistré.
- Il est toutefois plus pratique de les considérer comme le répertoire principal des fichiers du projet, dans sa globalité.
- Copie primaire
- C'est la seule et unique version des fichiers présents sur le dépôt (repository).
- C'est la base de tout !C'est à partir de cette copie que chacun pourra avoir une mise à jour du travail des autres.
- Elle n'est présente que sur le serveur de fichiers.
- Copie de travail
- Cette copie est possédé par tous ceux qui veulent participer au développement d'un projet.
- Cette copie existe sur l'ordinateur de tous les programmeurs actifs.
- La tâche leur incombe de la mettre à jour avant de travailler dessus.
- Copie de bêta-testeur
- C'est une copie des projets en évolution que certains projets mettent à disposition de tout un chacun. Cette copie ne pourra qu'être téléchargé sur l'ordinateur personnel et les modifications apportés aux projets ne pourront être mises à jour sur la copie primaire.
Les serveurs de fichiers
- Subversion - de son petit nom SVN
-
- Évolue assez rapidement, est aujourd'hui le standard en matière de serveur de fichiers de développement.
- Offre un numéro de version global du projet.
- Concurrent Versions System - de son petit nom CVS
-
- Est encore utilisé dans plusieurs projets qui ont la vie dure, mais la plupart des projets transitent tranquillement vers le SVN
- Offre un numéro de version par fichier
Comparaison de SVN et CVS
Numéro de version | à compléter... | |
---|---|---|
SVN | Projet global | |
CVS | Par fichier |
Intégration des outils dans les IDE
Eclipse, Zend, Dreamweaver?, Komodo
Développement alternatif
Parfois, lors de l'élaboration d'un projet, une organisation différente du traitement des données est proposée entre les développeurs. Ces outils permettent relativement facilement de créer différentes branches de développement d'un même projet.
Il est ensuite possible de raccorder les branches à la copie principale.
Les avantages
- Conserver une copie étalon de son travail.
- Conserver une version de chaque fichier d'un projet.
Dissertation
Nous avons souvent l'occasion d'entendre parler de développement, de collaboration et nous avons tous une certaine expérience du travail d'équipe ainsi qu'une (probablement) certaine expérience de la programmation.
Le monde de la programmation est une sorte de vase clos. Le programmeur a tendance à s'enfermer dans un langage de programmation et à limiter ses interactions directes avec les autres programmeurs que lorsqu'il rencontre des ennuis ou qu'il s'ennuie. Il y a dans les entreprises de développement collaboratif une façon globale d'organiser le développement, selon une structure, dans un objectif précis et une séparation des tâches à effectuer.
Mais qu'en est-il dans la réalité, lorsqu'un des développeurs a besoin de changer un bout de code dans un fichier ? Comment des équipes font-elles pour ne pas corrompre le travail des autres en écrasant malencontreusement un fichier mis à jour par un autre ? Cela nous est tous arrivé de perdre des données par une bêtise toute bête, alors imaginez en multipliant le nombre d'utilisateur d'un même espace !
Le collaboratif sans organisation finalement, ça n'est rien de plus que de ne pas toucher le travail de l'autre, ainsi cela crée des frontières importantes entre les travaux de chacun et il arrivait fréquemment qu'à cause de ces frontières, chacun développait son bout de code à sa sauce afin de faire rouler sa partie d'application. Créant de la redondance à perpétuité.
Aujourd'hui, nous avons droit à des outils suffisamment performant pour permettre une véritable collaboration au travers de l'équipe de programmation. Ces outils sont en fait des dépôts où l'on place une copie primaire d'une application. Ce dépôt va ensuite conserver une copie de chaque version de chaque fichier qui sera placé à l'intérieur. Chaque développeur devra ensuite mettre à jour sa copie de travail de l'application avant d'y opérer des modifications. Dés qu'il a terminé ses modifications, il devra mettre à jour la version primaire, afin que les autres programmeurs puissent travailler avec ses transformations et les valider.
Rien de bien différent que de travailler avec un bon vieux FTP me direz-vous. Erreur, car lors de la mise à jour, il y a une vérification des deux copies des fichiers et si un autre à travailler sur le même fichier, il sera prévenu du risque d'écrasement et devra scinder les modifications apporté par l'autre pour pouvoir mettre à jour la version primaire.