Incroyable, votre produit fonctionne toujours

Maintenant, je vais vous dire le secret de la porte ouverte. Prêt?



La plupart des logiciels sont très mal écrits. En même temps, ils y gagnent de l'argent. Il peut avoir des millions d'utilisateurs, peut être traduit en plusieurs langues, cependant, du point de vue du code source et de l'architecture, être une compilation de merdes d'antipatterns et de code spaghetti qui s'effondreront à la première demande incorrectement générée.

En est-il ainsi, pourquoi et quoi faire.

Rapidement pour ceux qui pensent qu'il a un produit qui lui convient et que vous ne pouvez pas lire plus loin.

D'abord pour les techniciens. Répondez vous-même: vous suivez les principes du code propre, SOLIDE, SEC et tout ce qui est écrit dans les articles et bien sûr vous n'avez pas de valeurs magiques dans le code. Vous avez vraiment une couverture de test à 100%, vous avez un CI / CD automatique honnête, votre REST utilise tous les codes HTTP nécessaires, pas seulement 200, 201 et 404. Tous les points de terminaison et la dette technique minimale sont parfaitement décrits, et le code hérité est refactorisé juste là ? Sinon, vous avez tout compris vous-même. Et je ne parlais toujours pas de surveillance et de beaucoup de choses.

Maintenant pour les managers. Les gars, vous ne travaillez pas sur une cascade, n'est-ce pas? Eh bien, votre mêlée est honnête, vous n'assimilez pas les points d'histoire à des heures ou des jours et planifiez le poker, discutez du résultat, non? Et vous n'avez certainement aucune tâche de blocage dans le sprint et la définition de done, et après la mise en œuvre, la tâche entre immédiatement en production. Vous avez une feuille de route du produit, la documentation et les tâches transmises aux développeurs contiennent plus de trois mots et décrivez pourquoi nous faisons cela, ce que nous faisons, comment tester et ce qui en résultera. Et toutes les analyses de rentabilisation sont décrites ... Et ce ne sont que quelques choses qui doivent être faites, nous le savons tous.

Ceux qui ont tout cela, vous pouvez terminer la lecture de l'article. Vous avez déjà un très bon produit. Envoyez-moi une référence, si c'est facile, je regarderai avec plaisir.

Pour ceux qui sont encore là, et je pense que la plupart d'entre vous, comprenons pourquoi cela se produit et pourquoi cela convient à tout le monde.

Cela se produit parce que les gestionnaires ne comprennent le plus souvent rien de foutu dans le développement. Ils comprennent le ROI et les KPI, ils ont reçu des MBA, et s'ils ont des antécédents tels qu'une éducation semi-spécialisée, ils ne sont pas allés plus loin que le conditionnel Hello World. En général, leurs délais sont respectés et décomposer correctement une tâche en MVP, sans connaissances techniques, est assez difficile. Cela ajoute l'aversion des programmeurs aux gestionnaires, ils ne les aideront évidemment pas. Il reste donc aux managers à écrire des histoires ou des romans à des histoires et à trouver des mesures indirectes afin de comprendre si telle ou telle tâche a été exécutée qualitativement. Oui, seules toutes ces métriques sont synthétiques, elles n'ont rien à voir avec la qualité du développement, ou très indirectement.

Et qu'en est-il des développeurs. Oui, en fait rien, la plupart d'entre eux ne veulent rien, elle sait déjà que ces lettres signifient. Le gestionnaire ne comprend toujours rien, alors ici, nous utilisons quelques antipatterns et collons quelques béquilles, commençons la compilation sans tests, mais pourquoi les démarrer, ... et allons prendre un café. Tout a été décidé sur l'expérience, pour ainsi dire. Eh bien, mais le fait qu'ils aient interrompu le déploiement, cela n'a pas d'importance, nous allons le retourner avec nos mains.

Presque personne ne veut comprendre la théorie, dans l'industrie, il y a beaucoup de ceux qui n'ont aucune idée du fonctionnement de son cadre, mais savent seulement quelle méthode utiliser. Pour ainsi dire, utilisez la magie. En raison du manque de développeurs, le niveau de professionnalisme a considérablement diminué.

Je comprends que personne n'aime la critique, mais une telle approche est très proche. Ils ne le feraient pas de cette façon, il n'y aurait pas ce que j'ai décrit dans les premiers paragraphes.

Maintenant, pourquoi cela convient-il à tout le monde? Oui, oui, cela convient à tout le monde. Ceux qui ne sont pas satisfaits de cela, soit ne travaillent pas sur ces produits, soit les refactorisent et les ramènent à leur forme normale.

Cette situation convient aux managers car ils ne comprennent même pas l’ampleur des problèmes. Le produit est arrivé et d'accord, et les utilisateurs trouveront des bogues le matin. Ils ont écrit dans le rapport, obtenu une tique, le chef a fait l'éloge. Ils ne sont pas exagérés, donc les programmeurs sont à blâmer. En général, quand il y a quelqu'un à pousser, rien ne doit être amélioré.

Pourquoi cela convient-il aux programmeurs? Probablement parce que beaucoup ne peuvent pas faire mieux, car pour faire mieux, vous devez constamment travailler sur vous-même. Et pour beaucoup, il n'y a même pas de question: pourquoi, si l'argent est déjà payé. Vous lisez ebanoe.it, il est directement conseillé de travailler tout autant pour ne pas être expulsé. Et cela ne veut rien dire.

Il s'avère donc un cercle vicieux, certains ne peuvent pas, d'autres ne veulent pas.

Que dois-je faire avec ça? Chaque jour pour se développer. Améliorer les tâches, les approches, appliquer les meilleures pratiques et principes. En désaccord avec le fait qu'on vous propose de fouiner dedans. Faites en sorte que vous n'ayez pas honte de montrer votre projet à des étrangers. Et faites-le des deux côtés. Il n'y a pas d'autre recette.