Comment fonctionne le travail en équipe (dans un projet OO)? [fermé]

Je programme en Java, dans un style très OO, par moi-même. Je n'ai jamais eu la chance de travailler avec d'autres programmeurs (je ne suis pas un professionnel, du moins pour le moment).

Par curiosité, je voulais demander: Comment fonctionne le travail avec une équipe sur un projet, en particulier lorsque vous travaillez sur un projet OO?

Comment fonctionne le fractionnement des tâches? Comment développez-vous quelque chose qui fonctionnera avec succès avec quelque chose qu'un autre programmeur a développé? Comment et quand les programmeurs communiquent-ils?

Merci

J'espère que je pourrai vous aider un peu, ou du moins vous orienter dans la bonne direction!

Cependant, comme un avertissement, c'est un sujet énorme - et je pense vraiment qu'il faut " se lancer " pour obtenir une compréhension approfondie. Cela dit, je vais vous présenter brièvement les deux principaux problèmes:

1. Le code et le contrôle des sources
2. Communications et quelques conseils.

En ce qui concerne spécifiquement les projets OOP - je ne peux honnêtement pas voir trop de problèmes spécifiques à OOP qui ne sont pas présents ailleurs.

En fait, je pense que la programmation de type POO est incroyablement adaptée au développement d'équipe. Une éthique clé de la POO est que je ne devrais pas connaître tous les détails de chaque objet avec lequel j'interagis: j'ai juste besoin de savoir ce qu'il peut faire et comment je peux le faire faire.

Les abstractions que la POO peut fournir sont impressionnantes dans une équipe.

Contrôle de source

Il doit y avoir un emplacement central pour le projet à stocker, et un qui permet à plusieurs développeurs d'accéder à la base de code à tout moment. C'est là que des systèmes tels que Git (ou SVN) entrent en jeu.

Je ne peux que parler spécifiquement de Git, car je n'ai jamais utilisé SVN - mais je suppose qu'ils sont similaires mais avec une terminologie différente.

En utilisant Git, je peux créer un référentiel avec tout le code source d'un projet donné, puis autoriser mon équipe à accéder au référentiel. Pour chaque fonctionnalité ou correction de bogue qui est alors effectuée, les développeurs individuels peuvent créer leur propre "branche", ce qui signifie que le développement peut se produire sur des pistes parallèles.

Une fois qu'une fonctionnalité ou un correctif est terminé, il peut ensuite être « fusionné » dans la base de code du projet principal. Tout " conflit " peut alors être détecté par Git et résolu au niveau source par le développeur responsable.

Je ne sais pas si vous avez déjà utilisé Git, mais cela peut sembler assez complexe au début - mais grâce à sa popularité récente (en partie auprès de Github ), il existe une multitude de tutoriels et de ressources.

Si vous ne l'avez pas utilisé auparavant, je vous recommande de vous inscrire à GitHub et de vous en faire une idée! (Alternativement, Bitbucket est une alternative similaire, mais il vous permet d'avoir des référentiels privés gratuitement.)

Git Flow est un excellent flux de travail basé sur Git qui est incroyablement utile pour les équipes. Comme Git en général, une fois que vous travaillez avec lui pendant un certain temps, il devient difficile d'imaginer travailler en équipe sans lui!

Les communications

Une fois que vous avez franchi toutes les barrières techniques, vous en revenez vraiment à la question fondamentale qui afflige la plupart des projets (techniques ou non) - et c'est la communication.

Toute l'équipe doit savoir qui fait quoi, quand elle le fait et ce qu'elle affecte.

La responsabilité doit être clairement définie

C'est évident, mais la plupart des projets utiliseront une certaine forme de système de ticket - où toutes les demandes de fonctionnalités ou les bugs sont enregistrés, puis attribués par la suite à un membre spécifique du personnel. ( JIRA , Unfuddle etc.) Souvent, ceux-ci sont intégrés au système de contrôle de source, ce qui rend la vie un peu plus simple. (BitBucket et GitHub fournissent tous deux un suivi des problèmes pour les référentiels Git hébergés avec eux.)

Cela arrête ou empêche au moins les développeurs de travailler accidentellement sur les mêmes problèmes.

Ce n'est cependant pas une solution complète; vous devez toujours vous assurer que les développeurs sont conscients des responsabilités des autres développeurs. Je sais par le passé que j'ai résolu d'autres problèmes que j'ai rencontrés lors de la correction d'un bogue spécifique, uniquement parce que cela avait du sens. (" Eh bien, je suis déjà là. Cela pourrait faire avec un refactor et je peux peut-être vérifier d'autres problèmes. ") Ensuite, j'ai dû m'excuser auprès d'autres développeurs car ils travaillaient sur les autres problèmes que j'ai fixe - nous perdions tous les deux de notre temps.

En général, ces problèmes peuvent être résolus par ...

Réunions régulières

Certaines méthodologies de gestion / développement de projets dictent des méthodes de communication spécifiques ou des intervalles de réunion. En général, les systèmes les plus productifs que j'ai vus ont été les réunions debout du matin où tout le monde dans une équipe donne un aperçu rapide de ce qu'ils font - si vous limitez cela aux membres de l'équipe de développement uniquement et avez des directives claires sur ce que pour communiquer alors ceux-ci peuvent être incroyablement efficaces. J'ai toujours essayé de m'en tenir à:

Je travaille sur X,

Pour atteindre / corriger Y,

Ce qui implique de modifier / amender Z.

Les autres membres de l'équipe peuvent immédiatement comprendre que " Fergus travaille sur la correction de ce bogue qui a été enregistré l'autre jour, mais cela signifie qu'il travaille sur un code que je dois regarder - je vérifierai avec lui avant d'apporter des modifications. ".

Rencontres architecturales

J'ai récemment travaillé avec une grande équipe qui a eu un " chat technique " tous les quinze jours , où des questions plus importantes / architecturales seraient discutées. Chaque membre de l'équipe a eu le temps de comprendre les problèmes plus importants auxquels le projet était confronté et a pu discuter des correctifs potentiels.

Personnellement, j'ai adoré cela, je n'ai pas beaucoup contribué car j'étais assez nouveau dans le projet - mais pouvoir écouter les discussions m'a donné beaucoup de perspicacité; très vite, j'ai pu comprendre le projet ainsi que les styles de pensée individuels.

La communication est le seul problème qui peut faire tomber n'importe quelle équipe. Technique ou non, si les gens ne sont pas au courant de la situation dans son ensemble, il y a de plus grandes chances qu'ils échouent.

Autres issues

Il est bon de s'assurer que tout le monde a la même configuration ou le même style lorsque vous travaillez en équipe. Qu'est ce que je veux dire?

Configuration

Si vous travaillez sur un projet Java - alors peut-être assurer (pour les environnements de développement au moins, certainement pas pour les tests.) Les versions JVM sont courantes parmi l'équipe peut être une bonne idée? Ensuite, les IDE. Cela aide grandement si toute l'équipe utilise Eclipse ou NetBeans ou l'IDE de votre choix.

Sur un projet Web, il se peut que tous les développeurs aient besoin d'une pile spécifique; avec des versions spécifiques d' Apache ou PHP .

Penser à des facteurs comme celui-ci permet simplement à l'équipe de "gélifier" un peu plus rapidement dans mon esprit.

Style

Onglets vs espaces? CamelCase ou spacing_with_underscores? Aussi petites que puissent être ces questions lorsque vous travaillez seul, lorsque vous travaillez avec une équipe plus grande, vous voulez vraiment tendre vers un style commun.

En fait, vous ne devriez pas vraiment pouvoir dire qui a écrit une section spécifique de code - vous devez juste savoir qu'elle appartient .

C'est pourquoi de nombreux projets open source publient ouvertement des directives / guides de style de code source - pour avoir une idée de ce qu'ils contiennent, jetez un œil aux Google StyleGuides pour leurs propres projets open source.

Tâches et tests unitaires

Cela ne se limite pas aux équipes, mais je vais y revenir rapidement pour une raison en particulier: cela facilite beaucoup la vie en équipe.

Si vous avez un flux de travail complexe avec beaucoup de dépendances ou un long processus de construction - il est souvent utile d'automatiser cela à l'aide d'un gestionnaire de tâches. Pour les projets Web, GruntJS est génial, bien que venant de Java, je suppose qu'Apache Ant peut être assez similaire.

En tant qu'individu, j'utilise GruntJS pour créer mon site avant de le déployer sur mon serveur FTP - une seule commande Grunt est tout ce dont j'ai besoin pour que mon CSS / Sass soit compilé et minifié , mes actifs à compresser puis mes fichiers à télécharger.

Cependant, en tant que membre de l'équipe, je peux utiliser GruntJS pour vérifier que je n'ai cassé aucun test - et que je n'ai introduit aucun bogue en n'étant pas pleinement au courant des autres parties du projet. Ceci est bien sûr, en plus des avantages qu'il me procure en tant que développeur individuel.

Je peux également l'utiliser pour cloner un projet à l'aide de mon package de contrôle de source (Git) - et exécuter une commande pour installer toutes mes dépendances. C'est un gros avantage, car le temps passé à amener un nouveau développeur dans la position où il peut réellement commencer à développer peut être assez long - sans même prendre en compte le temps qu'il faut pour s'habituer à une base de code inconnue.

Documentation

Les meilleurs projets que j'ai vus ont eu une documentation (et souvent assez excessive) destinée aux développeurs. Ce type de documents peut expliquer des choses comme:

1. L'environnement de développement:

"Nous déployons actuellement sur un serveur exécutant une pile LAMP , car ces développeurs devraient cibler les versions décrites dans .."

2. Flux de travail

"Toutes les fonctionnalités doivent être développées sur une branche 'feature / *' et fusionnées dans la branche 'testing' avant d'être considérées comme prêtes pour la sortie."

3. Responsabilités au sein de l'équipe:

"Pour les problèmes de base de données, parlez à Steve. Pour les problèmes de plate-forme, parlez à David."

4. Un " pipeline " pour l'avenir

«Lorsque vous développez un nouveau code, n'oubliez pas qu'à partir de juin 2014, nous souhaitons implémenter le code x -legacy devra peut-être être revu avant que cela ne se produise.

Exemples

Il peut être utile de regarder le flux de travail d'un projet open source pour avoir une idée de son fonctionnement - qu'il s'agisse d'un projet établi avec son propre flux de travail (souvent très documenté), ou l'un des nombreux exemples sur GitHub.

Un dernier mot d'avertissement

Si vous vous retrouvez à travailler dans une équipe qui réussit à faire tout cela correctement ... vous détesterez être ailleurs ..! Croyez-moi, une fois que vous avez fait l'expérience d'une bonne équipe, tout à coup, des problèmes ailleurs peuvent vraiment vous entraîner. (C'est une histoire pour un autre article cependant!)