Par un traducteur: nous publions pour vous
un article du développeur Jack Finlay. Jack parle de son propre cas - une tentative d'organiser le travail en équipe de juniors, où tout le monde est égal et sans responsable technique. Cet article sera utile aux programmeurs débutants.
Certains projets peuvent s'immobiliser et se terminer par rien pour un certain nombre de raisons. Les conseils techniques font souvent défaut. Ce problème peut conduire à un fiasco. Une fois c'est arrivé avec un projet au développement duquel j'ai participé.
Skillbox recommande: Cours pratique de deux ans "Je suis un développeur Web PRO . "
Nous vous rappelons: pour tous les lecteurs de «Habr» - une remise de 10 000 roubles lors de l'inscription à un cours Skillbox en utilisant le code promo «Habr».
Le temps peut vous apprendre beaucoup. Malheureusement, nous acquérons de l'expérience en travaillant non seulement avec des projets réussis, mais aussi avec des projets infructueux.
Expérience personnelle et leadership
Plus précisément, son absence. Il n'y avait ni développeur principal ni développeur principal dans notre projet. En principe, il était déjà clair ce qui allait arriver à notre travail, mais à l'époque nous ne comprenions pas cela.
L'équipe n'avait aucune expérience. Nous étions presque tous étudiants et personne ne pouvait nous guider. Ensuite, cela ne nous a pas paru nécessaire.
Au cours d'un été, le nombre de membres de l'équipe a quintuplé. Un problème? Tous étaient à peu près du même niveau professionnel. Tout le monde manquait d'expérience. Nous nous sommes scindés en plusieurs groupes, chacun étant responsable de quelque chose.
De plus, presque tous les participants au projet étaient de bonnes personnes en charge. Mais c'était notre premier projet commercial. Mon équipe était très bonne, nous avons parfaitement fonctionné, mais le résultat a été un échec.
Boîte à outilsLes outils constituent un élément clé du travail de tout professionnel. Sans les bons outils, un flux de processus normal est impossible. Une bonne équipe a généralement un leader qui sait qui a besoin de quels outils et où les obtenir.
Bases de donnéesDans ce projet, nous avions accès à une base de données partagée hébergée sur une machine virtuelle, l'une des plus lentes pouvant être obtenues. Naturellement, nous avons expérimenté tous les «plaisirs» d'un tel travail: perte de données, chute de tables, actions simultanées sur les mêmes éléments. Tout cela a ralenti notre travail.
Nous n'avons pas pu reproduire la base de données localement ou dans le cloud sans effectuer l'opération de sauvegarde et de restauration. Il n'y avait aucun moyen d'obtenir une base de données «propre» dans le même état dans lequel nous aimerions la déployer dans différents environnements. La base de données ne peut être créée qu'en tant que clone à partir de la base de données de notre serveur.
Mais le projet ne fonctionnait qu'avec la base de données, qui se trouvait sur le serveur de production. Cela signifiait que nous ne pouvions pas tester la base de données et le projet en fonction localement. Plusieurs fois, une situation est survenue lorsque nous avons dû faire reculer la base jusqu'à un certain point, car la nuit, quelqu'un l'a détruite par des actions imprudentes. Cela a considérablement entravé le processus de développement.
La migration et la mise à jour de la base de données ont été effectuées manuellement. Cela signifiait ... oui, nous perdions encore du temps.
Maintenant, il semble évident que les développeurs devraient avoir des bases de données locales sur leurs machines. De plus, vous devez utiliser des outils de migration automatisés. Cela donne aux développeurs la liberté et la marge de manœuvre dans certaines situations.
PerformancesLes développeurs ont besoin de hautes performances à la fois sur les machines locales et sur le serveur sur lequel le projet est testé. Mais comme nous avions des outils lents, nous ne pouvions même pas en rêver.
Beaucoup avaient des appareils extrêmement lents qui étaient utilisés depuis de nombreuses années. Claviers, pavés tactiles - tout cela portait l'empreinte du temps.
Les serveurs étaient également lents, comme je l'ai mentionné ci-dessus. En conséquence, l'ensemble du processus de développement s'est ralenti. Les tests ont également progressé lentement.
La conclusion est simple, dans le style de l'identité d'entreprise, est de donner au développeur l'équipement et les ressources dont il a besoin pour le processus de développement normal.
Contrôle de source
C'était généralement le chaos. Nous avons utilisé un système de contrôle des sources d'entreprise, mais le problème n'était pas dans le logiciel. Il n'y avait tout simplement pas de stratégie. Des équipes de développement distinctes ont travaillé chacune "dans leur propre marais", et nous ne nous sommes pas entendus sur le moment où nous fusionnerions les brunchs individuels. Le résultat est ce qui s'est passé: conflits, conflits lors de la fusion partout. J'ai dû passer beaucoup de temps à résoudre des problèmes et une bonne synchronisation.
Intégration et déploiementNous n'avions généralement pas de solutions CI / CD. Le déploiement a été simple: nous avons copié les ressources du dossier intégré et les avons collées sur le serveur à l'aide de Remote Desktop. Si vous avez fait quelque chose de similaire, vous pouvez comprendre ma douleur.
Pour ceux qui n'ont pas rencontré de problème: si vous avez autre chose que les fichiers nécessaires dans le tampon, cela tuera le téléchargement des fichiers sur le serveur. Si quelqu'un d'autre de l'équipe rejoint le serveur pour télécharger des fichiers, vous aurez des problèmes. De plus, certains fichiers peuvent être transférés corrompus.
Mon conseil est de choisir une solution CI / CD pour vous-même.
Contrôle qualité
Un autre élément important du processus de développement est le contrôle de la qualité.
Examen par les pairsCe travail était avec nous que les membres de l'équipe se sont réunis et ont examiné le travail accompli. Et parfois, nous n'avons même pas regardé le code, donc un grand nombre d'instants se sont écoulés. Un autre problème était que nous n'avions pas d'expérience, ce qui signifie comprendre ce qu'est un bon code. Nous n'avons pas pu isoler immédiatement les erreurs dans le code qu'un développeur expérimenté voit immédiatement.
Si l'équipe avait un développeur senior, il serait immédiatement en mesure de nous faire savoir où sont les problèmes et comment y faire face. Mais il n'était pas là, nous travaillions indépendamment.
TesteursNous ne les avions pas non plus. Nous avons effectué les tests nous-mêmes. Encore une fois sans expérience. En conséquence, un temps précieux a été consacré à la capture et à l'élimination des bogues.
Si vous voulez du bon code, vous avez besoin de testeurs et de testeurs professionnels. Les développeurs ne font pas toujours face au problème des tests de logiciels.
Qualité du code
Beaucoup d'entre nous au début du voyage sont des représentants de la culture du «copié-passé». Cela signifie que le développeur recherche les solutions nécessaires pour le projet sur Stackoverflow et insère la pièce trouvée sans pincement de conscience. Le résultat n'est pas un très bon code, qui est pratiquement illisible et que les développeurs ont du mal à expliquer complètement. Même la personne qui a copié un site particulier ne peut souvent pas comprendre son travail.
Je ne peux que conseiller une chose: si vous copiez le code, vous devez bien le comprendre. Sans cela, un projet normal ne peut pas être réalisé.
Code de spaghettiUne mauvaise compréhension de l'architecture du projet a conduit au chaos complet. Le code spaghetti est une description douce de ce qui s'est finalement produit.
Certaines sections sont passées par différentes mains, de différents développeurs, chacune ayant ajouté quelque chose de différent. Le code final du projet était un ensemble d'idées et de «béquilles».
Nous n'avions pas de système d'injection de dépendances et nous n'avons utilisé aucun modèle de conception commun. Cela a conduit à beaucoup de mauvais code qui a juste commencé à "pourrir".
Que puis-je dire? La lisibilité du code est tout aussi importante que son bon fonctionnement, et ces deux choses vont de pair. Un style clair et cohérent et un code cohérent fournissent le résultat le plus efficace.
Conclusion
De nombreux problèmes ont surgi en raison de notre manque d'expérience. Nous ne savions tout simplement pas comment travailler sur le projet. Nous n'avons pas pu implémenter correctement l'environnement. Nous n'avions pas les outils et les technologies nécessaires.
Un bon chef d'équipe résoudrait tous ces problèmes. Il aurait prévu bien à l'avance.
Soit dit en passant, le projet lui-même n'était pas le pire de ce qui pouvait arriver. J'ai rencontré de nombreux futurs collègues avec qui j'ai communiqué jusqu'à présent. J'ai l'expérience nécessaire pour travailler en tant que pro. Et j'ai réalisé que sans un leadership approprié, même l'équipe la plus compétente ne réalise pas son plein potentiel. Jamais.
Skillbox recommande: