Dans cet article, je parlerai des problèmes rencontrés par notre équipe Scrum Front End pendant une année de travail sur un projet décent. Nous avons commencé à développer le projet à partir de zéro en utilisant la pile technologique React + Typescript. Avec le recul, je constate que plusieurs millions de personnes ont été gaspillées simplement parce que le processus de développement n'a pas été défini dès le départ. Mais il y a des raisons à cela.
Il fallait d'abord remporter l'appel d'offres. Pour ce faire, il était nécessaire de déposer rapidement un produit de valeur minimale. Et c'est là la première erreur qui a coûté un montant décent à notre client. Cela ressemble à ceci: entaille rapidement MVP. Le client veut voir rapidement le résultat, mais cela signifie que nous sacrifions une bonne infrastructure, une architecture fiable et un an plus tard, nous sommes arrivés à la conclusion que notre architecture frontale nécessite une refonte sérieuse. Environ quelques mois. Nous avons donc divulgué 500 000 roubles.
Avec le recul, je peux dire avec confiance que la première chose à faire a été de prendre en compte toutes les fonctionnalités que le client voulait voir au bout de quelques années. Ainsi, nous pourrions éviter les erreurs architecturales dans le style de "cette architecture ne prévoit pas cela." En conséquence, chaque puce majeure nécessitait une refactorisation sérieuse.
Afin de remporter l'appel d'offres, notre société a envoyé des développeurs qui n'avaient pas d'expérience dans la conception de grandes applications et de systèmes extensibles fiables. Affaires claires, l'appel d'offres n'est pas une commande, et personne ne veut disperser un bon personnel. Mais le manque d'architecte technique au (niveau de la classe) a conduit au fait que notre application s'est transformée en code spaghetti et a cessé de satisfaire aux exigences SOLID. Et là réside l'erreur de chaque client. Il n'est pas possible de maintenir un rythme de développement constant sans augmenter les ressources de l'équipe. Le principe Agile «Les investisseurs, les développeurs et les utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment» ne fonctionne que dans le cas où si les exigences étaient connues et élaborées dès le début, l'ensemble des fonctionnalités, une architecture fiable et extensible ont été conçues (en un mot, si chaque classe a été pensée en tenant compte de la finale fonctionnalité du système) et des processus clairement définis. Et cela devait être fait en MPV avant de scier le produit. Sinon, avec un temps linéaire, la complexité de l'application croît de façon exponentielle. Cela signifie que la fonction d'entaille dans une année coûtera O (e (N)) plus cher qu'au début.
Dans notre équipe, le seul designer était un employé à distance. Ce fut une grave erreur. Un employé distant vit toujours sa propre vie. Il dessine un dessin pour lui-même, magnifiquement et bien, le client est content. Mais tous ces charmes se résument finalement au fait que sur les mêmes formes logiques, nous avons N styles et dispositions différents. Dès le début, cela valait la peine de mettre une exigence: styliser un certain cadre (nous avions Ant Design). Si quelque chose n'est pas là, faites ce qui est là. Le client pensait que React était un constructeur de blocs. Et il ne comprend toujours pas pourquoi nous scions des formes primitives depuis 4 jours. React est un constructeur, mais seulement si au tout début du développement nous avons un ensemble de composants réutilisables similaires (framework UI). Un concepteur sans expérience en aménagement ne le fera jamais lui-même. Le développeur n'en parlera jamais au client. Cela devrait être suivi par le leader. Le leader de l'équipe Front End devrait donc être le développeur Front End dans le passé, et non le Back End comme toujours. Par conséquent, nous arrivons à la conclusion qu'une équipe Agile pleinement fonctionnelle devrait inclure un leader compétent dans chacun de ses domaines de travail (FE, BE). Ces leaders doivent avoir de solides compétences non techniques afin de transmettre au client ce que j'essaie de décrire dans cet article. Et c'est très, très difficile.
Lorsque nous avons sorti la première version, nous avons réalisé que quelque chose se cassait constamment le dernier jour avant la démo. Tout au long de l'année de développement, chaque branche de sortie se transforme en un ensemble infernal de béquilles (éteignez-le, retirez-le) qui se retrouvent ensuite comme par magie dans la branche de développement. Et il y a une série de validations (activez-la, activez-la). Après un an, nous sommes arrivés à la conclusion que nous devons avoir une politique de branchement claire. Mais surtout, une personne responsable qui éliminerait le chaos existant. Cela signifiait: soit modérer les désirs chaotiques du client, soit modérer les bogues chaotiques, ou à chaque stand ont leur propre configuration désactivant une sorte de fonctionnalités graphiques ou de boutons. Envelopper chaque bouton dans une instruction if est fou. Nous sommes arrivés à la conclusion que nous avons besoin d'une architecture frontale modulaire et plug-in (désactiver - activer). Je réfléchis depuis longtemps à la réalisation d'une telle architecture. Mais une chose que je comprenais à coup sûr. Nous avions besoin d'un contexte complet. La bibliothèque js-beans est donc née (https://www.npmjs.com/package/js-beans). Chaque stand avait son propre contexte json. Les plug-ins ont été collectés dans une chaîne (chaîne) via le modèle de proxy. Ainsi, par exemple, nous avions une source de données en tant que bac séparé, et diverses transformations ont été effectuées en tant que bacs proxy facultatifs remplaçant ce bac, mais en l'injectant en lui-même. Par exemple, si vous avez besoin de mettre à l'échelle le modèle de données pour tester les performances FPS, j'ajoute simplement la ligne pour activer le plug-in de mise à l'échelle dans le fichier json. Quelque chose s'est cassé sur la production, mais ça ne joue pas localement, j'allume l'enregistreur avec une seule ligne sans reconstruire le stand (le stand prend environ 20 minutes, et une dizaine de stands ne suffit pas toujours pour tout le monde). Ou si vous devez désactiver rapidement un module car il peut être cassé (désactivez le bean optionnel dans le contexte).
Au fil du temps, les stands ont été fermés pendant une semaine. Il était impossible de développer le front localement. Nous n'avons pas prévu d'architecture autonome sur les mokas. J'ai dû l'entailler à travers la douleur avec un grincement. Avec le recul, je l'aurais fait au tout début. Mais nous avions MVP, et nous avons été obligés d'écrire du code sans ingénierie approfondie. Mais le client nous considérait comme des professionnels et pensait que nous devions immédiatement écrire du code sans erreur. Voici l'erreur suivante. Le nom de l'entreprise ne parle pas du professionnalisme de l'équipe. Le professionnalisme de l'équipe est déterminé par le professionnalisme du chef d'équipe. S'il n'y a pas de responsable technique dans l'équipe, votre projet s'arrêtera dans un an. Vous fusionnez donc quelques millions de plus.
Nous avions un architecte distant. Mais une seule chose était connue de lui: il l'est. La dernière étape du développement du leader selon Vladimir Tarasov. En cela, notre architecte a atteint la perfection. Erreur numéro N: vous n'avez pas d'architecte technique qui conçoit le système au niveau de la classe. Vous n'avez personne pour demander de l'aide si vous êtes à l'arrêt. Demandez l'aide d'autres équipes plus expérimentées, nous a dit le client. Mais pour une raison quelconque, les autres équipes n'ont jamais eu le temps de nous aider. Notre RP est suspendu depuis le deuxième mois. J'espère sincèrement qu'il y aura un homme courageux qui l'approuvera. En conséquence, la vie a récompensé notre code avec une riche abondance de phénomènes paranormaux sous forme de magie et de jeux de béquilles pour toutes les occasions. Un seul manquait. Annotations spéciales
Magic et @Kostyle. Bonne idée pour le prochain ES.
Nous avons décidé que plus de moyens et moins d'hommes étaient plus rentables pour le projet. Maintenant, nous pensons différemment. Si vous avez un petit budget, vous devez engager les spécialistes les plus chers. Si vous, comme le nôtre, n'avez pas de problèmes budgétaires, vous pouvez économiser en toute sécurité sur des spécialistes et transformer la révision de code en une bataille de médiums.
Nous pensions que nous respecterions les délais trimestriels. Maintenant, nous pensons différemment. Bref, pour de bon, il faut réécrire le projet. Et de préférence à partir de zéro. J'espère que notre client ne le saura jamais. Après tout, nous avons récemment eu un magnifique team building)
Nous avons décidé de jouer avec les nouvelles technologies dans lesquelles nous avions peu d'expertise. Ils nous ont été recommandés. Bien sûr, nous voulions acquérir de l'expérience. Maintenant, je pense qu'il serait préférable de n'utiliser que les technologies dans lesquelles j'ai de l'expérience.
Nous avons donné des estimations basées sur une journée de travail de 8 heures. En réalité, les estimations devraient être données sur la base d'une journée de travail de 4 heures. Pourquoi personne n’inclut du thé, raconte des histoires intéressantes, cherche des toilettes sur le navigateur, parle au téléphone, de la correspondance, étudie les nouvelles technologies et, surtout, des disputes enthousiastes au sein de l’équipe. Ce dernier est probablement le plus inévitable et le plus cher. Bien que, pour être honnête, pour Open Space, vous devez encore jeter quelques heures. Parler constamment réduit considérablement la concentration. Béni soit le client qui comprend tout cela!
Nos estimations étaient épuisantes et transformées de toute façon en une polémique technique fastidieuse. L'efficacité des rassemblements a été minime. Mais nous avons trouvé une solution: une délicieuse pizza. Lorsqu'une délicieuse odeur irrite le nez, une personne commence à exprimer ses pensées plus clairement.
Au début, nous avions une petite équipe, puis une grande équipe. La planification a pris 2 à 3 heures. Debout 30 minutes. Pour ce que je respecte notre bon de commande, c'est parce qu'il a décidé de le diviser en plusieurs petits et d'attribuer son propre mini bon de commande dans chacun d'eux. Ce fut probablement la meilleure décision de l'histoire de notre projet.
Dès le début, nous n'avons pas eu le temps d'écrire des tests. Après six mois, nous sommes arrivés à la conclusion qu'ils devaient encore être écrits. Mais nous ne trouvons toujours pas de temps pour cela. Une dette technique de priorité beaucoup plus élevée s'est accumulée. Ne sauvez pas la dette technique - c'est de l'utopie. Il le sera toujours.
Mes conclusions subjectives personnelles:
- Si vos développeurs ne comprennent pas à quoi sert IOC pour FrontEnd, alors très probablement quand ils comprendront qu'il sera trop tard.
- Si vos développeurs ne comprennent pas pourquoi FrontEnd a besoin de connaître la POO, alors votre code peut difficilement être pris en charge.
- Les spécialistes moins chers valent mieux que les plus rentables.
- Si vous avez un architecte, il vous en faudra probablement un de plus.
- Si vous sciez MVP, terminez-le et changez le projet.
- Si MVP a déjà été enregistré avant vous, ne passez pas à ce projet.
- Si vous coupez MVP et ne voulez pas partir, vous changerez probablement d'avis.
- Si vous zapilili MVP et que vous voulez que votre projet survive, réécrivez-le à partir de zéro.
- Si vous montrez cet article à un client, vous serez probablement renvoyé.
- Si vous travaillez sur Agile, vous me comprenez très probablement.
Il est peu probable que vous évitiez tous ces problèmes même après avoir lu cet article. Mon objectif est de vous montrer que c'est inévitable. Et peu importe vos efforts, vous n'aurez jamais de conditions idéales. Alors préparez-vous à cela. Et avant le licenciement, vous pouvez montrer cet article en toute sécurité à votre client. Qu'il soit moralement prêt pour cela.
PS: Maxim, si vous avez déjà lu cet article, sachez que tout ce que j'ai décrit est complètement fictif et n'a aucune ressemblance avec notre projet) Mais tout cela n'est pas important, car aujourd'hui je pars en vacances. Les premières vacances d'une année de travail laborieux et irrégulier! (en tant que leader FE).