"Combien de téléspectateurs viendront à votre conversation Java?" Cela dépend si Venkat se produit dans la salle adjacente en même temps. »
C'est une blague avec une bonne part de vérité: dans le monde Java,
Venkat Subramaniam est l'un des conférenciers les plus célèbres, qui est vraiment capable d'attirer des spectateurs d'autres salles lors de conférences. Il s'est déplacé sans relâche autour de la planète et a récemment établi un record impressionnant, par son 50e anniversaire, s'exprimant en un an devant 50 groupes d'utilisateurs Java différents.
À quoi cela ressemble-t-il lorsque votre carrière Java n'est pas «assise au bureau», mais «en mouvement constant»? Et que pense Venkat des problèmes actuels de Java? En octobre, il se rendra à Saint-Pétersbourg, et en prévision de cela, nous (
phillennium ,
olegchir ) l'
avons interviewé en détail, où nous avons commencé avec «la vie dans l'avion» et des conseils pour les locuteurs novices, puis nous sommes passés à la technologie.
Puisque Venkat répond en détail, le texte est long. Si vous le souhaitez, vous pouvez immédiatement passer à la deuxième partie:
Pour la vie
- Commençons par votre visite, au cours de laquelle vous avez visité 50 groupes d'utilisateurs Java, presque personne ne l'a fait auparavant. Quelles ont été vos impressions?- La chose la plus intéressante pour moi a été la prise de conscience que, dans différentes cultures dans différentes parties du monde, les gens qui parlent des langues différentes, malgré toutes ces différences, sont unis par la programmation comme un seul fil conducteur. Lorsque nous commençons à parler de programmation, il s'avère que les problèmes auxquels nous sommes confrontés chaque jour sont les mêmes. Ce fut une grande découverte pour moi - vous pouvez rencontrer un programmeur dans n'importe quel aéroport du monde, et vous trouverez certainement des sujets de conversation communs. Je peux sans cesse énumérer des cas où j'ai été impliqué dans des discussions sur Java de l'autre côté de la Terre.
Par conséquent, l'expérience avec ces groupes m'a été très utile. La gestion d'un groupe d'utilisateurs est très difficile ... Je ne veux pas dire «travail» car ce n'est pas du travail, mais il faut dépenser beaucoup d'efforts. J'ai un grand respect pour tous les dirigeants qui rassemblent ces événements encore et encore chaque mois. Différents groupes ont des dynamiques différentes - certains ont 20 ou 30 personnes aux réunions, d'autres 200 ou 300. Néanmoins, le nombre, en fait, ne joue aucun rôle, car l'essentiel est la passion des développeurs qui viennent à ces réunions, leur intérêt pour la technologie et leur désir d'apprendre. J'ai donc eu beaucoup de chance d'avoir eu l'occasion de rencontrer ces groupes et je leur en suis très reconnaissant.
- Et avec la similitude que vous avez mentionnée, les groupes d'utilisateurs dans différentes parties du monde ont-ils des différences locales notables?- Ces différences sont étonnamment peu nombreuses. J'ai remarqué que dans certaines régions, la préférence est donnée aux cadres lourds et, dans d'autres, aux solutions plus légères. Mais, en règle générale, toutes ces caractéristiques sont superficielles, et les questions et problèmes profondément ancrés, au contraire, sont universels. Je voudrais sincèrement vous dire qu'à un moment donné sur la carte, les gens font des choses complètement différentes de la nôtre, et que tout est intéressant et inattendu là-bas, mais je ne peux pas le dire.
Nous aspirons tous à la complexité, elle nous entraîne, et quand elle traîne, nous commençons à la combattre. C'est une tendance générale presque partout. Un autre problème important auquel personne n'a échappé est les exigences strictes de l'entreprise et le manque de temps pour travailler sur la qualité. Je peux parler d'un exemple à des gens partout dans le monde, et après mon histoire, on me demandera: "est-ce que tu as travaillé dans notre entreprise?" Nos problèmes sont si profonds et universels qu’apparemment, ils sont communs au monde entier. Ce qui nous fait involontairement penser à notre essence humaine commune, à la psychologie et à la philosophie, que nous suivons finalement. Peu importe combien nous nous imaginons en tant que geeks tournés vers la technologie, nous ne devons pas oublier l'aspect humain dans le développement de logiciels. Apparemment, il est une force unificatrice et universelle.
- Je voudrais poser des questions sur un mode de vie «camping». Lorsque vous êtes assis au bureau, il n'est pas toujours évident que vous souhaitiez une vie comme la vôtre. Par exemple, pour beaucoup, le décalage horaire est un problème, et pour cette raison, des vols constants peuvent sembler un cauchemar. Mais peut-être qu'avec la pratique, vous vous y adaptez?- Pour répondre à votre question, rappelons l'intégration continue. Si une équipe effectue l'intégration une fois par mois, vous proposez qu'elle le fasse tout le temps, elle vous considérera comme fou. En cela, les relations de voyage ressemblent à une intégration et à une livraison continues: si vous les traitez beaucoup, votre approche à leur égard change.
Ne vous méprenez pas, je ne suis pas fier de mon mode de vie, à mon avis, ça ne vaut pas la peine de vivre comme ça. Je dis toujours que dans les voyages, j'aime le moins les voyages eux-mêmes. Être assis dans un avion est fatigant, le corps s'use et avec l'âge, ces problèmes ne vont nulle part. Mais quand j'arrive à destination, quand je rencontre d'autres développeurs, je vois leur passion pour la technologie, leur enthousiasme, j'ai l'opportunité de partager cette passion, d'apprendre quelque chose de nouveau et d'aider à l'apprendre, toutes les difficultés sont payantes avec intérêt.
Si nous parlons du changement de fuseau horaire, cela ne me dérange pas du tout. En raison des vols constants, dans un certain sens, je n'ai pas de temps de «retour» constant. J'ai une règle: je me réveille toujours à la même heure locale, vers 3h30 du soir, et le corps entre très vite dans un certain rythme. Et, bien sûr, le café est toujours le bienvenu.
- Beaucoup de gens aimeraient voir le monde, mais ils partent généralement en voyage touristique et non en voyage d'affaires. Êtes-vous en mesure de regarder les villes, ou par manque de temps uniquement dans les salles de conférence?- Oui, en partie il y a un problème de temps. Mais, en plus de cela, en raison des vols constants, j'ai certains principes auxquels j'adhère. Si le voyage est lié au travail, je ne fais que travailler. J'essaie de passer le plus de temps possible avec les développeurs. Lorsque j'ai un samedi ou un dimanche gratuit, par exemple en Europe, je le passe généralement dans un groupe d'utilisateurs. Cela me fait grand plaisir de communiquer avec les développeurs, donc lors de mes voyages d'affaires, je ne vais presque jamais dans les lieux d'intérêt.
Mais chaque année pendant quatre ou six semaines en été, je voyage avec ma famille et nous allons faire du tourisme. C'est notre temps pour un repos commun, et dans les mois restants je me concentre sur le travail.
De plus, mon approche me permet de porter une attention maximale aux différents événements communautaires, ce qui me fait également grand plaisir. Cela prend beaucoup de temps et est une sorte de compromis, mais cela me convient. La vie est parfois trop stressante et je suis heureux d'avoir l'occasion de me laisser distraire et d'écouter des développeurs qui n'ont peut-être pas la possibilité d'assister à une conférence ou à un cours de formation. De plus, je crois que c'est aussi mon devoir professionnel, car ce sont ces choses qui m'ont inspiré dans ma jeunesse. J'ai visité des groupes d'utilisateurs, écouté des performances et rêvé à mon époque de me produire moi-même. Si, à mon tour, j'arrive à inspirer au moins une personne de la même manière, ce temps sera bien dépensé.
- Dernière question de voyage. Dans le film «Up in the Air», le personnage de George Clooney, qui vole constamment entre les villes, connaît de nombreuses astuces pour améliorer l'efficacité des voyages: comment faire la queue, comment emballer ses bagages, etc. Peut-être avez-vous également des connaissances non évidentes que vous aimeriez partager?«J'ai honte de l'admettre, mais j'envoie parfois des vêtements entre les villes sur FedEx, car je n'ai tout simplement pas le temps de rentrer chez moi et de prendre des vêtements pour la semaine prochaine. Souvent, quand j'arrive à l'hôtel, mes vêtements sont déjà là et quand je pars, je les renvoie chez moi. Heureusement, cela n'arrive pas trop souvent, peut-être trois ou quatre fois par an, quand je suis en route pendant trois semaines consécutives. Il y a eu un moment gênant où ma femme a dû se rendre à l'aéroport pour me remettre les bagages, car je n'avais qu'une demi-heure entre les vols. Mais avec le temps, vous apprenez vraiment à faire certaines choses plus efficacement. Parfois, cela me surprend quand les gens disent "j'ai besoin de faire mes valises" car mes affaires sont collectées tout le temps.
En parlant d'efficacité, j'ai au moins un avantage: je suis une personne très simple. Nous vivons dans le monde de Facebook, Twitter et divers messagers, ils nous distraient constamment. J'ai travaillé dur pour réduire cet effet, car les minutes se transforment en heures, les heures se transforment en jours, les jours se transforment en semaines, et tôt ou tard vous vous rendez compte que vous ne pouvez pas réaliser ce que vous voulez. Habituellement, j'ai un journal dans lequel j'écris les choses à faire pour chaque voyage. Ainsi, j'ai un horaire pour chaque jour (par exemple, pour le 7 novembre ou le 8 octobre), et mon téléphone me rappelle chaque tâche le jour correspondant. Sur un vol de huit heures, je peux écrire la plupart d'un chapitre du livre ou préparer un exemple pour le cours. Par conséquent, les vols sont pour moi un moment extrêmement efficace. Je n'ai jamais besoin de divertissement supplémentaire pendant le vol - de nombreux divertissements liés au débogage de code suffisent amplement. Ainsi, un voyageur professionnel (si un tel terme est généralement applicable) passe son temps de vol assez différemment d'un touriste.
- Probablement, à cause de votre renommée, vous recevez beaucoup plus de lettres que les développeurs ordinaires. Combien vous écrivent-ils et combien de temps prend le courrier?- Il convient d'ajouter que j'enseigne à l'université et que je reçois de nombreuses lettres d'étudiants. Habituellement, je reçois 20 ou 30 lettres par jour. Il y a environ un an, j'ai
écrit sur un blog un de mes principes: "répondez maintenant ou dites quand vous répondez."
J'apprécie vraiment mon temps, ce qui signifie que j'apprécie le temps des autres. À mon avis, le respect d'une autre personne n'est pas dans l'attrait de monsieur, mais dans l'appréciation du temps de chacun. Par conséquent, si une lettre m'arrive, je réponds toujours dans les 24 heures. Mais il y a des moments où cela ne fonctionne pas pour donner une réponse complète - par exemple, si l'organisateur de la conférence demande d'envoyer une annotation ou si un collègue de l'industrie pose une question sur la résolution d'un certain problème, demande de refactoriser du code ou demande d'utiliser une certaine méthode. Parfois, la réponse peut prendre dix minutes et parfois deux heures, mais même dix minutes ne peuvent pas toujours être dépensées. Cela peut sembler un peu étrange, mais je réponds toujours dans de tels cas dans les 24 heures et j'écris: j'ai reçu votre lettre, je vais travailler sur ce problème, disons le 2 septembre et vous écrire le 3. Dans le même temps, mon calendrier est mis à jour avec l'entrée correspondante le jour où j'ai du temps en vol ou l'après-midi.
Grâce à cette approche, ma boîte de réception est toujours vide, je la nettoie tous les soirs avant le coucher. Je suis donc extrêmement discipliné dans la réponse aux lettres. Les gens sont souvent surpris que je réponde si rapidement à leurs lettres, mais moi, au contraire, je ne comprends pas comment autrement. Je ne veux pas gêner les gens, les empêcher de se développer. De plus, je considère qu'il est important de dire non. J'aime répéter que plus vous dites oui, pire vous obtiendrez ce que vous faites. À un certain moment, vous devez réaliser que nous ne pouvons pas tout réaliser dans le monde. Par conséquent, parfois je réponds que, malheureusement, je ne peux pas aider. À mon tour, je préfère qu'on me dise non immédiatement, et que je ne tire pas le caoutchouc et que je dis non plus tard. À mon avis, cela parle également de respect de la personne et de refus de perdre son temps en vain. Vous n'avez pas à aider, mais au moins ne vous embêtez pas. Par conséquent, il est important de dire non. C'est ainsi que la vie est organisée, n'essayez pas de prétendre que vous pouvez tout faire dans le monde. Pour moi, la capacité de répondre rapidement et honnêtement est un signe de professionnalisme.
- Vous êtes un orateur très expérimenté. En tant qu'organisateurs de conférences, nous rencontrons des personnes qui n'ont pas d'expérience de prise de parole en public ou qui en ont très peu. Peut-être avez-vous des recommandations à leur faire? Vous avez eu une astuce intéressante sur Twitter "pour visiter à l'avance la salle dans laquelle le rapport se tiendra" - y en a-t-il d'autres?- Mes premiers rapports étaient dans des groupes d'utilisateurs, c'est pourquoi je continue à en faire 15 chaque année. Et je recommande que d'autres commencent par la même chose: avec un groupe d'utilisateurs dans votre région, puis dans un voisin, et ainsi de suite.
Pour de nombreuses raisons, ces reportages présentent moins de risques que lors d'une grande conférence: l'ambiance est conviviale, les gens viennent là pour partager leurs connaissances, après vos reportages il vous sera facile d'obtenir une réponse. Vous pouvez très bien commencer la présentation en disant que vous avez peu d'expérience en la matière et que vous aimeriez connaître l'opinion du public. Cette année, j'ai eu un nouveau rapport, au cours de la préparation duquel j'ai beaucoup vécu. J'ai écrit à ce sujet sur Twitter: il semble que tout peut être dit en deux minutes, mais en réalité le matériel ne peut pas être mis en une heure et demie. Et je suis très heureux que la première fois que j'ai fait ce rapport dans un groupe d'utilisateurs, car cela m'a donné l'occasion de mieux le préparer pour la conférence.
Dans les groupes d'utilisateurs ou dans l'entreprise où vous travaillez, vous avez une excellente occasion de pratiquer des présentations. Tout d'abord, vous recevrez des critiques de collègues, ce qui vous permettra d'améliorer le rapport. Deuxièmement, même s’ils ne vous disent rien directement, vous comprendrez toujours beaucoup vous-même lorsque vous commencerez à parler. Je pense qu'il est possible d'améliorer vraiment le rapport à partir de la troisième fois. La première fois, vous essayez seulement de rassembler toutes les pensées. Et voici ce qui est intéressant: pratiquer seul n'aidera pas ici, la prise de conscience des problèmes ne vient que lorsque l'on parle à d'autres personnes. La troisième fois, la chaîne logique de votre récit devient plus claire pour vous, elle est terminée. Ce n'est pas toujours perceptible, mais je m'arrête parfois pendant mon discours pour la troisième fois - en ce moment, je me rends compte que c'est moi qui essayais de dire dans le rapport qu'une sorte de moment de vérité arrive. La pratique est donc très importante, mais pas seule, mais avec les gens. Cela peut donner au jeune développeur la confiance nécessaire.
Certes, certains font leurs premiers rapports lors de conférences. Parfois, il est plus facile pour une personne de mourir que de parler en public, et ils sont faciles à comprendre - cela prend beaucoup de nerfs. Il y a deux ou trois ans, j'ai pris la parole lors d'une conférence. Une personne très intéressée est venue vers moi et m'a dit que, apparemment, j'étais très inquiète, à quoi j'ai répondu que c'était vraiment le cas. Il a demandé: «Est-ce votre premier rapport?», Et j'ai répondu: «Non, probablement dix mille, c'est pourquoi je suis inquiet.» Chaque représentation devant le public nécessite beaucoup de stress émotionnel, même si vous avez beaucoup d'expérience, simplement parce que vous vous souciez de la façon dont le rapport se déroule. Vous ferez un excellent travail si vous atténuez cette tension avec quelques rapports de test dans des groupes d'utilisateurs ou dans votre entreprise. Cela s'applique à tous les orateurs, y compris ceux expérimentés.
- Mais y a-t-il quelque chose à parler en public qui devrait au contraire être évité?«J'ai fait de nombreuses erreurs dans ma vie qui m'ont appris que les gens apprennent mieux par expérience.» Lorsque vous parlez à un public, il y a quelques points à garder à l'esprit. Tout d'abord, vous devez garder confiance en vous: vous avez beaucoup travaillé sur le sujet et vous en savez beaucoup. Deuxièmement, souvenez-vous: il est impossible de tout savoir et l'ignorance de quelque chose n'est pas de votre faute. Cela signifie simplement que vous n'avez pas eu l'occasion de prêter attention à cela, et il n'y a rien de mal à cela. Il est extrêmement important de vous l'avouer honnêtement. Vous pouvez tout à fait répondre à la question lors de la conférence comme ceci: désolé, je ne peux rien vous dire, je n'ai pas eu l'occasion d'étudier ce problème.
Un autre point important est que les auditeurs peuvent être divisés en trois types. Il y a des gens qui veulent apprendre quelque chose de nouveau de toi. D'autres se tiennent un peu plus prudents, ils vous écouteront, mais ils ne seront pas prêts à percevoir tout ce que vous dites. Enfin, il y a un troisième groupe de personnes, heureusement, plutôt petites: celles qui sont hostiles et qui essaient de vous attraper tout le temps. Tôt ou tard, votre rapport aura définitivement un développeur qui vous interrompra tout le temps et interrompra la progression du rapport. Dans de tels cas, il est très important de rester calme, de le laisser parler et de ramener la discussion dans la direction dont vous avez besoin - mais, je dois l'admettre, je suis aussi une personne, et je n'y arrive pas toujours. Vous pouvez, par exemple, dire: Je comprends que c'est important pour vous, discutons-en après le rapport, ce sujet est important pour beaucoup ici. Certes, très souvent, vous avez des alliés dans le public, et lorsqu'une personne viole vraiment le cours de son discours, on lui demande de se calmer. Je dis tout cela au fait qu'il est important de ne pas être trop en conflit dans de telles situations, même si notre nature peut y résister. En tant que jeune orateur, je me suis souvent engagé dans de telles confrontations à pleine puissance, et cela n'a jamais apporté de bien à personne. Il faut faire preuve de maturité émotionnelle et ne pas essayer de prouver quoi que ce soit à qui que ce soit à propos de soi, en s'engageant dans ce genre d'escarmouche. Au lieu de cela, dans de tels cas, le sujet devrait être ramené à ce qui est intéressant pour le public.
Je voudrais également parler de certaines habitudes négatives lors des performances, ce que, à mon avis, les développeurs ont. Pour commencer, les gens devraient se regarder dans les yeux. Je comprends que cela est très difficile et nécessite beaucoup d'efforts émotionnels, mais vous devez vous entraîner. Les conférenciers regardent souvent leur moniteur ou, pire encore, l'écran, dos au public. Vous devez toujours faire face au public et vous devez toujours le regarder. De plus, la confiance en soi doit être maintenue. Vous parlez à un public de programmeurs et vous pouvez parier qu'aucun d'entre eux n'a de code qui fonctionne la première fois. Si votre démonstration n'a pas fonctionné pendant la présentation, il n'y a rien de mal à cela. Toutes les personnes présentes penseront très probablement: "Merde, tout est exactement pareil avec moi." Au fil des ans, j'ai appris dans de telles situations à me tourner vers le public pour obtenir de l'aide avec le débogage. Habituellement, les locuteurs dans une telle situation commencent à marmonner quelque chose dans leur souffle et essaient de résoudre toutes les difficultés par eux-mêmes. Au lieu de cela, vous devriez demander au public - amis, pouvez-vous me dire où je suis stupide? , . , . . , : , , , . , .
— Java- , Java «Hello world». «public static void main» , , .
: Java- , , , . , . - - Java?— , . , , Java — , 2000-. , , , .
, , , , , . , , 70 try-catch . , , , .
— . , , , . , , . , . , .
Java 12, 13 14 : , , Java , , . , , Java , . , , . , , Java . , , , Java . , , , , , Java .
. Joker «Don't walk away from complexity, run» . , Joker , , .
- Dans le contexte de «Java moins explosif», il est impossible de ne pas vous poser de questions sur Kotlin, qui est souvent appelé ainsi."Oui, c'est vrai." Et la question n'est pas seulement dans moins de prétention. Pour moi, l'une des choses les plus excitantes de la vie est d'apprendre à connaître de nouvelles langues et leurs capacités. Une possibilité dans Kotlin est d'exécuter un lambda dans le contexte d'un objet, même s'il ne fait pas partie de la classe. Je suis devenu très intéressé lorsque je l'ai découvert, car la même possibilité est présente dans JavaScript. Là, vous pouvez passer un objet contextuel dans l'appel (ce que Kotlin appelle récepteur), puis exécuter cette fonction globale arbitraire comme si c'était une fonction d'un objet. Le fait que cette fonctionnalité soit en JavaScript n'est pas surprenant, car ce langage est dynamique. Mais Kotlin est un langage statique, et il fait de même, tout en respectant la sécurité des types. Le manque de prétention, bien sûr, est un grand avantage du langage, tout comme le fait qu'il génère automatiquement une partie importante du code, de sorte que nous ne pouvons pas écrire les mêmes modèles encore et encore. Mais les avantages ne s'arrêtent pas là, car cette fonctionnalité vous permet de créer des DSL internes.
La science et les mathématiques m'ont conduit à la programmation, mais 30 ans plus tard, je reste programmeur car c'est de l'art. Notre domaine allie science et art, il n'y a pas moyen de le contourner. La possibilité de simplement faire fonctionner le système n'est pas limitée, vous pouvez ici faire une analogie avec l'écriture de poésie: demandez à deux personnes d'écrire sur l'amour, et chacun écrira à sa manière. Le code de n'importe quelle tâche peut être écrit de différentes manières. C'est ce qui m'attire dans des langages comme Kotlin et bien d'autres: la capacité d'exprimer certaines de ces idées, de donner au code souplesse et légèreté. Vous pouvez penser beaucoup moins à la syntaxe du langage et plus à la pensée que vous souhaitez transmettre.
- La qualité du code est d'une grande importance pour vous. Cela semble être important pour tout le monde, et il semble que tout le monde veuille mieux écrire, mais on sait qu'une partie importante du code existant a des problèmes. Par conséquent, la question est: pour que vos collègues ne vous détestent pas pour votre code, vous avez juste besoin d'autodiscipline, pouvez-vous donner des recommandations spécifiques?«Je suis convaincu que la seule façon d'écrire du code lisible est de le lire.» Quand ils me disent que le code est lisible, je demande - qui l'a lu? Si l'auteur lui-même l'a lu immédiatement après avoir écrit, cela ne compte pas. Par conséquent, je crois fermement à la révision du code. Je veux clarifier: je suis opposé à amener une équipe dans une pièce avec un grand écran, à montrer du code dessus et à le critiquer. Cela conduit inévitablement à des griefs, une telle okhayanie publique que personne n'est bon.
Nous devons admettre honnêtement: nous écrivons tous du mauvais code. Je suis fier de l'admettre: mon code est nul, je ne sais pas écrire un bon code. Si vous demandez comment cela correspond à mon discours sur la qualité du code, je répondrai: l'écriture de code est un processus d'innovation constante, et lorsque vous essayez de mettre en œuvre une idée, la qualité du code ne vous dérange pas trop. Il est toujours nécessaire de revenir et de refactoriser, et même lorsque je fais cela, généralement rien ne fonctionne pour moi. Mais au fil des ans, j'ai réalisé cela, même si mon propre code est basique, mais je peux très bien trouver des failles dans le code de quelqu'un d'autre. Par conséquent, au lieu de prétendre que mon code est déjà si excellent, je l'écrirai aussi bien que possible et je vous le donnerai pour vérification, tandis que dans l'intervalle, je prendrai le code de mon collègue et le vérifierai. En conséquence, mon code et le code de mon collègue seront de meilleure qualité.
Il est très important de renoncer à la fausse fierté. Je rappelle toujours aux développeurs qu'ils font partie d'une équipe, cela n'a aucun sens de se faire concurrence et de découvrir qui est plus cool, non. Je suis prêt à admettre honnêtement que mes connaissances sont assez limitées - mais ce que je sais, je le sais bien. Et mon collègue a également des connaissances très approfondies dans un autre domaine. Ensemble, nous devenons plus forts lorsque nous sommes prêts à apprendre les uns des autres. Par conséquent, je suggère toujours de vérifier le code de l'autre, et une fierté supplémentaire est complètement inutile ici. Vous devez être honnête les uns avec les autres, c'est l'une des qualités les plus importantes d'une bonne équipe. L'honnêteté ne devrait pas être punie si une personne admet avoir écrit un mauvais code - c'est normal. Nous élevons la barre en nous offrant mutuellement des moyens d'améliorer le code.
Autre point important: vous n'avez pas besoin de dire à une personne qu'il a fait une erreur, il faut dire ce qui peut être amélioré exactement. Ne dites pas: "Dieu, quel nom terrible pour une variable", c'est mieux ainsi: "Vous vouliez probablement dire que cette variable montre la fréquence de distribution - probablement elle devrait être appelée en conséquence." Cela vous aidera à mieux exprimer vos intentions. Cela vaut également pour l'édition de livres: parlez non seulement de ce qui doit être amélioré, mais aussi de ce qui a été bien fait. Nous l'oublions souvent. Lorsque je modifie le code de quelqu'un d'autre et que je vois un endroit bien exécuté, j'écris dans un commentaire que j'aime beaucoup, que nous devons le faire plus souvent et expliquer pourquoi. Cela crée des commentaires constructifs, montre clairement au développeur que vous n'êtes pas hostile à son égard et améliore finalement la qualité du code de votre équipe.
- Vous avez écrit qu'utiliser un outil qui vous pousse à la nostalgie, c'est comme se retrouver coincé dans une relation toxique: dans cette situation, il vous suffit de partir, et le plus tôt possible. Cela sonne bien, mais souvent l'instrument n'a pas d'alternative particulière, et alors quoi?- Une question tout à fait justifiée. En effet, il y a des situations où il n'y a nulle part où aller. Mais j'ai plutôt parlé de ces cas où il y a encore une possibilité de choix, et seule l'envie de le faire fait défaut. À mon avis, c'est un facteur important.
Lorsqu'il n'y a pas le choix, au lieu de se plaindre, les points douloureux doivent être identifiés: ce qui rend exactement cet outil inconfortable pour vous. Et puis vous pouvez le faire de différentes manières. Vous pouvez contacter les développeurs et dire - merci pour votre travail, il nous semble que votre outil pourrait être bien meilleur si vous portiez attention à tel ou tel aspect. Ou vous pouvez organiser un hackathon - réunissez-vous le week-end avec plusieurs développeurs, organisez un groupe d'utilisateurs, dites-leur que vous passez neuf heures par jour avec cet outil, que c'est terrible, et demandez-leur d'essayer d'y ajouter des fonctionnalités.
Peut-être que vous ne pouvez pas résoudre tous les problèmes seuls, mais au moins vous pouvez réunir d'autres personnes et résoudre ce problème avec elles, surtout si leurs intérêts sont similaires aux vôtres. Enfin, si votre outil vous cause vraiment autant de problèmes, vous pouvez essayer d'en écrire un nouveau vous-même - si vous avez trois ou quatre amis dans la communauté avec la même attitude que vous.
Donc, à mon avis, il existe encore des alternatives. Vous n'avez pas à supporter une relation toxique. Vous devez toujours être en mesure de trouver une issue - soit convenir avec un partenaire et parvenir à une compréhension mutuelle, soit partir.
- Vous avez écrit un livre sur les lambdas, et vous êtes connu grâce à ce livre. Je l'ai également lu, et je pense qu'il est magnifiquement écrit, donne ce dont le développeur d'applications a besoin et ne donne rien de superflu. En tant que véritable professionnel, je voudrais vous demander: quelle est la programmation fonctionnelle pour vous? Pourriez-vous le décrire avec vos propres mots? Je pose cette question parce que tout le monde la définit un peu à sa manière, et chaque fois que des significations cachées sont révélées qui diffèrent de la définition standard de Wikipedia.- C'est une merveilleuse question. Ma compréhension de ce concept a évolué au fil des ans, et maintenant pour moi, la chose la plus importante dans la programmation fonctionnelle est l'élimination de la complexité étrangère. Nous parlons du fait que dans la programmation impérative, vous indiquez non seulement ce qui doit être fait, mais aussi prescrivez en détail comment le faire. Pour moi, la programmation fonctionnelle est un complément au style de programmation déclarative, dans lequel nous indiquons ce qui doit être fait, mais ne disons pas comment.
Permettez-moi de vous donner une analogie primitive: mes meilleurs amis aiment les voitures, mais ils ne m'intéressent pas du tout. Lorsque nous nous réunissons, nous nous engageons à ne pas discuter de voitures, car nous voulons rester amis. Je ne conduirai jamais une voiture avec une boîte de vitesses manuelle - la nécessité de changer constamment de vitesse gâche toute ma conduite, et il en va de même pour le style de programmation impératif. La transmission automatique facilite la conduite, mais pour moi, la meilleure option est que le conducteur me conduise. Dans ce cas, je dis simplement où je dois aller et, en cours de route, j'écris le code sur mon ordinateur portable sur le siège arrière. Pour moi, c'est la différence entre la programmation impérative et fonctionnelle. Avec la programmation impérative, vous conduisez vous-même, vous devez savoir où aller, comment aller, où tourner, où vous pouvez couper. Avec une programmation fonctionnelle, vous êtes assis sur le siège arrière, indiquant au conducteur où vous emmener, et votre attention est entièrement concentrée sur votre travail.
Comment cette complexité étrangère est-elle supprimée? Par la composition des fonctions. Lors de la composition de fonctions, votre code subit une série de transformations au cours desquelles les données passent d'une forme à une autre. De plus, pour nous, il est important non pas de savoir comment chacune de ces étapes est exécutée, mais ce qu'elle permet exactement. Pour moi, le premier aspect de la programmation fonctionnelle est la composition fonctionnelle. Le problème est que de nombreux langages dans lesquels la composition fonctionnelle est implémentée - Ruby, Python, JavaScript, Groovy, etc. - fournissent l'élégance et l'expressivité à cause de cela, mais ils ont des performances très faibles. La composition fonctionnelle en eux est mise en œuvre de manière inefficace. Je crois que l'élégance sans efficacité n'est pas viable. Non seulement le code doit être beau, mais il doit également fonctionner rapidement. Et nous arrivons ici au deuxième aspect vital de la programmation fonctionnelle - nous parlons de l'informatique paresseuse. Le résultat d'une certaine fonction n'est calculé qu'au moment où il est nécessaire. Grâce à cela, une combinaison d'élégance et d'efficacité est obtenue dans la programmation fonctionnelle. Donc, pour moi, la programmation fonctionnelle met l'accent sur ce qu'il faut faire, pas sur la façon de le faire; utilisation de la composition fonctionnelle comme une série de transformations de données; et la capacité d'effectuer ces transformations efficacement grâce à l'informatique paresseuse.
Veuillez noter que je n'ai pas parlé de l'immunité et des fonctions de haut niveau. Le fait est que ce ne sont que des ingrédients pour obtenir le résultat que j'ai décrit. Nous utilisons la programmation fonctionnelle non pas pour l'immunité et les fonctions d'ordre élevé, elles ne sont qu'un moyen d'atteindre un objectif plus élevé: se débarrasser de la complexité étrangère.
- Grande définition. Aujourd'hui, il existe un langage qui est la référence pour ce que devrait être la programmation fonctionnelle: Haskell (et peut-être F #).- C'est vrai.
"Au moins beaucoup de gens le pensent." Mais Java n'est évidemment pas Haskell, il est largement limité. La programmation fonctionnelle a-t-elle un sens en tant que discipline lorsqu'elle est appliquée à Java? Après tout, notre langage dispose d'un ensemble d'outils très limité pour cette approche.- Pour moi, l'aspect pragmatique plutôt que la recherche de l'excellence est plus important. Je suis curieux de savoir la perfection, mais pour que tout fonctionne, je dois être pragmatique. Je suis fou de Haskell et je passe beaucoup de temps avec lui, juste pour découvrir comment une tâche particulière est résolue dans la programmation fonctionnelle. Mais pour mes clients, je n'écris pas sur Haskell. Ici, vous pouvez faire une analogie avec la «cathédrale et le bazar». La cathédrale est magnifique, mais la plupart du temps je passe au bazar. La question est de savoir comment survivre dans ce monde. Lorsque les langages évoluent et lorsque nous essayons de combiner plusieurs paradigmes différents ensemble, nous, en tant que programmeurs, devons être extrêmement prudents avec leur implémentation.
Je ne pense pas que la programmation fonctionnelle soit impossible du tout en Java. Dans les situations où il y a un choix, je me concentrerai sur la langue la plus appropriée pour moi. Mais je ne le dirai jamais au client: vous devez utiliser cette langue. Le plus souvent, je demande ce qu'ils font exactement et j'essaie de trouver un moyen de faire de même de manière plus optimale dans le cadre de l'environnement qu'ils ont déjà. Je crois que dans des langages comme Java, une combinaison de programmation impérative et fonctionnelle est tout à fait possible et même recommandée, mais cela doit être fait avec une extrême prudence. Imaginez que vous ayez une sorte de cercle de fonctions pures, autour duquel il y aura un anneau d'impureté. Tout ce que vous voulez faire changer doit être en dehors du cercle. À l'intérieur de ce cercle, vous pouvez implémenter votre propre chaîne de fonctions, mais toutes les modifications doivent être en dehors de celui-ci.
C'est l'une des raisons pour lesquelles j'aime apprendre de nouvelles langues. J'ai récemment fait connaissance avec le langage Elm, qui est une syntaxe Haskell avec des intercalaires F # qui se compile en JavaScript. Cette approche m'a intéressé dès le début, car JavaScript est un bazar. Lorsque vous voyagez via JavaScript, vous entrez constamment dans des flaques d'eau. Grâce à la syntaxe d'Haskell, Elm est définitivement une cathédrale. Néanmoins, ce code conciliaire peut être exécuté dans le bazar. L'architecture d'Elm est élégante, elle a un modèle (c'est-à-dire des données), il y a une vue qui affiche ces données, et il y a une transformation, une mise à jour. Le premier principe principal est que les données sont stockées en vue. Lorsque l'utilisateur effectue une action (appuie sur une touche, par exemple), les données de la vue sont envoyées à la fonction de mise à jour, où la conversion a lieu. Les données sont immuables et la fonction de mise à jour renvoie de nouvelles données que la vue enregistre au lieu des anciennes.
Si vous y pensez, alors exactement de la même manière que Redux fonctionne. Il contient des données et des réducteurs existent. Lorsque les données sont envoyées aux réducteurs, vous obtenez une nouvelle copie en retour, que vous enregistrez à la place de l'ancienne. Mais si Elm et Redux fonctionnent sur le même schéma, le même schéma peut être implémenté en Java. Nous pouvons créer des fonctions pures qui prendront des données, les transformeront et retourneront une nouvelle copie. En apprenant de Redux et Elm, nous pouvons rendre l'architecture Java plus fonctionnelle. J'en parle parce que Redux compile en JavaScript, qui est uniquement un bazar. JavaScript, je pense, est le plus éloigné de l'idéal de pureté fonctionnelle, ici à chaque étape, vous entrez dans une flaque d'eau. Néanmoins, Redux vous offre une pureté fonctionnelle dans ce monde extrêmement impur. Cette approche m'a beaucoup influencé car elle a changé ma vision de la programmation fonctionnelle et a montré que je peux également implémenter ces principes en Java.
- Bien, merci. À votre avis, l'ensemble complet d'outils que nous avons en Java est-il complet et suffisant? Avons-nous besoin d'autre chose que des expressions lambda, des références de méthode, des collections avec des flux?- À mon avis, nous avons encore beaucoup à manquer. Le monde Java est en constante évolution. J'ai récemment eu un dialogue avec un homme qui a dit: "J'ai entendu dire que vous étiez dans notre ville il y a quelques années et que je me suis beaucoup disputé sur les génériques", ce à quoi j'ai répondu: "Je discute toujours beaucoup sur les génériques." Je crois qu'en Java les génériques se font très mal. Brian Goetz est toujours en colère contre moi: «Il y aura toujours quelqu'un qui se plaindra des génériques», et celui-ci, bien sûr, c'est moi. À mon avis, beaucoup peut être amélioré dans ce domaine. La réforme est très importante, à mon avis. Beaucoup peut être fait pour réduire les flatulences, se débarrasser du code passe-partout. Le code peut être rendu beaucoup plus fluide. Et un certain mouvement dans ce sens est déjà visible aujourd'hui. Java implémente maintenant la correspondance de modèles, ce qui me rend très heureux - j'aime vraiment la façon dont il est implémenté dans Scala et Kotlin. Je pense que c'est très important, et l'analogie avec une machine de traitement des billets me vient à l'esprit. Si vous lui passez un paquet de billets, il les triera en fonction de la valeur de chaque billet. De même, la correspondance de motifs dans la programmation fonctionne. Vous transmettez des données via des paramètres qui peuvent récupérer des données pour le traitement. Je pense que cela pourrait aider à se débarrasser du grand nombre d'opérateurs de succursales que nous écrivons en Java. Le code deviendra beaucoup plus expressif. En général, je pense que Java a besoin de beaucoup d'ajouts, mais, apparemment, il évolue déjà dans cette direction.
Je veux mentionner un autre aspect qui est vraiment curieux pour moi. J'ai grandi dans le monde de la programmation traditionnelle. Je n'ai pas peur d'admettre publiquement que ma première langue était Visual Basic. Dans un sens, c'est un bon langage pour la première expérience, car ça ne peut pas être pire. Ensuite, j'ai écrit longtemps en C et C ++, et la plupart du temps à partir de tous les langages que j'ai passés avec C ++. Après cela, j'ai commencé à écrire en Java, C #, des langages comme Ruby. À un certain moment, j'ai réalisé que j'écrivais toujours dans des langues avec du multithreading. Donc, connaître Node était une sorte de perspicacité - il m'a fallu un certain temps avant de découvrir la programmation asynchrone. , , — , Java. (coroutines) (continuations). , Java , , , . , Java , . , . . , , , , Java-, . , , , . Java , .
— , ? JVM-, . . ?— , . , . , , : , , , , , . , . . , , , , . Big Data. , . , . , , , -. , , . , .
, , . , . , . , , . , , , . , , , . . , , : . , 30 . , -, .
, . , , , . . . , , , . : , . , , .
— . , ? , , . , Reactive Streams, Spring Reactor, CQRS event sourcing. - , CQRS?— , , . , , — . Angular 1, , , . Angular «$» . , : « . ». , . , , , . , . — — Angular 2, , .
, , . , , API — . ? - ? , , - . . Java — — deprecated-. Angular 1 — . , , .
— - (event-driven systems), , . , -. , , API , . , . , , 5-10 , . -, , - . , . , , — , . — ++. — . , , , . - , , , . , , , .
— , , .
Java Champions, Microsoft MVP, JavaScript, . : Java ? .NET, JavaScript - ?— , Java , .NET - . # Java, , C# . . Java , # LINQ, , (, Func). C# , Java. , , Java 2014 CompletableFuture. C# .
Java JavaScript. , « JavaScript» , JavaScript , . «callback hell», , - , . JavaScript Promises (), CompletableFutures Java. : , . Promises , . — Promises . , , , . , , , , . JavaScript async await. , Promise. , , , , , . CompletableFuture , continuations Java . , coroutines Kotlin.
, , . . , , , , , , . , , . , , — , , . async C#, async/await Promises JavaScript coroutines Kotlin, , , — , , . . Java . , Java , , , , . , . , , , . Java , . , Java — .
Java. . , Java , . Java , invokedynamic, , . , JVM. Java , — . , , . , Java , Java , JVM. . , , . , Java , .
— . , , , . , 5 . — . — , Common Lisp, JavaScript Meta Object Protocol, DSL Kotlin JetBrains MPS, GraalVM Java Java . . ?— . , . , , . . -, , . -, , . , , , . , . , , . , , . , , : ? — ? , , ? , . : , Angular, — React? , React. — ? , , , , - , . , , . , , . , , — , , . , .
, . , . - : , . , : , , , , . 1 10, 10 « », 1 «». 1 10, 1 « », 10 — « ». , , . , . , . , Angular, React Java . : ? , . , : . . , , , . , , , , ; ; .
, , — . — , . . - , , . , , . , . , , . , , . , . , , , .
— , . Joker , .— , .
