"Wie viele Zuschauer werden zu Ihrem Java-Vortrag kommen?" Es kommt darauf an, ob Venkat gleichzeitig in der angrenzenden Halle auftritt. “
Dies ist ein Witz mit einer Menge Wahrheit: In der Java-Welt ist
Venkat Subramaniam einer der bekanntesten Redner, der auf Konferenzen wirklich Zuschauer aus anderen Hallen ziehen kann. Er hat sich unermüdlich um den Planeten bewegt und vor kurzem einen beeindruckenden Rekord aufgestellt, als er zum 50. Geburtstag in einem Jahr vor 50 verschiedenen Java-Benutzergruppen sprach.
Wie ist es, wenn Ihre Java-Karriere nicht "im Büro sitzt", sondern "sich ständig bewegt"? Und was hält Venkat von aktuellen Java-Problemen? Im Oktober wird er nach St. Petersburg kommen, und in Erwartung dessen haben wir (
Phillennium ,
Olegchir ) ihn ausführlich interviewt, wo wir mit „Leben im Flugzeug“ und Tipps für Anfänger begonnen haben und dann zur Technologie
übergegangen sind.
Da Venkat ausführlich antwortet, ist der Text lang. Wenn Sie möchten, können Sie sofort mit dem zweiten Teil fortfahren:
Für das Leben
- Beginnen wir mit Ihrer Tour, bei der Sie 50 Java-Benutzergruppen besucht haben, die bisher kaum jemand gemacht hat. Was waren deine Eindrücke?- Das Interessanteste für mich war die Erkenntnis, dass in verschiedenen Kulturen in verschiedenen Teilen der Welt Menschen, die trotz all dieser Unterschiede verschiedene Sprachen sprechen, durch die Programmierung als ein einziger Verbindungsfaden vereint werden. Wenn wir über Programmierung sprechen, stellt sich heraus, dass die Probleme, mit denen wir jeden Tag konfrontiert sind, dieselben sind. Dies war eine großartige Entdeckung für mich - Sie können an jedem Flughafen der Welt einen Programmierer treffen, und Sie werden auf jeden Fall gemeinsame Gesprächsthemen finden. Ich kann endlos Fälle auflisten, in denen ich auf der anderen Seite der Erde über Java gesprochen habe.
Daher war die Erfahrung mit diesen Gruppen für mich sehr nützlich. Das Verwalten einer Benutzergruppe ist sehr schwierig ... Ich möchte nicht "Arbeit" sagen, da es nicht funktioniert, aber Sie müssen viel Aufwand betreiben. Ich habe großen Respekt vor allen Führern, die diese Ereignisse jeden Monat immer wieder sammeln. Unterschiedliche Gruppen haben unterschiedliche Dynamiken - einige haben 20 oder 30 Personen bei Besprechungen, andere 200 oder 300. Trotzdem spielt die Anzahl keine Rolle, da die Hauptsache die Leidenschaft der Entwickler ist, die zu diesen Besprechungen kommen, ihr Interesse an Technologie und ihr Wunsch zu lernen. Ich hatte großes Glück, dass ich die Gelegenheit hatte, mich mit diesen Gruppen zu treffen, und ich bin sehr dankbar dafür.
- Und weisen Benutzergruppen in verschiedenen Teilen der Welt aufgrund der von Ihnen erwähnten Ähnlichkeit merkliche lokale Unterschiede auf?- Diese Unterschiede sind überraschend gering. Ich habe festgestellt, dass in einigen Regionen Schwergewichts-Frameworks und in anderen Regionen leichtere Lösungen bevorzugt werden. In der Regel sind alle diese Merkmale oberflächlich, und tiefgreifende Fragen und Probleme sind im Gegenteil universell. Ich möchte Ihnen aufrichtig sagen, dass die Leute irgendwann auf der Karte ganz andere Dinge tun als wir, und dort ist alles interessant und unerwartet, aber das kann ich nicht sagen.
Wir alle streben nach Komplexität, sie zieht uns und wenn sie schleppt, fangen wir an, dagegen anzukämpfen. Dies ist fast überall ein allgemeiner Trend. Ein weiteres wichtiges Problem, dem niemand entkommen ist, sind die strengen Anforderungen des Unternehmens und der Mangel an Zeit, um an der Qualität zu arbeiten. Ich kann mit Menschen auf der ganzen Welt über ein Beispiel sprechen, und nach meiner Geschichte werde ich gefragt: "Haben Sie zufällig in unserem Unternehmen gearbeitet?" Unsere Probleme sind so tiefgreifend und universell, dass sie anscheinend der ganzen Welt gemeinsam sind. Was uns unwillkürlich dazu bringt, über unser gemeinsames menschliches Wesen nachzudenken, über Psychologie und Philosophie, denen wir letztendlich folgen. Egal wie sehr wir uns als Geeks vorstellen, die sich der Technologie zuwenden, wir sollten den menschlichen Aspekt bei der Entwicklung von Software nicht vergessen. Anscheinend ist er eine vereinigende und universelle Kraft.
- Ich möchte nach einem "Camping" -Lebensstil fragen. Wenn Sie im Büro sitzen, ist es möglicherweise nicht offensichtlich, ob Sie ein Leben wie das Ihre möchten. Zum Beispiel ist Jetlag für viele ein Problem, und aus diesem Grund können ständige Flüge wie ein Albtraum erscheinen. Aber vielleicht passen Sie sich mit etwas Übung daran an?- Um Ihre Frage zu beantworten, erinnern wir uns an die kontinuierliche Integration. Wenn ein Team einmal im Monat eine Integration durchführt, schlagen Sie vor, dass es dies die ganze Zeit tut. Sie werden Sie für verrückt halten. In dieser Hinsicht ähneln Reisebeziehungen einer kontinuierlichen Integration und Bereitstellung: Wenn Sie viel mit ihnen zu tun haben, ändert sich Ihre Herangehensweise an sie.
Versteh mich nicht falsch, ich bin nicht stolz auf meine Lebensweise, meiner Meinung nach lohnt es sich nicht, so zu leben. Ich sage immer, dass ich auf Reisen die Reisen selbst am wenigsten mag. Das Sitzen im Flugzeug ist anstrengend, der Körper nutzt sich ab und mit zunehmendem Alter gehen diese Probleme nirgendwo hin. Aber wenn ich an mein Ziel komme, wenn ich mich mit anderen Entwicklern treffe, sehe ich ihre Leidenschaft für Technologie, ihre Begeisterung, ich bekomme die Gelegenheit, diese Leidenschaft zu teilen, etwas Neues zu lernen und dabei zu helfen, es zu lernen. Alle Schwierigkeiten zahlen sich mit Interesse aus.
Wenn wir über den Wechsel der Zeitzonen sprechen, stört mich das überhaupt nicht. Aufgrund der ständigen Flüge habe ich in gewissem Sinne keine konstante "Heimat" -Zeit. Ich habe eine Regel: Ich wache immer zur gleichen Ortszeit auf, gegen 3.30 Uhr nachts, und der Körper tritt sehr schnell in einen bestimmten Rhythmus ein. Und natürlich ist Kaffee immer sehr willkommen.
- Viele Menschen möchten die Welt sehen, aber sie unternehmen normalerweise Touristenreisen und keine Geschäftsreisen. Können Sie sich die Städte ansehen oder aus Zeitgründen nur in den Konferenzräumen?- Ja, teilweise gibt es ein Zeitproblem. Darüber hinaus habe ich aufgrund ständiger Flüge einige Grundsätze, an die ich mich halte. Wenn die Reise mit der Arbeit verbunden ist, dann mache ich nichts als Arbeit. Ich versuche so viel Zeit wie möglich mit den Entwicklern zu verbringen. Wenn ich beispielsweise in Europa einen freien Samstag oder Sonntag habe, verbringe ich ihn normalerweise in einer Benutzergruppe. Es ist mir eine große Freude, mit Entwicklern zu kommunizieren, daher gehe ich auf meinen Geschäftsreisen fast nie zu interessanten Orten.
Aber jedes Jahr reise ich im Sommer vier oder sechs Wochen lang mit meiner Familie und wir machen Sightseeing. Dies ist unsere Zeit für eine gemeinsame Pause, und in den verbleibenden Monaten konzentriere ich mich auf die Arbeit.
Darüber hinaus ermöglicht mir mein Ansatz, verschiedenen Community-Veranstaltungen maximale Aufmerksamkeit zu schenken, was mir ebenfalls große Freude bereitet. Das kostet viel Zeit und ist eine Art Kompromiss, aber es passt zu mir. Das Leben ist manchmal zu stressig, und ich freue mich über die Gelegenheit, manchmal abgelenkt zu werden und Entwicklern zuzuhören, die möglicherweise nicht die Möglichkeit haben, an einer Konferenz oder einem Schulungskurs teilzunehmen. Darüber hinaus glaube ich, dass dies auch meine berufliche Pflicht ist, weil mich diese Dinge in meiner Jugend inspiriert haben. Ich besuchte Benutzergruppen, hörte Performances und träumte in meiner Zeit auch davon, selbst aufzutreten. Wenn es mir wiederum gelingt, mindestens eine Person auf die gleiche Weise zu inspirieren, ist diese Zeit gut angelegt.
- Letzte Reisefrage. In dem Film "Up in the Air" kennt George Clooneys Charakter, der ständig zwischen Städten fliegt, viele Tricks, um die Reiseeffizienz zu verbessern: wie man in der Schlange steht, wie man Gepäck packt und so weiter. Vielleicht haben Sie auch einige nicht offensichtliche Kenntnisse, die Sie teilen möchten?„Ich schäme mich, das zuzugeben, aber ich schicke manchmal Kleidung zwischen Städten auf FedEx, weil ich einfach keine Zeit habe, nach Hause zu fliegen und Kleidung für die nächste Woche mitzunehmen. Wenn ich im Hotel ankomme, sind meine Kleider oft schon da und wenn ich gehe, schicke ich sie nach Hause. Glücklicherweise passiert dies nicht allzu oft, vielleicht drei- oder viermal im Jahr, wenn ich drei Wochen hintereinander unterwegs bin. Es gab einen unangenehmen Moment, in dem meine Frau zum Flughafen musste, um mir die Taschen zu geben, weil ich zwischen den Flügen nur eine halbe Stunde Zeit hatte. Aber im Laufe der Zeit lernen Sie wirklich, einige Dinge effizienter zu erledigen. Manchmal überrascht es mich, wenn Leute sagen "Ich muss packen", weil meine Sachen ständig gesammelt werden.
Apropos Effizienz: Ich habe mindestens einen Vorteil: Ich bin eine Person mit nur einer Aufgabe. Wir leben in der Welt von Facebook, Twitter und verschiedenen Messenger, sie lenken uns ständig ab. Ich habe hart gearbeitet, um diesen Effekt zu reduzieren, denn aus Minuten werden Stunden, aus Stunden werden Tage, aus Tagen werden Wochen, und früher oder später merkt man, dass man nicht erreichen konnte, was man wollte. Normalerweise habe ich ein Tagebuch, in das ich Dinge schreibe, die für jede Reise erledigt werden müssen. So habe ich einen Zeitplan für jeden Tag (z. B. für den 7. November oder den 8. Oktober) und mein Telefon erinnert mich an jede Aufgabe am entsprechenden Tag. Während eines achtstündigen Fluges kann ich den größten Teil eines Kapitels des Buches schreiben oder ein Beispiel für den Kurs vorbereiten. Daher sind Flüge für mich eine äußerst effektive Zeit. Ich brauche während des Fluges keine zusätzliche Unterhaltung - ausreichend Unterhaltung im Zusammenhang mit Code-Debugging ist völlig ausreichend. Ein professioneller Reisender (wenn ein solcher Begriff allgemein anwendbar ist) verbringt seine Flugzeit also ganz anders als ein Tourist.
- Wahrscheinlich erhalten Sie aufgrund Ihres Ruhms viel mehr Briefe als gewöhnliche Entwickler. Wie viel schreiben sie dir und wie viel Zeit braucht die Arbeit mit Post?- Es ist erwähnenswert, dass ich an der Universität unterrichte und viele Briefe von Studenten erhalte. Normalerweise bekomme ich 20 oder 30 Briefe pro Tag. Vor ungefähr einem Jahr
schrieb ich in einem Blog über eines meiner Prinzipien: "Antworte jetzt oder sag, wann du antwortest."
Ich schätze meine Zeit sehr, was bedeutet, dass ich die Zeit anderer Menschen schätze. Meiner Meinung nach liegt der Respekt vor einer anderen Person nicht in der Anziehungskraft von Sir, sondern darin, die Zeit des anderen zu schätzen. Wenn ein Brief bei mir eintrifft, antworte ich daher immer innerhalb von 24 Stunden. Es gibt jedoch Situationen, in denen es nicht funktioniert, eine vollständige Antwort zu geben - beispielsweise, wenn der Organisator der Konferenz eine Anmerkung senden möchte oder wenn ein Branchenkollege eine Frage zur Lösung eines bestimmten Problems stellt, einen Code umgestalten oder eine bestimmte Methode verwenden möchte. Manchmal kann die Antwort zehn Minuten und manchmal zwei Stunden dauern, aber selbst zehn Minuten können nicht immer verbracht werden. Es mag etwas seltsam klingen, aber ich antworte in solchen Fällen immer noch innerhalb von 24 Stunden und schreibe: Ich habe Ihren Brief erhalten, ich werde an diesem Problem arbeiten, sagen wir am 2. September und Ihnen den 3. schreiben. Gleichzeitig wird mein Kalender mit dem entsprechenden Eintrag an dem Tag aktualisiert, an dem ich Zeit im Flug oder am Nachmittag habe.
Dank dieses Ansatzes ist mein Posteingang immer leer, ich putze ihn jeden Abend vor dem Schlafengehen. Daher bin ich äußerst diszipliniert bei der Beantwortung von Briefen. Die Leute sind oft überrascht, dass ich so schnell auf ihre Briefe antworte, aber ich verstehe im Gegenteil nicht, wie anders. Ich möchte den Menschen nicht im Weg stehen, um sie daran zu hindern, sich zu entwickeln. Außerdem halte ich es für wichtig, nein zu sagen. Ich möchte wiederholen, dass je öfter Sie Ja sagen, desto schlechter werden Sie das bekommen, was Sie tun. In einem bestimmten Moment müssen Sie erkennen, dass wir nicht alles auf der Welt erreichen können. Deshalb antworte ich manchmal, dass ich leider nicht helfen kann. Im Gegenzug möchte ich lieber sofort nein sagen und nicht an Gummi ziehen und später nein sagen. Meiner Meinung nach spricht dies auch für Respekt vor der Person und die Unwilligkeit, ihre Zeit vergeblich zu verschwenden. Sie müssen nicht helfen, aber zumindest nicht stören. Daher ist es wichtig, nein zu sagen. So ist das Leben arrangiert. Versuchen Sie nicht, so zu tun, als könnten Sie alles auf der Welt tun. Die Fähigkeit, schnell und ehrlich zu reagieren, ist für mich ein Zeichen von Professionalität.
- Sie sind ein sehr erfahrener Redner. Als Konferenzorganisatoren treffen wir Leute, die keine Erfahrung mit öffentlichen Reden haben oder nur sehr wenige. Vielleicht haben Sie Empfehlungen für sie? Sie hatten auf Twitter einen interessanten Tipp: „Besuchen Sie die Halle, in der der Bericht im Voraus stattfinden wird“ - gibt es noch mehr?- Meine ersten Berichte waren in Benutzergruppen, weshalb ich weiterhin jedes Jahr 15 Berichte darin erstelle. Und ich empfehle anderen, mit der gleichen Sache zu beginnen: mit einer Benutzergruppe in Ihrer Region, dann mit einer benachbarten und so weiter.
Aus vielen Gründen sind diese Berichte weniger risikobehaftet als bei einer großen Konferenz: Es herrscht eine freundliche Atmosphäre, Menschen kommen dorthin, um Wissen auszutauschen, und nach Ihren Berichten können Sie leicht eine Antwort erhalten. Sie können die Präsentation sehr gut beginnen, indem Sie sagen, dass Sie wenig Erfahrung in dieser Angelegenheit haben und die Meinung des Publikums wissen möchten. Dieses Jahr hatte ich einen neuen Bericht, bei dessen Vorbereitung ich viel erlebt habe. Ich habe darüber auf Twitter geschrieben: Es scheint, dass alles in zwei Minuten gesagt werden kann, aber in Wirklichkeit kann das Material nicht in anderthalb Stunden veröffentlicht werden. Und ich bin sehr froh, dass ich diesen Bericht zum ersten Mal in einer Benutzergruppe erstellt habe, da ich die Gelegenheit hatte, ihn besser auf die Konferenz vorzubereiten.
In Benutzergruppen oder in dem Unternehmen, in dem Sie arbeiten, haben Sie eine großartige Gelegenheit, Präsentationen zu üben. Zunächst erhalten Sie Kritik von Kollegen, mit denen Sie den Bericht verbessern können. Zweitens, auch wenn sie Ihnen nichts direkt sagen, werden Sie selbst viel verstehen, wenn Sie anfangen zu sprechen. Ich glaube, dass es möglich ist, den Bericht ab dem dritten Mal wirklich zu verbessern. Das erste Mal versuchen Sie nur, alle Gedanken zusammenzubringen. Und hier ist das Interessante: Das Üben allein hilft hier nicht, das Problembewusstsein entsteht nur, wenn man mit anderen Menschen spricht. Beim dritten Mal wird die logische Kette Ihrer Erzählung für Sie klarer, sie ist abgeschlossen. Das fällt nicht immer auf, aber manchmal mache ich während meiner Rede zum dritten Mal eine Pause - in diesem Moment merke ich, was ich in dem Bericht versucht habe zu sagen, dass eine Art Moment der Wahrheit kommt. Übung ist also sehr wichtig, aber nicht allein, sondern mit Menschen. Dies kann dem jungen Entwickler das nötige Vertrauen geben.
Es stimmt, einige machen ihre ersten Berichte auf Konferenzen. Manchmal ist es für eine Person einfacher zu sterben als in der Öffentlichkeit zu sprechen, und sie ist leicht zu verstehen - es braucht viele Nerven. Vor zwei oder drei Jahren sprach ich auf einer Konferenz. Eine sehr interessierte Person kam auf mich zu und sagte, dass ich anscheinend sehr besorgt war, worauf ich antwortete, dass dies wirklich so sei. Er fragte: "Ist das Ihr erster Bericht?" Und ich antwortete: "Nein, wahrscheinlich zehntausend, deshalb mache ich mir Sorgen." Jede Aufführung vor dem Publikum erfordert viel emotionalen Stress, auch wenn Sie viel Erfahrung haben, einfach weil Sie sich darum kümmern, wie der Bericht abläuft. Sie werden einen großartigen Job machen, wenn Sie diese Spannung mit ein paar Testberichten in Benutzergruppen oder in Ihrem Unternehmen lösen. Dies gilt für alle Redner, auch für erfahrene.
- Aber gibt es in der Öffentlichkeit etwas, das im Gegenteil vermieden werden sollte?"Ich habe in meinem Leben viele Fehler gemacht, die mich gelehrt haben, dass Menschen am besten aus Erfahrung lernen." Wenn Sie mit einem Publikum sprechen, sollten Sie einige Dinge beachten. Erstens müssen Sie Ihr Selbstvertrauen bewahren: Sie haben viel an dem Thema gearbeitet und wissen viel darüber. Zweitens denken Sie daran: Es ist unmöglich, alles zu wissen, und Unwissenheit über etwas ist nicht Ihre Schuld. Es bedeutet nur, dass Sie nicht die Gelegenheit hatten, darauf zu achten, und daran ist nichts auszusetzen. Es ist äußerst wichtig, dies ehrlich zuzugeben. Sie können die Frage auf der Konferenz wie folgt beantworten: Entschuldigung, ich kann Ihnen nichts sagen, ich hatte keine Gelegenheit, dieses Problem zu untersuchen.
Ein weiterer wichtiger Punkt ist, dass die Zuhörer in drei Typen unterteilt werden können. Es gibt Leute, die etwas Neues von Ihnen lernen wollen. Andere halten sich etwas vorsichtiger, sie werden auf dich hören, aber sie werden nicht bereit sein, alles wahrzunehmen, was du sagst. Schließlich gibt es eine dritte Gruppe von Menschen, die glücklicherweise eher klein sind: diejenigen, die feindselig sind und ständig versuchen, Sie zu fangen. Früher oder später wird Ihr Bericht definitiv einen Entwickler haben, der Sie ständig unterbricht und den Fortschritt des Berichts stört. In solchen Fällen ist es sehr wichtig, ruhig zu bleiben, ihn sprechen zu lassen und die Diskussion in die von Ihnen gewünschte Richtung zurückzubringen - aber ich muss zugeben, ich bin auch eine Person, und das gelingt mir nicht immer. Sie können zum Beispiel sagen: Ich verstehe, dass dies für Sie wichtig ist. Lassen Sie uns dies nach dem Bericht diskutieren. Dieses Thema ist für viele hier wichtig. Es stimmt, sehr oft haben Sie Verbündete im Publikum, und wenn eine Person wirklich gegen den Verlauf ihrer Rede verstößt, wird sie gebeten, sich zu beruhigen. All dies sage ich zu der Tatsache, dass es wichtig ist, in solchen Situationen nicht zu konfliktreich zu sein, auch wenn unsere Natur dem widerstehen kann. Als junger Redner bin ich ziemlich oft mit voller Kraft in solche Konfrontationen eingetreten, und das hat niemandem etwas Gutes gebracht. Es ist notwendig, emotionale Reife zu zeigen und nicht zu versuchen, irgendjemandem etwas über sich selbst zu beweisen, wenn man in diese Art von Gefecht eintritt. Stattdessen sollte in solchen Fällen das Thema auf das zurückgeführt werden, was für das Publikum interessant ist.
Ich möchte auch über einige negative Gewohnheiten während der Aufführungen sprechen, die meiner Meinung nach die Entwickler haben. Für den Anfang sollten die Leute in ihre Augen schauen. Ich verstehe, dass dies sehr schwierig ist und viel emotionale Anstrengung erfordert, aber Sie müssen dies üben. Die Sprecher schauen oft auf ihren Monitor oder, noch schlimmer, auf den Bildschirm und stehen mit dem Rücken zum Publikum. Sie müssen immer dem Publikum gegenüberstehen und es immer ansehen. Darüber hinaus muss das Selbstvertrauen gewahrt bleiben. Sie sprechen mit einem Publikum von Programmierern, und Sie können darauf wetten, dass keiner von ihnen Code hat, der beim ersten Mal funktioniert. Wenn Ihre Demonstration während der Präsentation nicht funktioniert hat, ist daran nichts auszusetzen. Alle Anwesenden werden höchstwahrscheinlich denken: "Verdammt, bei mir ist alles genau gleich." Im Laufe der Jahre habe ich in solchen Situationen gelernt, mich an das Publikum zu wenden, um Hilfe beim Debuggen zu erhalten. Normalerweise murmeln Sprecher in einer solchen Situation etwas vor sich hin und versuchen, alle Schwierigkeiten selbst zu lösen. Stattdessen solltest du das Publikum fragen - Freunde, kannst du mir sagen, wo ich dumm bin?
Sie erhalten sofort viele Angebote, die Ihnen sehr oft dabei helfen, den Fehler zu finden. Es ist schwierig für eine Person, gleichzeitig Code zu sprechen und zu schreiben. Haben Sie keine Angst, um Hilfe zu bitten. Für die Zuhörer ist diese Erfahrung ebenfalls wertvoll. Dies ist einer der Gründe, warum ich die Berichte anderer Leute besuche: um zu sehen, was sie tun und um zu verstehen, was genau nicht getan werden sollte. Meiner Meinung nach helfen Ihnen diese Gewohnheiten dabei, Ihre Sprecherfähigkeiten zu verbessern.
Über Technologie
— 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 , , .
- Im Zusammenhang mit "weniger bombastischem Java" ist es unmöglich, Sie nicht nach Kotlin zu fragen, was oft so genannt wird."Ja, das ist wahr." Und die Sache ist nicht nur weniger anspruchsvoll. Für mich ist es eines der aufregendsten Dinge im Leben, neue Sprachen und ihre Fähigkeiten kennenzulernen. Eine Möglichkeit in Kotlin besteht darin, ein Lambda im Kontext eines Objekts auszuführen, obwohl es nicht Teil der Klasse ist. Ich wurde sehr interessiert, als ich herausfand, weil die gleiche Möglichkeit in JavaScript vorhanden ist. Dort können Sie ein Kontextobjekt im Aufruf übergeben (was Kotlin Empfänger nennt) und dann diese beliebige globale Funktion ausführen, als wäre es eine Funktion eines Objekts. Die Tatsache, dass diese Funktion in JavaScript enthalten ist, ist nicht überraschend, da diese Sprache dynamisch ist. Aber Kotlin ist eine statische Sprache, und sie tut das Gleiche unter Berücksichtigung der Typensicherheit. Der Mangel an Anmaßung ist natürlich ein großer Vorteil der Sprache, ebenso wie die Tatsache, dass sie einen wesentlichen Teil des Codes automatisch generiert, so dass wir nicht immer wieder dieselben Vorlagen schreiben können. Die Vorteile enden jedoch nicht hier, da Sie mit dieser Funktion interne DSLs erstellen können.
Wissenschaft und Mathematik haben mich zum Programmieren geführt, aber 30 Jahre später bleibe ich Programmierer, weil dies Kunst ist. Unser Gebiet verbindet Wissenschaft und Kunst, daran führt kein Weg vorbei. Die Möglichkeit, das System einfach zum Laufen zu bringen, ist nicht eingeschränkt. Hier können Sie eine Analogie zum Schreiben von Gedichten ziehen: Bitten Sie zwei Personen, über Liebe zu schreiben, und jeder schreibt auf seine Weise. Der Code für jede Aufgabe kann auf viele verschiedene Arten geschrieben werden. Dies ist es, was mich an Sprachen wie Kotlin und vielen anderen interessiert: Die Fähigkeit, einige dieser Ideen auszudrücken, verleiht dem Code Flexibilität und Leichtigkeit. Sie können viel weniger über die Syntax der Sprache nachdenken als vielmehr über den Gedanken, den Sie vermitteln möchten.
- Die Qualität des Codes ist für Sie von großer Bedeutung. Es scheint für alle wichtig zu sein und es scheint, als ob jeder besser schreiben möchte, aber es ist bekannt, dass ein erheblicher Teil des vorhandenen Codes Probleme hat. Daher lautet die Frage: Damit Ihre Kollegen Sie nicht für Ihren Code hassen, brauchen Sie nur Selbstdisziplin. Können Sie konkrete Empfehlungen geben?"Ich bin überzeugt, dass der einzige Weg, lesbaren Code zu schreiben, darin besteht, ihn zu lesen." Wenn sie mir sagen, dass der Code lesbar ist, frage ich - wer hat ihn gelesen? Wenn der Autor es unmittelbar nach dem Schreiben selbst gelesen hat, zählt dies nicht. Daher glaube ich fest an die Überprüfung von Codes. Ich möchte klarstellen: Ich bin dagegen, ein Team in einen Raum mit großem Bildschirm zu bringen, Code darauf zu zeigen und ihn zu kritisieren. Dies führt unweigerlich zu Beschwerden, solche öffentlichen Okhayanie ist niemand gut.
Wir müssen ehrlich zugeben: Wir alle schreiben schlechten Code. Ich bin stolz zuzugeben: Mein Code ist scheiße, ich weiß nicht, wie man guten Code schreibt. Wenn Sie fragen, wie dies zu meinem Vortrag über Codequalität passt, werde ich antworten: Das Schreiben von Code ist ein Prozess mit ständiger Innovation, und wenn Sie versuchen, eine Idee umzusetzen, stört Sie die Qualität des Codes nicht allzu sehr. Es ist immer notwendig, zurück zu kommen und umzugestalten, und selbst wenn ich das tue, funktioniert normalerweise nichts für mich. Aber im Laufe der Jahre wurde mir klar, dass mein eigener Code zwar Basis ist, ich aber sehr gut Fehler im Code eines anderen finden kann. Anstatt vorzutäuschen, dass mein Code bereits so gut ist, werde ich ihn so gut wie möglich schreiben und Ihnen zur Überprüfung geben, während ich in der Zwischenzeit den Code meines Kollegen nehme und überprüfe. Infolgedessen sind sowohl mein Code als auch der Code meines Kollegen von höherer Qualität.
Es ist sehr wichtig, den falschen Stolz aufzugeben. Ich erinnere Entwickler immer daran, dass sie Teil eines Teams sind. Es macht keinen Sinn, miteinander zu konkurrieren und herauszufinden, wer cooler ist, nein. Ich bin bereit, ehrlich zuzugeben, dass mein Wissen ziemlich begrenzt ist - aber was ich weiß, weiß ich gut. Und mein Kollege hat auch sehr tiefe Kenntnisse in einem anderen Bereich. Gemeinsam werden wir stärker, wenn wir bereit sind, voneinander zu lernen. Daher empfehle ich immer, den Code des anderen zu überprüfen, und zusätzlicher Stolz ist hier völlig nutzlos. Man muss ehrlich miteinander umgehen, das ist eine der wichtigsten Eigenschaften eines guten Teams. Ehrlichkeit sollte nicht bestraft werden, wenn jemand zugibt, einen schlechten Code geschrieben zu haben - das ist normal. Wir legen die Messlatte höher, indem wir uns gegenseitig Möglichkeiten zur Verbesserung des Codes anbieten.
Ein weiterer wichtiger Punkt: Sie müssen einer Person nicht sagen, dass sie einen Fehler gemacht hat. Es muss gesagt werden, was genau verbessert werden kann. Sagen Sie nicht: "Gott, was für ein schrecklicher Name für eine Variable", es ist besser so: "Sie wollten wahrscheinlich sagen, dass diese Variable die Häufigkeit der Verteilung anzeigt - wahrscheinlich sollte sie entsprechend aufgerufen werden." Dies wird Ihnen helfen, Ihre Absichten besser zu vermitteln. Dies gilt auch für die Buchbearbeitung: Sprechen Sie nicht nur darüber, was verbessert werden muss, sondern auch darüber, was gut gemacht wurde. Wir vergessen das oft. Wenn ich den Code eines anderen bearbeite und einen Ort sehe, der gut ausgeführt ist, schreibe ich in einem Kommentar, dass es mir wirklich gefällt, dass wir dies öfter tun müssen, und erkläre, warum. Dies schafft konstruktives Feedback, macht dem Entwickler klar, dass Sie ihm gegenüber nicht feindlich eingestellt sind, und verbessert letztendlich die Qualität des Codes Ihres Teams.
- Sie haben geschrieben, dass die Verwendung eines Werkzeugs, das Sie in Sehnsucht treibt, wie das Feststecken in einer giftigen Beziehung ist: In dieser Situation müssen Sie nur gehen und so schnell wie möglich. Das hört sich toll an, aber oft hat das Instrument keine besondere Alternative, und was dann?- Eine völlig berechtigte Frage. In der Tat gibt es Situationen, in denen es keinen Ort gibt, an den man gehen kann. Aber ich habe eher von solchen Fällen gesprochen, in denen es noch eine Wahlmöglichkeit gibt und nur der Wunsch fehlt, sie zu treffen. Meiner Meinung nach ist dies ein wesentlicher Faktor.
Wenn es keine andere Wahl gibt, als sich zu beschweren, sollten Schmerzpunkte identifiziert werden: Was genau macht dieses Tool für Sie unangenehm? Und dann können Sie es auf verschiedene Arten tun. Sie können sich an die Entwickler wenden und sagen - danke für Ihre Arbeit, es scheint uns, dass Ihr Tool viel besser sein könnte, wenn Sie auf diesen und jenen Aspekt achten. Oder Sie können einen Hackathon veranstalten - treffen Sie sich am Wochenende mit mehreren Entwicklern, organisieren Sie eine Benutzergruppe, sagen Sie ihnen, dass Sie neun Stunden am Tag mit diesem Tool verbringen, dass es schrecklich ist, und bitten Sie sie, einige Funktionen hinzuzufügen.
Vielleicht können Sie nicht alle Probleme alleine lösen, aber zumindest können Sie andere Menschen zusammenbringen und dieses Problem mit ihnen lösen, insbesondere wenn ihre Interessen Ihren ähnlich sind. Wenn Ihr Tool Ihnen wirklich so viele Probleme bereitet, können Sie versuchen, selbst ein neues zu schreiben - wenn Sie drei oder vier Freunde in der Community haben, die dieselbe Einstellung wie Sie haben.
Meiner Meinung nach gibt es also immer noch Alternativen. Sie müssen sich keine toxische Beziehung gefallen lassen. Sie müssen immer in der Lage sein, einen Ausweg zu finden - entweder mit einem Partner einverstanden zu sein und gegenseitiges Verständnis zu erreichen oder zu gehen.
- Sie haben ein Buch über Lambdas geschrieben und sind dank dieses Buches bekannt. Ich habe es auch gelesen und glaube, dass es wunderschön geschrieben ist, das gibt, was der Anwendungsentwickler braucht, und nichts Überflüssiges gibt. Als echter Profi möchte ich Sie fragen: Was ist funktionale Programmierung für Sie? Könnten Sie es in Ihren eigenen Worten beschreiben? Ich stelle diese Frage, weil jeder sie ein wenig auf seine eigene Weise definiert und jedes Mal verborgene Bedeutungen aufgedeckt werden, die von der Standarddefinition von Wikipedia abweichen.- Das ist eine wunderbare Frage. Mein Verständnis dieses Konzepts hat sich im Laufe der Jahre weiterentwickelt, und jetzt ist für mich das Wichtigste in der funktionalen Programmierung die Beseitigung von Fremdkomplexität. Wir sprechen über die Tatsache, dass Sie in der imperativen Programmierung nicht nur angeben, was zu tun ist, sondern auch detailliert vorschreiben, wie dies zu tun ist. Für mich ist die funktionale Programmierung ein Add-On zum deklarativen Programmierstil, in dem wir angeben, was zu tun ist, aber nicht sagen, wie.
Lassen Sie mich Ihnen eine primitive Analogie geben: Meine besten Freunde lieben Autos, aber sie interessieren mich überhaupt nicht. Wenn wir uns treffen, sind wir uns einig, nicht über Autos zu diskutieren, weil wir Freunde bleiben wollen. Ich werde niemals ein Auto mit Schaltgetriebe fahren - die Notwendigkeit, ständig zu schalten, verdirbt meine gesamte Fahrt, und das gilt auch für den zwingenden Programmierstil. Das Automatikgetriebe erleichtert das Fahren ein wenig, aber für mich ist es die beste Option, wenn der Fahrer mich fährt. In diesem Fall sage ich nur, wo ich hin muss, und schreibe unterwegs den Code auf meinen Laptop auf dem Rücksitz. Für mich ist dies der Unterschied zwischen imperativer und funktionaler Programmierung. Mit zwingender Programmierung fahren Sie selbst, Sie müssen wissen, wohin Sie gehen müssen, wie Sie gehen müssen, wohin Sie abbiegen müssen, wo Sie schneiden können. Mit der funktionalen Programmierung sitzen Sie auf dem Rücksitz und sagen dem Fahrer, wohin er Sie bringen soll, und Ihre Aufmerksamkeit ist voll und ganz auf Ihre Arbeit gerichtet.
Wie wird diese überflüssige Komplexität beseitigt? Durch die Zusammensetzung von Funktionen. Beim Erstellen von Funktionen wird Ihr Code einer Reihe von Transformationen unterzogen, bei denen Daten von einem Formular in ein anderes übertragen werden. Darüber hinaus ist es für uns nicht wichtig, wie jeder dieser Schritte ausgeführt wird, sondern was genau er erreicht. Für mich ist der erste Aspekt der funktionalen Programmierung die funktionale Komposition. Das Problem ist, dass viele Sprachen, in denen die funktionale Komposition implementiert ist - Ruby, Python, JavaScript, Groovy usw. - aufgrund dessen Eleganz und Ausdruckskraft bieten, aber eine sehr geringe Leistung aufweisen. Die funktionale Zusammensetzung in ihnen ist ineffizient implementiert. Ich glaube, dass Eleganz ohne Effizienz nicht realisierbar ist. Der Code sollte nicht nur schön sein, sondern auch schnell funktionieren. Und hier kommen wir zum zweiten wichtigen Aspekt der funktionalen Programmierung - wir sprechen von Lazy Computing. Das Ergebnis einer bestimmten Funktion wird nur zu dem Zeitpunkt berechnet, zu dem es benötigt wird. Dadurch wird eine Kombination aus Eleganz und Effizienz in der funktionalen Programmierung erreicht. Für mich ist funktionale Programmierung ein Schwerpunkt darauf, was zu tun ist, nicht wie es zu tun ist. Verwendung der funktionalen Zusammensetzung als eine Reihe von Datentransformationen; und die Fähigkeit, diese Transformationen dank Lazy Computing effizient durchzuführen.
Bitte beachten Sie, dass ich nicht über Immunität und Funktionen höherer Ordnung gesprochen habe. Tatsache ist, dass sie nur Zutaten sind, um das von mir beschriebene Ergebnis zu erzielen. Wir verwenden funktionale Programmierung nicht für Immunität und Funktionen höherer Ordnung, sie sind nur ein Mittel, um ein höheres Ziel zu erreichen: überflüssige Komplexität loszuwerden.
- Großartige Definition. Heute gibt es eine Sprache, die den Maßstab für die funktionale Programmierung darstellt: Haskell (und möglicherweise F #).- Das stimmt.
"Zumindest viele Leute denken so." Aber Java ist offensichtlich nicht Haskell, es ist weitgehend begrenzt. Ist funktionale Programmierung als Disziplin sinnvoll, wenn sie auf Java angewendet wird? Schließlich verfügt unsere Sprache nur über sehr begrenzte Werkzeuge für diesen Ansatz.- Für mich ist eher der pragmatische Aspekt als das Streben nach Exzellenz wichtiger. Ich bin neugierig auf Perfektion, aber damit alles funktioniert, muss ich Pragmatiker sein. Ich bin verrückt nach Haskell und verbringe viel Zeit mit ihm, nur um herauszufinden, wie eine bestimmte Aufgabe in der funktionalen Programmierung gelöst wird. Aber für meine Kunden schreibe ich nicht über Haskell. Hier können Sie eine Analogie zur "Kathedrale und zum Basar" ziehen. Die Kathedrale ist wunderschön, aber die meiste Zeit verbringe ich auf dem Basar. Die Frage ist, wie man in dieser Welt überlebt. Wenn sich Sprachen weiterentwickeln und wir versuchen, verschiedene Paradigmen miteinander zu kombinieren, müssen wir als Programmierer bei ihrer Implementierung äußerst vorsichtig sein.
Ich denke nicht, dass funktionale Programmierung in Java überhaupt unmöglich ist. In Situationen, in denen es eine Wahl gibt, werde ich mich auf die für mich am besten geeignete Sprache konzentrieren. Aber ich werde dem Kunden niemals sagen: Sie sollten diese Sprache verwenden. Meistens frage ich, was genau sie tun, und versuche, im Rahmen der bereits vorhandenen Umgebung einen Weg zu finden, dies auch optimaler zu tun. Ich glaube, dass in Sprachen wie Java eine Kombination aus zwingender und funktionaler Programmierung durchaus möglich ist und sogar empfohlen wird, aber dies sollte mit äußerster Vorsicht geschehen. Stellen Sie sich vor, Sie haben eine Art Kreis reiner Funktionen, um den sich ein Ring der Unreinheit befindet. Alles, was Sie ändern möchten, muss sich außerhalb des Kreises befinden. Innerhalb dieses Kreises können Sie Ihre eigene Funktionskette implementieren, aber alle Änderungen müssen außerhalb des Kreises liegen.
Dies ist einer der Gründe, warum ich gerne neue Sprachen lerne. Ich habe kürzlich die Elm-Sprache kennengelernt, eine Haskell-Syntax mit F # -Stersperses, die in JavaScript kompiliert wird. Dieser Ansatz hat mich von Anfang an interessiert, weil JavaScript ein Basar ist. Wenn Sie durch JavaScript reisen, treten Sie ständig in Pfützen. Dank Haskells Syntax ist Elm definitiv eine Kathedrale. Trotzdem kann dieser konziliare Code auf dem Basar ausgeführt werden. Die Architektur von Elm ist elegant, es gibt ein Modell (dh Daten), es gibt eine Ansicht, in der diese Daten angezeigt werden, und es gibt eine Transformation, ein Update. Das erste Hauptprinzip ist, dass Daten im Blickfeld gespeichert werden. Wenn der Benutzer eine Aktion ausführt (z. B. eine Taste drückt), werden die Daten aus der Ansicht an die Aktualisierungsfunktion gesendet, in der die Konvertierung stattfindet. Die Daten sind unveränderlich und die Aktualisierungsfunktion gibt neue Daten zurück, die in der Ansicht anstelle der alten gespeichert werden.
Wenn Sie darüber nachdenken, dann funktioniert Redux genauso. Es sind Daten darin und Reduzierungen vorhanden. Wenn Daten an Reduzierungen gesendet werden, erhalten Sie im Gegenzug eine neue Kopie, die Sie anstelle der alten speichern. Wenn Elm und Redux jedoch nach demselben Schema arbeiten, kann dasselbe Schema in Java implementiert werden. Wir können reine Funktionen erstellen, die Daten aufnehmen, transformieren und eine neue Kopie zurückgeben. Indem wir von Redux und Elm lernen, können wir die Java-Architektur funktionaler machen. Ich spreche darüber, weil Redux in JavaScript kompiliert, das einzigartig ein Basar ist. Ich denke, JavaScript ist am weitesten vom Ideal der funktionalen Reinheit entfernt, hier tritt man bei jedem Schritt in eine Pfütze. Trotzdem bietet Ihnen Redux funktionale Reinheit in dieser extrem unreinen Welt. Dieser Ansatz hat mich sehr beeinflusst, weil er meine Sicht auf funktionale Programmierung verändert hat und gezeigt hat, dass ich diese Prinzipien auch in Java implementieren kann.
- Gut, danke. Ist Ihrer Meinung nach der gesamte Satz an Tools, über die wir in Java verfügen, vollständig und ausreichend? Benötigen wir außer Lambda-Ausdrücken, Methodenreferenzen und Sammlungen mit Streams noch etwas anderes?- Meiner Meinung nach haben wir noch viel zu vermissen. Die Java-Welt entwickelt sich ständig weiter. Ich hatte kürzlich einen Dialog mit einem Mann, der sagte: „Ich habe gehört, dass Sie vor einigen Jahren in unserer Stadt waren und viel über Generika gestritten haben“, worauf ich antwortete: „Ich streite immer viel über Generika.“ Ich glaube, dass in Java Generika sehr schlecht gemacht werden. Brian Goetz ist die ganze Zeit wütend auf mich: „Es wird immer jemanden geben, der sich über Generika beschwert“, und dieser bin natürlich ich. Meiner Meinung nach kann in diesem Bereich viel verbessert werden. Reformation ist meiner Meinung nach sehr wichtig. Es kann viel getan werden, um Blähungen zu reduzieren und den Code auf der Kesselplatte loszuwerden. Der Code kann viel flüssiger gestaltet werden. Und eine gewisse Bewegung in diese Richtung ist bereits heute sichtbar. Java implementiert jetzt Pattern Matching, was mich sehr freut - ich mag die Implementierung in Scala und Kotlin sehr. Ich denke, das ist sehr wichtig, und mir fällt die Analogie zu einer Banknotenverarbeitungsmaschine ein. Wenn Sie ein Bündel von Banknoten durchlaufen, werden diese nach dem Wert jeder Banknote sortiert. Ebenso funktioniert der Mustervergleich bei der Programmierung. Sie übergeben Daten über Parameter, mit denen Daten zur Verarbeitung abgerufen werden können. Ich denke, dies könnte helfen, die große Anzahl von Zweigoperatoren, die wir in Java schreiben, loszuwerden. Der Code wird viel ausdrucksvoller. Im Allgemeinen glaube ich, dass Java viele Ergänzungen benötigt, aber anscheinend bewegt es sich bereits in diese Richtung.
Ich möchte noch einen Aspekt erwähnen, der mich wirklich interessiert. Ich bin in der Welt der traditionellen Programmierung aufgewachsen. Ich habe keine Angst, öffentlich zuzugeben, dass meine Muttersprache Visual Basic war. In gewisser Hinsicht ist dies eine gute Sprache für das erste Experiment, da es nicht schlimmer sein kann. Dann habe ich lange in C und C ++ geschrieben und die meiste Zeit aus allen Sprachen, die ich mit C ++ verbracht habe. Danach begann ich in Java, C #, Sprachen wie Ruby zu schreiben. Ab einem bestimmten Punkt wurde mir klar, dass ich immer in Sprachen mit Multithreading schrieb. Das Kennenlernen von Node war also eine Art Einsicht - es dauerte eine Weile, bis ich die asynchrone Programmierung herausfand. , , — , 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 . : ? , . , : . . , , , . , , , , ; ; .
, , — . — , . . - , , . , , . , . , , . , , . , . , , , .
"Danke, das ist eine großartige Antwort." Auf unserer Joker-Konferenz werden Sie auch über Komplexität sprechen , damit Sie die Diskussion dort fortsetzen können.- Ja, ich werde mich mit Begeisterung darauf freuen.