C'est bien que le créateur de votre instrument préféré n'ait pas écouté les ânes quand il a inventé le vélo



L'été dernier, les gars et moi avons parlé de notre bibliothèque, que notre client n'a pas acceptée et jetée à la poubelle. Nous avons bombardé, parce que nous croyions en notre décision, et en avons parlé à la communauté - les développeurs ordinaires vérifieraient certainement et n'échangeraient pas pour des bêtises.

Oui bien sur. Nous avons été littéralement emportés par une vague de critiques. Il y avait beaucoup de gens qui n'aimaient pas ma vanité et moi personnellement - c'est bon, je n'ai aucun problème avec eux. J'étais en colère contre des gens apparemment intelligents qui ne voulaient même pas regarder le code et se plonger dans le contexte, car ils ont dit depuis le seuil: "Vous avez fait un vélo." Et tout le monde a ramassé - réinventer la roue est mauvais, terrible, cauchemar, inacceptable, honte, exécutez-les, lynche. En effet, seul un idiot développera un nouvel outil pour une tâche que quelqu'un a déjà résolue.

Je suis étonné de la rapidité avec laquelle les conceptions sont effectuées pour cette astuce. J'ai même demandé aux personnes les plus critiques et les plus profondes - «réinventer les vélos est-il mauvais?». Ils répondent «oui» en moins d'une seconde.

Eh bien non, les hommes, ça ne marchera pas. Arrêtons-nous ici, jetons un coup d'œil et réfléchissons en détail.



Une fois, j'ai fait une application frontale à la maison pendant un certain temps. J'ai utilisé le réactif, mais je ne l'ai pas pris pour la gestion de l'état - je n'ai pas eu un tel problème. Puis le problème est apparu et j'ai commencé à fabriquer "mon vélo". Les oncles intelligents m'ont dit que je suis un idiot et que je dois prendre Redux. J'ai pris.

Deux mois plus tard, la majeure partie du code du projet était une adaptation de l'éditeur à mon architecture. Cet outil m'a créé beaucoup plus de problèmes qu'il n'en a résolu. Pas parce que les éditeurs sont mauvais - ça ne convenait tout simplement pas.

Une personne d'une grande société a décidé de travailler avec l'état de l'application Web d'une grande société. Les éditeurs résolvent un tas de problèmes auxquels une telle application est confrontée et le font bien. Et que fait l'industrie? L'industrie dit - Dan Abramov nous a ouvert la voie. Maintenant, mon site Web sous deux formes utilisera des éditeurs pour travailler avec l'État.

Ami, les rédacteurs sont faits pour travailler avec l'État - mais pas avec votre État. Vous n'avez pas besoin d'une chaîne persistante de toutes les tranches de l'état de l'application, vous ne transmettez pas de jeux d'action sur le réseau et vous n'en faites pas beaucoup plus qui devraient automatiser les éditeurs. Dans le même temps, l'utilisation d'éditeurs n'est pas facile. Vous devrez récompenser une centaine de kilomètres de code pour expliquer à l'éditeur quelle est votre condition, où et comment elle est mise à jour, quels changements sont importants et lesquels ne le sont pas. Pour que les éditeurs automatisent pour vous un problème que vous n'aviez pas. Sérieusement, avez-vous vu au moins un poste vacant pour une réaction, mais sans éditeur? Pas moi.

Il existe des analogues - mais ils sont également volumineux. Parfois, le moyen le moins cher de résoudre un problème n'est pas de prendre un outil pour tout, mais d'écrire une solution de domaine qui vous convient. Mon dieu, le tapuscrit est assez puissant pour écrire un mvvm, mvc ou tout ce que vous voulez en quelques heures - de sorte qu'il ne résout que les problèmes que vous avez. Faites-le sortir moins cher et plus rapidement. Et peut-être que votre solution fonctionnera bien, évoluera avec le projet et deviendra la norme.

Mais cela est interdit - parce que d'autres développeurs vous ont dit: «Mec, ne réinvente pas la roue. Prenez simplement les plus populaires du marché. »

Dans mon projet, par exemple, MobX était plus adapté, mais pas non plus super. Cela fonctionnerait mieux pour moi exactement le vélo que j'ai inventé. Mais il semblait qu'ils m'ont enlevé mon droit de prendre une bonne décision, car quoi que je fasse, personne n'écouterait même. Personne n'est prêt à croire que cela se révélera meilleur et moins cher.

Cela crée un cercle vicieux. Si tout le monde n'utilisera que ce qui a été inventé avant eux, alors les progrès dans le développement s'arrêteront. Ils vous disent, si vous voulez faire mieux que dans la finition - faites-le à la maison pendant votre temps libre. Vous dites ok, vous commencez à travailler la nuit, vous le terminez, vous allez parler aux gens de votre décision, mais personne n'est même prêt à regarder sous son capot - "c'est un vélo".

Mais en fait, tout ce que nous faisons, c'est inventer des vélos. «Vélo» est simplement une ruse rhétorique nuisible pour justifier votre paresse ou pour s'affirmer dans un différend avec un autre développeur.

Les créateurs de l'éditorial, React et Mobix - après tout, ils ont aussi "fait leur vélo". Eh bien, quoi, à moins que l'angulaire n'apparaisse, nous n'avions pas de bibliothèque pour travailler avec l'interface utilisateur du navigateur? Jquery knockout C'est aussi très bien, soit dit en passant. Après tout, il y avait toujours vanilla js et une API de navigateur. Alors pourquoi ces idiots ont-ils résolu le problème résolu?

Douglas Crockford a inventé JSON. Le boob incompétent ne semble pas savoir que nous avons déjà XML. Bien avant lui, les programmeurs ont inventé un moyen d'échanger des données: qui pensait-il qu'il était là?

Mauvais exemples? Oui bien sur. En effet, dans vos têtes, les gens des grandes entreprises ont le droit d'inventer des vélos. Ils l'ont fait, mais vous et moi non.



L'informatique la plus utilisée dans la Fédération de Russie est la banque. Et si vous regardez les produits techniques de n'importe quelle Sberbank, Tinkov ou Alf, vous verrez - ils ont tous les mêmes applications avec approximativement la même conception. Ce sont des systèmes presque identiques. De même pour l'utilisateur, ils sont réalisés de différentes manières, sur différentes piles, par différentes personnes. Toutes ces banques ont leurs propres approches de développement uniques. Les géants mondiaux de l'informatique proposent également les mêmes produits. Lorsque les grands banquiers se réunissent et décident qu'ils ont besoin de produits numériques, ils embauchent une armée de développeurs et les forcent à faire les mêmes choses que d'autres banques ont déjà fait, pour la centième fois - mais d'une manière nouvelle.

Il s'agit de vélos.

Il y avait des problèmes de longue durée dans chaque projet sur lequel j'ai travaillé, car quelque chose n'était pas automatisé. Parce qu'une fois qu'on a dit à quelqu'un - ne réinventez pas la roue, fermez simplement le ticket. Oui, l'entreprise attend ses billets et elle doit être nourrie, mais soyons honnêtes - je sais que nous avons toujours plus de budget que ne le pense l'entreprise.

J'ai tout juste avec l'argent de l'entreprise que je dépense. Une grande entreprise a beaucoup d'argent et cela les pousse au développement. Cette énorme somme d'argent peut être dépensée par des développeurs qui résolvent des problèmes tout en effectuant des recherches. Et les gestionnaires peuvent dépenser, mais les gestionnaires les dépenseront pour payer notre séance insensée dans des millions de réunions inutiles. Les entreprises ont déjà dépensé de l'argent pour le développement, et si vous ne le transformez pas en programmation, les hommes d'affaires les dépenseront pour leurs processus stupides qui ne sont nécessaires à personne, sauf à eux-mêmes.

J'ai vu assez de mecs qui "travaillent" 18 heures par jour. Et je sais bien que si vous restez au bureau pendant 18 heures, vous travaillerez vraiment autant que si vous étiez assis 8.

Notre manière collective de tromper une entreprise s'explique très simplement - elle ne cherche pas. Les entreprises ne comprennent pas pourquoi nous ne devrions pas faire de fonctionnalités pendant deux semaines, mais mettre de l'ordre dans l'héritage. C'est normal, et nous savons comment le résoudre. Vous travaillez pour une entreprise pendant une demi-journée et travaillez pour un projet pendant une demi-journée. Je suis venu travailler, j'ai fermé la norme quotidienne - c'est tout, vous avez une carte blanche pour la recherche.

Pendant que nous résolvons une affaire de liste de souhaits pratique et momentanée, il est prêt à payer pour ce travail. En fait, le véritable développement commence là où il y a de la programmation pour le plaisir de la programmation. Lorsque vous vous délectez de la mécanique pure pour ne rien foutre, un clic momentané et un enthousiasme technique, car c'est la seule façon dont les limites sont tracées, de nouvelles façons et de nouveaux outils semblent résoudre à nouveau les problèmes pratiques, mais en mieux.

Quand je développe quelque chose, quelque chose qui a déjà été fait, je ne le réinvente pas exactement comme le leur. Je viens avec mon approche. Il est toujours quelque chose de mieux, toujours quelque chose de pire. Et c'est toujours une invention. La grande majorité de mes inventions vont aux poubelles de l'histoire, mais il y a toujours une chance que j'invente quelque chose de vraiment cool. Même si au passage, même si moi-même je n'y attache aucune importance, cela n'a pas d'importance. Quelqu'un verra, ailleurs, que l'industrie recevra une nouvelle norme qui commencera à résoudre nos problèmes. Seule cette idée me pousse à écrire du code.

L'open source a également plusieurs des mêmes projets. Ceux qui résolvent le même problème. Êtes-vous prêt à dire que tous ceux qui les fabriquent sont des imbéciles? Je ne suis pas prêt. Lorsque je veux créer un lot pour la sérialisation, j'obtiens cinq ou six solutions principales, chacune ayant des avantages uniques. Parfois, l'un de ces avantages est essentiel pour moi, dans de tels moments, je suis plein de gratitude envers les gars qui ont décidé de faire ce «vélo».

Quand ils me disent que tout a déjà été inventé en développement, je demande: "quoi, n'avons-nous pas de problèmes?".

N'écrivons-nous pas un passe-partout quotidien? Ne supprimons-nous pas encore l'automatisation lorsque nous remplissons nos fichiers avec le même code? Nous faisons encore beaucoup de ce que la machine pourrait faire maintenant. Et nous le faisons parce que nous n'avons pas encore inventé d'approches, parce que nous insérons toujours des bâtons dans les roues des vélos.



Regarder mon podcast

All Articles