Comment les programmeurs travaillent-ils ensemble sur un projet?
J'ai toujours programmé seul, je suis encore étudiant donc je n'ai jamais programmé avec quelqu'un d'autre, je n'ai même jamais utilisé de système de contrôle de version auparavant.
Je travaille actuellement sur un projet qui nécessite de savoir comment les programmeurs travaillent ensemble sur un logiciel dans une entreprise.
Comment le logiciel est-il compilé? Est-ce du système de contrôle de version? Est-ce par des programmeurs individuels? Est-ce périodique? Est-ce quand quelqu'un décide de construire ou quelque chose? Existe-t-il des tests pour s'assurer que cela "fonctionne"?
N'importe quoi fera l'affaire.
En fait, il existe autant de variantes de ces processus que de nombreuses entreprises. Signification: chaque entreprise a des conventions un peu différentes des autres, mais il existe quelques bonnes pratiques communes qui sont généralement utilisées dans la plupart des endroits.
Meilleures pratiques toujours utiles
- Tout le code source du projet et tout ce qui est nécessaire pour le construire est sous contrôle de version (aussi appelé source contrôle). N'importe qui devrait être en mesure de créer l'intégralité du projet en un seul clic.
De plus, les fichiers inutiles (fichiers objets ou binaires compilés) ne devraient pas être ajoutés au référentiel, car ils peuvent être régénérés assez facilement et serait juste perdre de l'espace dans le repo. - Chaque développeur doit mettre à jour et valider pour le contrôle de version plusieurs fois par journée. Surtout lorsqu'ils ont terminé la tâche sur laquelle ils travaillent et l'ont suffisamment testée pour qu'ils sachent qu'elle ne contient pas de bugs triviaux.
- Encore une fois: n'importe qui devrait pouvoir construire le projet en un seul clic. Ceci est important et permet de tester facilement pour tout le monde. Gros avantage si les non-programmeurs (par exemple le patron) sont capables de le faire aussi. (Cela leur donne l'impression de voir exactement sur quoi l'équipe travaille.)
- Chaque développeur devrait tester la nouvelle fonctionnalité ou le correctif de bogue qu'il ajoute avant ils les valident dans le référentiel.
- Configurez un serveur qui se met régulièrement à jour (à des intervalles prédéterminés) à partir du référentiel et essaie de construire tout dans le projet entier . S'il échoue, il envoie des e-mails à l'équipe avec les dernières validations du contrôle de version (depuis quelle validation n'a-t-il pas été généré) pour aider à déboguer le problème.
Cette pratique est appelée intégration continue et les versions sont également appelées versions nocturnes.
(Cela n'implique pas que les développeurs ne doivent pas construire et tester le code sur leurs propres machines. Comme mentionné ci-dessus, ils doivent le faire.) - De toute évidence, tout le monde doit être familier avec la conception/architecture de base du projet, donc si quelque chose est nécessaire, les différents membres de l'équipe n'ont pas à réinventer la roue. Écrire du code réutilisable est une bonne chose.
- Une sorte de communication est nécessaire entre les membres de l'équipe. Tout le monde devrait être conscient de ce que font les autres, au moins un peu. Plus c'est mieux. C'est pourquoi le standup quotidien est utile dans les équipes SCRUM.
- Le test unitaire est une très bonne pratique qui permet de tester automatiquement les fonctionnalités de base de votre code.
- Un logiciel de suivi des bogues (parfois appelé logiciel de suivi du temps) est un très bon moyen de garder une trace des bogues présents et quelles tâches les différents membres de l'équipe ont. Il est également bon pour les tests: les testeurs alpha/bêta de votre projet pourraient ainsi communiquer avec l'équipe de développement.
Ces choses simples garantissent que le projet ne devient pas incontrôlable et que tout le monde travaille sur la même version du code. Le processus d'intégration continue est utile lorsque quelque chose va terriblement mal.
Cela empêche également les utilisateurs de valider des éléments qui ne sont pas générés dans le référentiel principal.
Si vous souhaitez inclure une nouvelle fonctionnalité qui prendrait des jours à mettre en œuvre et empêcherait d'autres personnes de créer (et de tester) le projet, utilisez les branches fonctionnalité de votre contrôle de version.
Si cela ne suffit pas, vous pouvez également le configurer pour effectuer des tests automatisés, si cela est possible avec le projet en question.
Quelques réflexions supplémentaires
La liste ci-dessus peut être très lourde à première vue. Je vous recommande de le suivre sur une base selon les besoins : commencez par un contrôle de version et un suivi des bogues, puis installez plus tard le serveur d'intégration continue , si tu en as besoin. (Si c'est un grand projet, vous en aurez besoin très bientôt.) Commencez à écrire des tests unitaires pour les parties les plus importantes. Si cela ne suffit pas, écrivez-en plus.
Quelques liens utiles:
Intégration continue , Les versions quotidiennes sont vos amis , Contrôle de version , Test unitaire
Exemples:
Pour le contrôle de version, j'ai tendance à utiliser Git pour mes projets personnels de nos jours. Subversion est également populaire, et par exemple, VisualSVN est assez facile à configurer si vous utilisez un serveur Windows. Pour le client, TortoiseSVN fonctionne mieux pour de nombreuses personnes. Voici une comparaison entre Git et SVN.
Pour les logiciels de suivi des bogues, Jira et Bugzilla sont très populaires. Nous avons également utilisé Mantis sur un ancien lieu de travail.
Pour les logiciels d'intégration continue, il y a Teamcity pour l'un (aussi, CruiseControl et son homologue .NET sont notables).
Répondez à votre question "qui décide de la conception principale du projet?"
Bien sûr, ce serait le développeur principal.
. qui est disponible.
C'est une tâche complexe, et généralement plus d'une personne est impliquée. Parfois, les membres de l'équipe sont également invités à participer ou à réfléchir sur la conception de l'ensemble du projet ou de parties spécifiques.
Je suis également un étudiant, qui a récemment suivi un cours de génie logiciel où tout le semestre a consisté en un projet de groupe géant. Permettez-moi de commencer en disant que nous aurions pu faire avec 3 personnes ce qu'il nous a fallu 12 personnes pendant tout le semestre. Travailler avec les gens est une chose difficile. La communication est la clé.
Utilisez certainement un référentiel. Chaque personne peut accéder à distance à tout le code et ajouter/supprimer/modifier quoi que ce soit. Mais la meilleure partie de Subversion est que si quelqu'un casse le code, vous pouvez revenir à une version antérieure et évaluer ce qui n'a pas fonctionné à partir de là. La communication est toujours essentielle, sachez ce que font vos coéquipiers pour qu'il n'y ait pas de conflits. Ne vous asseyez pas non plus sur votre code, effectuez des validations rapides et significatives dans le référentiel pour être le plus efficace.
** Je recommanderais également un outil de suivi des bogues, tel que Redmine. Vous pouvez configurer des comptes pour tout le monde, attribuer des tâches aux personnes avec différentes priorités, et également suivre et voir si les personnes ont résolu certains problèmes ou si d'autres sont survenus.
Et, comme cela a été dit précédemment, les tests unitaires seront très utiles. Bonne chance! J'espère que cela a aidé :-)
Les grandes choses sont:
- n plan - Si les gens ne savent pas où ils vont, ils n'iront nulle part. Le démarrage de tout projet a donc besoin de quelques personnes (souvent les barbes grises du projet) pour entrer dans un Huddle et élaborer un plan; le plan n'a pas besoin d'être très détaillé, mais il est toujours nécessaire.
- Système de contrôle de version - Sans cela, vous ne travaillez pas ensemble. Vous avez également besoin de l'engagement ferme que si les choses ne sont pas engagées, elles ne comptent pas. "Oh, c'est dans un de mes bacs à sable" n'est qu'une excuse boiteuse.
- Issue tracker - Vous ne pouvez pas garder une trace de ces choses par les dossiers de messagerie. Devrait certainement être soutenu par une base de données.
- Système de notification - Les gens ont besoin de savoir quand les choses sont engagées dans le code qu'ils maintiennent ou lorsque des commentaires sont faits sur les bogues dont ils sont responsables. Le courrier électronique peut fonctionner pour cela, tout comme IRC (à condition que tout le monde l'utilise, bien sûr).
- Build system - Peu importe comment cela se produit, tant qu’une action vous permet d’obtenir une construction complète de l'état actuel des choses, à la fois de votre sandbox de développement et du référentiel principal. La meilleure option pour cela dépend de la ou des langues que vous utilisez.
- Suite de tests - Une suite de tests aide les gens à éviter les erreurs idiotes. Il doit être aussi facile à exécuter que la construction (faire partie de la construction est bon ). Notez que les tests ne sont qu'un substitut brut de l'exactitude, mais ils sont bien mieux que rien.
Enfin, vous avez besoin d'une volonté de travailler ensemble pour réaliser le plan. C'est trop souvent la partie difficile.
En règle générale, il est recommandé de ne pas vérifier les artefacts de génération dans le référentiel. Le référentiel contiendra l'arborescence source, la configuration de la construction, etc. - tout ce qui est écrit par un humain. Les ingénieurs logiciels vont extraire une copie de leur code sur leur système de fichiers local et le construire localement.
Il est également recommandé d'avoir des tests unitaires exécutés dans le cadre du processus de génération. De cette façon, un développeur saura instantanément si ses modifications ont invalidé l'un des tests unitaires et aura la possibilité de les corriger avant de vérifier ses modifications.
Vous voudrez peut-être consulter la documentation d'un système de contrôle de version (Subversion, CVS, Git, etc.) et d'un système de construction (par exemple, en Java il y a Ant et Maven) .
comment les programmeurs travaillent ensemble sur un logiciel dans une entreprise
Les développeurs ne travaillent jamais en équipe. Les équipes sont nulles. Dilbert est drôle non pas parce qu'il est un personnage comique comme Dingo. Il est drôle parce qu'il est réel et les gens reconnaissent les situations dans lesquelles il se trouve.
Il n'y a pas de norme pour les choses que vous demandez. Il existe plutôt des conventions qui dépendent fortement de la taille et de la maturité de l'organisation. Si vous êtes dans une petite organisation, par exemple quelques programmeurs, les choses seront probablement quelque peu informelles, les développeurs individuels effectuant le codage, les builds et les tests.
Dans les grandes organisations, il peut y avoir un ingénieur et un processus de construction dédiés. Ce type d'organisation effectuera généralement une construction formelle sur une base régulière, disons une fois par jour, en utilisant le code source archivé. Le processus comprendra également généralement BVT (Build Validation Tests) et peut-être quelques tests de régression. Les développeurs extrairont le code du référentiel, travailleront sur leur propre partie localement, puis l'archiveront.
Dans les plus grandes organisations, comme Microsoft ou Google, ils auront un groupe entièrement dédié et un laboratoire complet qui s'appuiera sur une base plus ou moins continue, rendant les résultats de chaque exécution disponibles. Ces organisations ont mis en place des processus et des procédures très formels concernant ce qui est enregistré et quand, quels sont les processus de révision du code, etc.
Il n'y a pas de livre de recettes pour travailler avec le développement de logiciels, mais en général, le système de contrôle de version devrait être le cœur de votre système de construction, même si vous travaillez dans un projet où vous êtes le seul développeur. Même dans ce cas, la possibilité de revenir aux versions et de lire le journal des versions est une aide très appréciée pour corriger les bogues. Ce n'est pas la seule caractéristique d'un système de contrôle de version, mais cela justifie à lui seul l'installation, la configuration et la maintenance d'un système de contrôle de version.
La construction peut être effectuée soit par chaque développeur lors de l'ajout de nouveau code, soit périodiquement par un "serveur de génération". La dernière approche nécessite plus de configuration, mais permet de découvrir les erreurs de construction plus tôt.
La réponse courte - "Cela dépend".
Actuellement, je travaille sur un projet par moi-même, donc je suis celui qui construit/utilise VCS. Je connais d'autres endroits où vous avez des équipes travaillant ensemble sur le projet par frisson email. Ou de grandes équipes (+5) utilisant VCS.
Sur cette note, je recommande fortement d'apprendre au moins quelques VCS, et Joel Spolsky a une excellente introduction tutoriel pour Mercurial. Bazaar (mon choix personnel) est similaire, puis Git est le prochain plus proche en termes de similitude, mais probablement plus populaire que l'un ou l'autre (au moins ATM). Après cela, vous avez SVN qui est assez faible en comparaison.
En fait, Joel parle à propos de la plupart de vos questions - je recommanderais de lire les 10 ans d'archives qu'il possède - ce sont toutes des informations très utiles, et la plupart pertinentes à votre situation actuelle et proche.
Tout d'abord, les équipes travaillent en utilisant des référentiels (qui peuvent être un contrôle de version professionnel, ou tout simplement un ensemble de répertoires considéré comme `` en direct '', mais un système de contrôle de révision est la norme de facto). De plus, la façon dont le projet est géré dépend de la façon dont vous travaillez (cascade, agile, etc.). Si vous travaillez par itérations, vous créez des composants/plugins/modules/bibliothèques qui sont autonomes et vous effectuez des tests unitaires jusqu'à ce qu'ils soient approuvés comme terminés. En équipe, vous travaillez en équipe, ce qui signifie que vous ne travaillez pas sur l'ensemble du projet partout en même temps. Au lieu de cela, vous obtenez une tâche à effectuer dans un domaine du projet. À certaines occasions, vous devez corriger du code qui n'est pas le vôtre, mais cela survient généralement lorsqu'un comportement étrange se produit. Fondamentalement, vous testez les pièces que vous développez.
Laissez-moi vous expliquer cela. Vous faites partie d'une équipe de travailleurs de la construction. L'architecte vient avec un plan pour un bâtiment, le contremaître examine les nécessités de la construction puis engage les constructeurs. Le maçon fait les murs, vérifie leur résistance et les colle bien. L'électricien fait tout le câblage à l'intérieur du bâtiment afin que l'électricité puisse circuler. Chaque homme a son propre travail. Parfois, l'électricien peut vouloir discuter avec le maçon si certains murs peuvent être sculptés, mais toujours en collaboration avec le contremaître.
J'espère que cela vous sera utile!
Une bonne programmation est une chose profonde qui bénéficie grandement de l'expérience. La programmation par paires, c'est comme exécuter plusieurs processeurs de prise de conscience ... l'un peut ignorer quelque chose vu par l'autre et tant qu'ils communiquent, cela peut entraîner de grands progrès.
Une bonne introduction à une méthode d'utilisation du contrôle de source est le HOWTO de contrôle de source d'Eric Sink http://www.ericsink.com/scm/source_control.html
Dans ses exemples, il utilise SourceGear Vault depuis qu'il l'a écrit et tout, mais les méthodes peuvent être appliquées à d'autres systèmes de contrôle de version.
En règle générale, le système de contrôle des sources contient le code source et n'a généralement pas les fichiers binaires. Si vous voulez le construire et l'exécuter, vous devriez extraire le code et le construire sur votre machine locale.
Certains endroits exécutent des builds tous les soirs pour s'assurer que tout fonctionne. Il peut même y avoir des tests automatisés exécutés côté serveur. Si la construction ou autre chose échoue, quelqu'un en est automatiquement informé.
C'est encore une bonne raison pour laquelle on devrait se pencher sur les projets Open Source.
Les développeurs principaux qui travaillent dans de grands projets OpenSource (comme Chromium, Mozilla Firefox, MySQL, Popular Gnu Software) sont des professionnels. Ils ont beaucoup d'expérience et ces projets ont évolué au fil des ans avec les idées de centaines de ces professionnels.
Tout ce que les autres ont mentionné dans leurs réponses (Plan, Système de contrôle de version, Suivi des problèmes, Système de notification, Système de construction, Suite de tests,) peut être trouvé dans ces projets OpenSource.
Si vous voulez vraiment une expérience pratique, je vous suggère fortement de passer par quelques grands projets OpenSource populaires, puis d'obtenir la source de n'importe quel projet (en utilisant le contrôle de version) et de le construire vous-même.
PS: Je suis également étudiant et m'impliquer dans des projets OpenSource est la meilleure chose que j'ai jamais faite dans ma vie. Croyez-moi! vous ressentirez également la même chose.