« Développement collaboratif » : différence entre les versions

De EduTech Wiki
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
 
(12 versions intermédiaires par un autre utilisateur non affichées)
Ligne 1 : Ligne 1 :
[[category:programmation]]
[[category:programmation]]
{{stub}}
{{En construction}}


'''Citation de Kant''' :  
'''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.''
:''...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...


==Introduction==
==Qu'est-ce que le développement collaboratif ?==
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.
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..


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.
===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.


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 !
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.


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é.
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]


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.
Pour aller plus loin dans la documentation de PHP :
[http://manual.phpdoc.org/HTMLframesConverter/default/phpDocumentor/tutorial_elements.pkg.html phpDocumentor Manual]


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''.
==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==
===Quelques définitions===
;Dépôt (ou ''repository'')
;Dépôt (ou ''repository'')
:Il s'agit d'un serveur de fichiers, chacune des versions de chaque fichier y sera enregistré.
:Il s'agit d'un serveur de fichiers, chacune des versions de chaque fichier y sera enregistré.
Ligne 34 : Ligne 62 :




==Les bonnes pratiques==
===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====
{| border="1" style="margin: 0 auto"
!          !! Numéro de version !! à compléter...
|-
|'''SVN''' || Projet global    ||
|-
|'''CVS''' || Par fichier      ||
|}


==Les moins bonnes pratiques==
====Intégration des outils dans les [[:en:IDE | 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.


==Les outils==
Il est ensuite possible de raccorder les ''branches'' à la copie principale.


;[[Subversion]] - de son petit nom '''''SVN'''''
==Les avantages==
:Évolue assez rapidement, est aujourd'hui le standard en matière de développement collaboratif
*Conserver une copie étalon de son travail.
;[[Concurrent Versioning System]] - de son petit nom '''''CVS'''''
*Conserver une version de chaque fichier d'un projet.
:Est encore utilisé dans plusieurs projets qui ont la vie dure, mais la plupart des projets transitent tranquillement vers le SVN


===Les outils d'outils===
----
Une certaine maîtrise du Linux
==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.


TortoiseSVN
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.


TortoiseCVS
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é.


===Intégration des outils dans les IDE===
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.
Eclipse, Zend, Dreamweaver?


===Historique===
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''.


==Quand les utiliser==
[[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.