Bonjour, je m'appelle Dmitry Karlovsky et je suis un cycliste professionnel. Au cours de ma carrière, j’ai fait un tas de vélos: petits et grands, rapides et confortables, tordus et droits. Par conséquent, c'est assez fou pour moi de voir des programmeurs intelligents créer des applications grandes et complexes, mais en même temps connecter un autre pavé gauche au projet, au lieu d'écrire quelques lignes simples de mes propres mains. La raison en est la peur des vélos en production qui s'est développée chez les programmeurs et qui se soutient.

Programmeur Evolution

Pour simplifier la présentation, nous distinguons 3 groupes conditionnels de programmeurs. Conditionnel, car il n'y a pas de frontière claire entre eux, et la même personne dans différentes régions peut appartenir à différents groupes.

Débutant

• Il a encore peu d'expérience et de connaissances, mais il en apprend rapidement de nouvelles, car il n'a pas encore établi d'habitudes.
• En raison de l'effet de nouveauté, il voit bien les lacunes des solutions existantes et a un fort désir de faire le sien sans ces lacunes.
• Il ne sait pas comment et pourquoi ces pratiques et principes ont été formés, et s'il le fait, il n'a pas ressenti les raisons de leur apparition sur sa propre peau.
• La plupart du code écrit par lui est soit jeté, soit refactorisé au-delà de la reconnaissance. Au mieux, de ses propres mains sous la direction de collègues plus expérimentés.
• Il est impitoyablement battu pour avoir écrit des vélos parce qu'une bibliothèque tierce est plus susceptible de se révéler meilleure en termes de nombreux critères.

Spécialiste

• La grande majorité des bibliothèques populaires ont été écrites par lui pendant son temps libre à partir de son travail principal, car elles se battaient encore les mains pour les vélos et pour ouvrir les codes source.
• En règle générale, la qualité de son code correspond à la qualité moyenne du code dans l'écosystème. Si tout le monde écrit des nouilles à partir de rappels, alors rien ne lui reste.
• En règle générale, il utilise du code tiers, car le sien n'est pas beaucoup mieux, voire pire, en raison de limites de temps.
• En conséquence, il continue de recevoir des mains sur les vélos de manière explicite (lors d'une révision de code) ou implicite (rapports de bogues).
• Quand un problème l'obtient complètement, il scie un vélo. Et comme il existe une majorité de ces programmeurs, il s'avère que 100 500 vélos ne sont pas compatibles entre eux, pris en charge par un développeur et demi.

Professionnel

• Il est capable de résoudre n'importe lequel des problèmes mieux que la moyenne de l'hôpital, mais en raison des ressources limitées, il est obligé de choisir à quoi consacrer du temps.
• Par habitude, ils l'ont frappé aux mains. Surtout si l'entreprise pratique la mêlée, où toutes les décisions sont prises à la majorité, sous réserve de l'effet Dunning-Krueger.
• Souvent à cause des complexes formés au cours des deux premières étapes, il se limite et pense qu'il n'est pas en mesure de faire mieux qu'une bibliothèque tierce qui est "testée", "pensée", "soutenue par un grand nombre de développeurs".

Les causes de la peur

Suite à l'évolution du programmeur, il est facile de remarquer qu'au début il a peu de compétences, mais pas de peur, et à mesure qu'il acquiert des compétences, la peur des vélos apparaît et s'intensifie. Pour faire face à cette peur, vous devez analyser ses causes.

Je ne peux pas faire mieux

Un débutant ne peut vraiment pas. Il devrait diriger ses efforts pour expliquer l'essence et l'importance des problèmes qu'il voit avec son regard neuf à des collègues plus expérimentés et des développeurs de bibliothèques.

Un spécialiste ne réussira probablement pas pire s'il connaît bien les problèmes et consulte d'autres spécialistes et professionnels.

Un professionnel est capable de faire mieux dans la plupart des cas, car il connaît déjà bien le sujet et a même la capacité d'analyser de manière approfondie. Malheureusement, il n'y a généralement personne pour le consulter, car il y a peu d'autres professionnels et ils sont engagés dans d'autres sujets. Et les spécialistes manquent d'horizons.

Il n'y aura personne pour réparer les défauts

Habituellement, l'auteur du vélo est bien motivé pour réparer les défauts de son idée. Mais tôt ou tard, cette motivation passe, s'il le fait après les heures. Et ici, une bibliothèque tierce, semble-t-il, vous permet d'économiser des ressources, car d'autres personnes qui n'ont pas à payer sont engagées dans son support. Mais il n'est pas possible de les influencer, et donc pour respecter le délai, vous devrez retrousser vos manches et corriger le défaut vous-même, après quoi il sera long et difficile de casser votre patch dans le référentiel principal, sans aucune garantie de succès.

Personne ne s'améliorera et ne se développera

Ici, la situation est la même qu'avec des défauts. Mais si avec des défauts, il est généralement clair pour tout le monde qu'ils doivent être réparés, alors la vue sur la direction du développement est différente pour tout le monde. Un développeur tiers développera sa bibliothèque là où il en a besoin, et pas pour vous. À la vitesse qui lui convient et non à vous. Donc, si un vecteur de développement spécifique est requis, votre vélo vous donne le contrôle et la prévisibilité - deux qualités qui sont beaucoup plus importantes pour la gestion que le temps et l'argent.

Je ne peux pas l'utiliser ailleurs

Si vous souhaitez utiliser le vélo en dehors de l'entreprise, vous devrez le développer soit pendant votre temps libre, soit convenir de l'ouverture de la source, ce qui est généralement plus difficile, mais tout à fait possible. Après tout, l'entreprise reçoit des RP presque gratuitement parmi les employés potentiels, ainsi que des bêta-testeurs gratuits (ou même des contributeurs, mais vous ne devriez pas vous fier à cela) en la personne d'autres utilisateurs de vélos.

Du temps et de l'argent seront gaspillés

Ici, tout d'abord, il vaut la peine de comparer avec des alternatives. S'il n'y en a pas, alors il n'y a pas d'autre choix - vous devez le couper. S'il existe des alternatives, il vaut la peine de comparer en termes d'argent et de temps:

• Le coût d'écriture de votre vélo est de bonne qualité. Cela comprend le temps réel d'écriture du code, ainsi que la rédaction des tests, le transfert du projet sur un vélo et l'évaluation du coût des défauts introduits.
• Les avantages d'un vélo. Il peut s'agir d'économies en raison de certaines fonctionnalités, de moins en moins de défauts et d'autres facteurs.
• Le coût de l'intégration d'une solution tierce. Encore une fois, y compris une évaluation du coût des tests et des défauts introduits.
• Restrictions imposées par une solution tierce. Il peut s'avérer qu'une solution tierce ne convient pas du tout. Ou qu'il ralentira le développement de 2 fois.

Il convient également d'évaluer séparément le coût du passage d'une solution tierce à un vélo, s'il s'avère soudain que certaines des restrictions sont plus inacceptables. Il arrive souvent qu'il soit plus rentable maintenant d'implémenter une solution tierce, puis de la transférer rapidement sur votre vélo quand (et si) vous en avez besoin, que de passer du temps sur la construction de vélos maintenant.

Cette évaluation permet à la fois de comprendre si le jeu en vaut la chandelle et d'expliquer à la direction pourquoi il vaut la peine d'écrire le vôtre et de ne pas prendre celui d'un autre (ou vice versa).

Je serai maudit comme j'ai maudit mon prédécesseur

Il est douteux que la moto ait occupé une part importante du projet. Ils maudiront donc davantage le reste du code. Donc, le vélo doit être fait au moins pas pire. Et encore mieux si personne n'avait envie de le remplacer par une bibliothèque tierce ou un autre vélo. Pour ce faire, vous avez besoin de:

1. La présence d'un avantage clair et important pour le projet.
2. Une interface d'utilisation simple pour que vous n'ayez pas à faire vos wrappers.
3. API flexible pour que vous n'ayez pas à voir un nouveau vélo avec un petit changement dans les exigences.
4. Bonne couverture de test, qui permettra moins de clignotements dans les rapports de bogues et revivra bien la refactorisation.
5. Documentation complète pour que vous n'ayez pas besoin de chercher l'auteur du vélo pour comprendre comment le conduire.

Je ne veux pas prendre la responsabilité

C'est normal si vous ne vous souciez pas du projet sur lequel vous travaillez. Si vous ne vous souciez pas vraiment de ce que vous consacrez un tiers de votre temps dans une journée, alors vous devez défendre votre point de vue. Et plus votre statut est élevé, plus il est responsable d'approcher quoi dire. En effet, non seulement la façon dont vous travaillez, mais la façon dont les autres travailleront et où ira le projet dans son ensemble, dépend de votre voix.

Recommandations

J'espère avoir pu montrer les craintes infondées des vélos. Plus vous vous rapprochez du professionnalisme, plus vous pouvez prendre de vélos ambitieux. Il vaut mieux commencer par des vélos plus petits, qui présentent moins de risques, mais qui donnent pas mal d'expérience dans ce domaine. Et avec ce portfolio, prenez des choses de plus en plus cool et intéressantes. Il est important de ne pas oublier qu'un vrai professionnel fait non seulement des choses sympas, mais sait aussi quand abandonner leur création. Par conséquent, effectuez toujours une analyse qui vous donnera l'assurance que vous faites tout correctement, et la direction sera de votre côté, et ceux qui vous suivront comprendront de quel type de vélo il s'agit, pourquoi il est ici et pourquoi il était impossible autrement.

Eh bien, pour vous aider dans l'analyse des bibliothèques tierces, au cours de la soirée, j'ai noté une application qui vous permet d'estimer le temps de résolution des problèmes de projets sur le GitHub . Plus le nombre est élevé, plus le projet avec support est mauvais et plus vous devez attendre une solution à votre problème. Par exemple: une comparaison d'Angular, VueJS, React, et bien sûr le $ mol sur lequel ce vélo est écrit. Gardez à l'esprit que le dernier lien est unique, car le pompage de tous les problèmes ouverts d'Angular dévore toutes les limites du GitHub, ce qui montre avec éloquence que ses responsables ne peuvent pas faire face au soutien du monstre qu'ils ont engendré.