Git et développement d'équipe (pour les nuls)

Co-auteur de l'article: RicardoMilos

Présentation

Salut Si vous êtes venu ici, la question de savoir comment les programmeurs travaillent en équipe vous intéresse. Si auparavant vous ne travailliez qu'en solo, il vous semble probablement que travailler en équipe est plus facile, car il y a plus de mains et cela signifie que vous pouvez faire le travail beaucoup plus rapidement. Mais pas si simple. Nous allons maintenant nous familiariser avec les outils qui sont développés et ce qui se passe au sein de l'équipe.

Git

Vous connaissez sûrement cette situation:



Il s'agit d'un problème de version. En règle générale, un tel problème se produit chez les personnes créatives qui refont constamment tout et atteignent l'idéal. Malheureusement, dans la programmation aussi, loin de toujours, tout se passe bien du premier coup. Imaginez une situation: vous avez compris comment refaire un morceau de code pour qu'il fonctionne un peu plus rapidement. Vous réécrivez, compilez, exécutez et comprenez que le programme ne fonctionne plus du tout. Tout est cassé.

Et ici, vous vous rendez compte que vous n'avez pas enregistré l'option de travail et que le bouton Z de votre clavier est cassé, vous ne pouvez donc même pas spammer ctrl + z. Dans une crise de rage, vous percez le moniteur avec votre main droite pompée. Le soir, vous pleurez, enveloppé dans une couverture, et pensez au sort des programmeurs.

Une situation déplorable ... Et pour éviter que cela ne se produise, vous devez enregistrer des versions de votre code.

Eh bien, les programmeurs sont des gens intelligents, et ils ont parfaitement compris que le stockage de toutes les versions sous la forme d'un tas de fichiers n'est pas pratique autant que possible et qu'il est urgent d'inventer quelque chose qui facilitera le stockage des versions et résoudra ainsi le problème de versioning.

Et ici, nous pouvons faire une analogie avec les jeux. Presque tous les projets AAA ont un système de sauvegarde. Comme bon exemple, le jeu Papers Please.



Autour de la même chose, tous les systèmes de contrôle de version fonctionnent.

Le système de contrôle de version (VCS) est un système qui enregistre les modifications apportées à un fichier ou à un ensemble de fichiers sur une longue période, afin que vous puissiez revenir ultérieurement à une version spécifique.

Classification SLE:

1. Local
2. Centralisé
3. Distribué

Nous avons déjà compris la devise forte locale (ce sont les mêmes tas des mêmes fichiers)

Devise forte centralisée

• serveur central
  tous les fichiers sous contrôle de version
• un certain nombre de clients
  recevoir des copies des fichiers

Exemples:

• CVS
• Subversion
• Perforce

Devise distribuée

1. Les clients copient l'intégralité du référentiel
2. Le serveur central est chargé de fournir la copie principale
3. La synchronisation peut être
   
   • Avec serveur
   • Avec n'importe quel client
   
   

Exemples:

• Git
• Mercurial
• Bazar

Pourquoi ai-je besoin de SLE

1. Stocker toutes les modifications du projet
2. La possibilité de passer "à n'importe quelle étape du projet"
3. La capacité de mener un développement d'équipe simultané
4. Capacité à résoudre des problèmes comme les suivants

Git

Git - Système de contrôle de version distribué
Publié par Linus Torvalds
2005 - première version

Installation:
Linux: sudo apt install git
Windows / macOS: lien

Les développeurs utilisent:

• GNU / Linux
• Android
• Le vin
• Google
• Chrome
• jQuery
• Php
• MediaWiki
• Qt

Concepts de base

Référentiel (référentiel, référentiel) - un endroit où la monnaie forte stocke ses métadonnées et une base de données d'objets de projet
Répertoire de travail - une copie d'une version spécifique d'un projet extraite du référentiel
La zone préparée ( zone par étapes) - un fichier de service contenant des informations sur ce qui devrait être inclus dans la prochaine révision du projet
Révision (révision) - un objet qui stocke la modification de l'état du projet (version du projet)
Valider - créer une nouvelle révision

Configurer GIT

Réglage du nom d'utilisateur

git config --global user.name "Your Name" git config --global user.email you@abc.net 

Les paramètres sont enregistrés dans un fichier .gitconfig caché (dans le répertoire personnel de l'utilisateur)

 [user] name = John Doe email = jdoe@example.com 

Créer un référentiel

 mkdir first_git_repo cd first_git_repo git init 

États des fichiers de projet

1. Fixe
   le fichier est déjà dans le référentiel
2. Modifié
   le contenu du fichier est différent de son état validé
3. Préparé
   un fichier modifié qui sera validé après la création d'une nouvelle révision (ce fichier tombera dans cette révision)

Travailler avec du code

• Initialisation du référentiel
  
  

   git init 

• Ou passer à une révision spécifique
  

   git checkout _ 

1. Changement de code de projet: création / suppression / modification de fichiers
   Dans n'importe quel IDE
2. Afficher le statut
   git status
3. Ajout de fichiers modifiés à l'index
   (transition vers l'état de Staged)
   git add ___
4. Création d'une révision (de Staged à Repo)
   git commit -m ""

Résumer

Travailler avec des devises fortes

Que stocker?

[+] Tous les fichiers de code source
[+] Toutes les ressources nécessaires à la compilation
[+] paramètres de compilation du projet
[-] paramètres du projet dans l'IDE
[-] fichiers compilés à partir de la source
[-] fichiers exécutables

Supprimer de l'index

git rm _

Un commit peut contenir des modifications sur plusieurs fichiers

Quand s'engager?

• Quand j'ai terminé une petite tâche
• Si le problème est important - divisez-le en sous-parties logiques
• Le code doit être opérationnel!

Afficher l'historique

 git log git log --graph 

Numéro de révision = SHA-1 Modifier le hachage

Passer à l'audit

 git checkout sha1_hash git checkout _8__sha1 

Succursales

Une branche est une séquence de commits dans laquelle une fonctionnalité est développée en parallèle

Succursale principale - master

Agences dans GIT

Afficher toutes les branches existantes dans le référentiel

git branch

Créer une branche

git branch

Passer à la succursale

git checkout
Il ne doit pas y avoir de modifications non enregistrées pour le moment.

Créer une branche et y basculer

git checkout -b

Fusionner les succursales

Fusionner les branches - le processus d'intégration des modifications (validations) d'une branche à une autre:

b1 - branche à laquelle nous ajoutons des modifications
b2 - branche à partir de laquelle nous ajoutons des modifications

 git checkout b1 git merge b2 

Afficher l'historique

Utilitaires de fenêtre:

• gitg
• gitk
• gitx
• gitKraken

Supprimer les branches

Supprimer la branche

git branch –d _

SUPPRIMER une succursale

git branch –D _

Ou plutôt, supprimez la branche sans attendre que les validations se déplacent vers le master

Tampon de modification non enregistré

Ou "que faire si vous devez passer à une autre branche et vous engager tôt?"

Écrire les modifications dans le tampon temporaire

git stash

Extraire ces modifications du tampon

git stash pop

Liens utiles:

git-scm.com/book/en/v2
githowto.com/ru
en.wikipedia.org/wiki/version_system

Développement d'équipe

Donc, si vous arrivez à cette ligne, cela signifie que vous avez au moins un petit problème avec git (j'espère vraiment). Mais qu'en est-il du développement d'équipe? Examinons ce problème plus en détail.

Un petit puzzle humoristique:

Étant donné:

• N développeurs
• Lieux de travail
• Termes de référence (TOR)
• Internet

Question:

• Comment réaliser un projet sans attirer l'attention des aides-soignants?

La réponse est:

• Équipe bien coordonnée et travail acharné

Hmm, qu'est-ce qu'une équipe? Comment est-elle?

Une équipe est un petit nombre de personnes:

• avec des compétences complémentaires (quelqu'un programme, quelqu'un conçoit, etc.)
• aspirant à des objectifs communs (ils ont tous besoin de remplir la tâche du client afin d'obtenir une auto-satisfaction complète)
• partager la responsabilité de la réalisation de l'objectif du projet (si soudainement l'un des membres de l'équipe a des difficultés avec ses savoirs traditionnels personnels, alors ses partenaires viendront toujours à son aide (cela ne devrait pas être abusé, sinon vous serez simplement inutile pour l'équipe)).

Une note très importante: dans l'équipe, vous devez vous sentir absolument à l'aise et essayer de vous entendre avec toute l'équipe, sinon tout risque de mal tourner.

Alors maintenant, vous comprenez ce qu'est une équipe. Mais la question suivante qui se pose dans votre tête (oui, oui, les auteurs de cet article peuvent lire dans les esprits): «Et qui est responsable de quoi dans l'équipe? Est-ce que chacun a sa propre place? Ou est-ce que tout le monde fait ce qu'il veut?

Naturellement, chaque participant de l'équipe a son propre rôle et ses propres tâches. Sinon, au lieu de développer un produit, il y aurait du chaos. Regardons les rôles dans la programmation des commandes:

1. Chef d'équipe:
   
   Team Leader est un croisement entre un chef de projet et un développeur qualifié.
   
   Il existe deux rôles principaux sur les projets: gestion - PM et technique - architecte système. Timlid remplit en partie les deux rôles, mais ses responsabilités se concentrent sur la gestion (l'accent sur la partie technique est le responsable technique).
   
   «Chef d'équipe n ° 1: prendre soin de votre équipe. L'équipe doit se sentir à l'aise dans l'environnement de travail et être bien motivée. En outre, le chef d'équipe assure également la croissance professionnelle et professionnelle de ses enfants, organise régulièrement des discussions sur le sujet où les gens sont intéressés à se développer et les aide dans ce domaine. »
   
   Le rôle de gestionnaire du chef d'équipe comprend des responsabilités telles que la gestion, l'attribution et la délégation des tâches, toutes sortes d'évaluations et de planification, le suivi de l'état du projet, ainsi que les réunions, la communication avec le client, la direction et tous les membres de l'équipe (développeurs, testeurs, gestionnaires).
   
   Sous le rôle technique: participation à la rédaction de la documentation technique, la sélection des technologies pour le projet, le développement de l'architecture, la R&D, la révision du code, le mentorat des juniors, la conduite des entretiens techniques, l'implication compétente des nouveaux membres de l'équipe dans le processus de travail, la responsabilité de la partie technique du projet.
   
   Une journée de travail typique de Timlid comprend:
   
   
   • prise en compte des nouvelles tâches et de leur répartition
   • se tenir debout avec une équipe
   • rassemblements
   • programmation
   • problèmes architecturaux
   • examen du code
2. Chef de projet:
   
   Project Manager est un spécialiste dont la tâche principale est de gérer le projet dans son ensemble: conception et priorisation, planification des tâches, suivi, communication et résolution rapide des problèmes.
   
   La responsabilité principale et la responsabilité de PM est de concrétiser à temps l’idée du client en utilisant les ressources existantes. Dans le cadre de cette tâche, PM doit construire un plan de développement, organiser une équipe, mettre en place un workflow de projet, fournir un retour d'informations entre les équipes et le client, éliminer les interférences pour les équipes et contrôler la qualité et la livraison du produit à temps.
   
   Les tâches PM peuvent être classées comme tactiques et stratégiques. Tactique - c'est la solution aux problèmes quotidiens du projet, l'élimination des obstacles de l'équipe. Les plus stratégiques sont de coordonner l'objectif global du projet, le chemin à parcourir, ainsi que la vitesse de déplacement.
   
   «Le principal objectif de PM est:« Nous avons besoin que cela fonctionne », ce qui implique que l'équipe fournira le résultat dans un délai raisonnable avec un niveau de qualité raisonnable.»
3. Testeur:
   
   Un testeur est un spécialiste qui est engagé dans le test d'un produit logiciel afin d'identifier les erreurs dans son travail et leur correction ultérieure.
   
   Les principales fonctions du testeur:
   
   
   • Contrôle qualité des produits développés.
   • Identification et analyse des erreurs et problèmes rencontrés par les utilisateurs lorsqu'ils travaillent avec des produits logiciels.
   • Développement d'autotests et de leur déroulement régulier.
   • Test de développement de script.
   • Documentation des défauts trouvés.
4. Développeurs:
   
   
   • Junior:
     Junior est un développeur débutant.
     
     Après avoir terminé un stage, une personne se transforme en juin à part entière. La principale exigence en est la capacité d'exécuter de manière indépendante des tâches techniques. Si un projet est construit en architecture, il doit immédiatement implémenter un autre élément de la logique d'application typique. Bien que Junior puisse faire des erreurs de temps en temps, ne comprenez pas les nuances, discutez des plans de mise en œuvre avec le chef d'équipe ou vérifiez le code fini avec lui.
     
     Vous devez comprendre que pour les tâches que le signataire résoudra en dix minutes, le juin peut nécessiter trois approches par heure, et dans le processus, le code devra être complètement réécrit, dépensant beaucoup d'énergie supplémentaire. Il est important de ne pas avoir peur de cela et de sentir l'équilibre: quand pousser, essayer de résoudre le problème vous-même et quand, au contraire, arrêtez de vous cogner le front contre le mur, brûlez le temps du projet et demandez de l'aide. Justifier votre manque de performances avec la phrase "Je suis toujours juin" est une mauvaise idée.
   • Milieu:
     
     Moyen - un développeur de niveau intermédiaire.
     
     La principale exigence pour un développeur intermédiaire est la capacité d'exécuter indépendamment les tâches qui lui sont assignées. Très similaire à ce qui était écrit dans le paragraphe précédent, non? Cependant, il y a une mise en garde importante - le mot «technique» manque ici. Autrement dit, à un nouveau niveau, vous devez comprendre les exigences de l'entreprise et être en mesure de les traduire en solutions techniques.
     
     De cette façon:
     
     
     1. Le développeur intermédiaire comprend ce que fait l'application. Cela vous permet de mieux comprendre la tâche et, par conséquent, de l'évaluer plus précisément et de mieux la mettre en œuvre. Si les exigences ne couvrent pas complètement un scénario, un bon développeur en fera attention au stade de la planification. Et pas lorsque l'application commence à se bloquer lors d'une action utilisateur non standard.
     2. Le développeur intermédiaire connaît les modèles et solutions standard lors de la création d'une application dans son domaine, comprend pourquoi ils sont nécessaires et sait comment les appliquer. La standardisation des décisions est d'une grande importance dans le développement collectif du code, car elle permet à une nouvelle personne de comprendre rapidement ce qui est et minimise le nombre d'erreurs. Comprendre la structure d'une application typique rend la tâche de la construire à partir de zéro assez triviale, vous permet de parler des principes de bonne mise en œuvre et de distinguer le bon code du mauvais.
     3. Le développeur intermédiaire comprend que personne ne fonctionne. Il sait comment interagir avec les autres membres de l'équipe: il peut discuter d'un moment difficile avec le concepteur, clarifier des exigences incomplètes avec l'analyste commercial ou coordonner une solution technique importante avec l'architecte de projet (le cas échéant) et, bien sûr, possède les outils appropriés pour le développement de l'équipe.
   • Senior:
     
     Senior est un développeur de haut niveau qui a vu beaucoup de code, a obtenu un tas de cônes et a réussi à en tirer les bonnes conclusions. La tâche principale de Signor est de prendre les bonnes décisions technologiques dans le projet. Les «bons» sont ceux qui maximisent les avantages commerciaux et minimisent les coûts. Un bon signataire comprend non seulement ce que l'équipe développe, mais réfléchit aux tâches que l'application finale doit résoudre. En développant un site pour la vente aux enchères, le signataire s'interroge toujours sur la charge de pointe et essaie de prévoir les tentatives d'écriture compétitive dans les tables de la base de données. Il pense à l'avance aux goulots d'étranglement du système, à la possibilité de le faire évoluer, se souvient des vulnérabilités et des problèmes causés par une mauvaise utilisation des outils.
     
     Un tel spécialiste fait une chose incroyable - résout les problèmes avant même qu'ils n'apparaissent. De l'extérieur, il ressemble au don de prévoyance. Mais si votre projet vit d'un feu à l'autre et que vous devez constamment jeter et réécrire des morceaux de code, ce sont des symptômes que le projet ne reçoit pas suffisamment d'attention des signataires.
5. Concepteur:
   
   Un designer est une personne qui conçoit. Logiquement, n'est-ce pas?
   
   Le travail du concepteur commence bien avant que le premier pixel n'apparaisse et se termine bien plus tard que le dernier.
   
   La plupart des gens sont habitués à croire que le design est en fait un ensemble d'images, de couleurs et de polices qui sont transmises aux concepteurs de mise en page et aux programmeurs pour créer un produit. Parfois, cette approche fonctionne, mais le plus souvent, il s'agit d'un projet, ce qui est alors embarrassant de l'ajouter au portefeuille.
   
   Le fait est que pour résoudre le problème, il ne suffit pas de faire un dessin. Dans le processus, un bon designer passe par 4 étapes. Les voici:
   
   • Comprendre le problème:
     
     Le travail commence par une compréhension du problème, comme un théâtre avec un cintre: jusqu'à ce que vous abandonniez vos vêtements d'extérieur, vous n'irez pas plus loin. Si vous ne plongez pas dans le problème, vous obtiendrez un produit non viable.
   • Rechercher une solution:
     
     Lorsque le problème est clair, il est temps de chercher une solution. En termes établis, ce sont toutes sortes de croquis et de prototypes qui aident à construire une vision préliminaire du produit final.
   • Conception:
     
     Il s'agit simplement de dessiner des images et de sélectionner des polices. De nombreux designers commencent à partir d'ici et terminent immédiatement le travail, et les résultats de leur travail peuvent être vus en grand nombre à Dribble ou à Behans.
   • Approbation:
     
     Même si vous avez une solution mince et élégante dans votre tête et sur le papier, cela ne signifie pas que pour le client, cela aura la même apparence. Si vous omettez cette étape et donnez simplement au client les meilleures pratiques, alors au mieux, elles seront refaites selon votre propre compréhension. Ce qui restera finalement après les modifications du client ressemblera un peu à votre travail.
   
   

Eh bien, maintenant, enfin, vous connaissez tous les postes du développement d'équipe. Ici, je n'ai répertorié que les messages liés à la programmation. Si nous considérons le développement d'un produit logiciel comme un projet d'entreprise, alors bien sûr, il y aura plus de rôles ajoutés, par exemple, comptables, spécialistes du marketing, etc.

Conclusion

Eh bien, si vous lisez jusqu'à ce point - félicitations, vous êtes incroyablement cool! Non, eh bien, vraiment, votre cerveau n'a pas encore bouilli avec autant d'informations? J'espère que non.

J'espère donc que notre article vous a aidé à comprendre toutes les subtilités du développement d'équipe. Et vous n'avez plus de questions sur ce sujet. Et quand vous arrivez dans une entreprise super-duper-irréelle-cool-et-célèbre et que vous serez embauché (si seulement ils essaient de ne pas accepter), alors vous ne serez pas confus et montrez à votre patron qui est le programmeur principal. Ou peut-être allez-vous créer votre propre entreprise, qui sait ;-)

Merci de votre attention!

PS

L'article a été préparé par des étudiants de la MSHP (Moscow School of Programmers) , sur la base de conférences du cours de programmation industrielle.