Ein Tag bei Alpha Lab: Java-Entwicklung



    Wir führen häufig technische Interviews mit Unternehmen, die auf unseren Konferenzen vertreten sind. Mit der IT-Abteilung der Alfa-Bank ging man jedoch noch einen Schritt weiter: Sie schickte nicht nur Fragen an einen Entwickler, sondern verbrachte den ganzen Tag im Büro und befragte Backender, Front-End- und Mobiltelefone. So ergibt sich am Ende ein ganzes Bild - von den eingesetzten Technologien bis zur allgemeinen Herangehensweise des Unternehmens.

    Sie dachten, sie würden einen "Vollstapel" -Text erstellen, aber es gab so viel Material, dass wir es in Teile teilen mussten. Und jetzt vor Ihnen ist der "Morgen" erste Teil, in dem sie mit Java-Entwicklern Maxim Gorelikov und Kirill Tolkachev gesprochen haben . Beide haben kürzlich auf unserer Joker-Konferenz gesprochen.


    Maxim Gorelikov


    - Sagen Sie mir zunächst, wie viel Zeit Sie in der Firma haben, zu welcher Position Sie ursprünglich gekommen sind und was machen Sie jetzt?

    - Ich bin Mitte 2015 zu Alpha gekommen. Am alten Ort habe ich viele Dinge entwickelt, ich habe mich mit Architektur beschäftigt, aber dann bin ich gekommen und habe gemerkt, dass ich eine Teekanne bin. Die Jungs vom Sense-Team sprachen mit mir und riefen mich an, aber ich konnte es nicht ablehnen, der Technologie-Stack war sehr interessant.

    Wenn Sie nicht gehört haben, war Sense ein solches Startup innerhalb der Bank, ein persönlicher Finanzassistent in Form einer mobilen Anwendung. Er wurde bei einem der jährlichen Hackathons geboren. Die Idee und der Prototyp sind gut gelaufen, das Geld wurde für das Projekt und das Team, das sie entwickelt hat, bereitgestellt. Der Sinn lebt noch, aber im Allgemeinen werden seine Funktionen jetzt langsam auf die Hauptanwendung der Bank übertragen.

    Generell habe ich hier als Java-Entwickler in einem reinen Produktteam angefangen. Ich habe ein paar Jahre lang viel gelernt, an verschiedenen Projekten teilgenommen und arbeite jetzt hauptsächlich an Infrastruktur, Tools für Entwickler und Stabilitätsaufgaben.

    - Es ist interessant, aber war eine solche Umwandlung einer Hackathon-Idee in ein echtes Produkt einer Bank, oder gibt es andere Beispiele?

    - Nicht isoliert. Zum Beispiel haben wir letztes Jahr an einem Hackathon mit einem Team teilgenommen, das nur aus Entwicklern bestand (ohne Produktbesitzer, Designer usw.). Das Team kam ziemlich eng zusammen: Wir haben die Laptops eigentlich 24 Stunden lang nicht verlassen, sodass wir am Ende wie eine Zitrone zusammengedrückt wurden. Und so gab es ein Projekt für andere Alpha-Entwickler ... Ich habe Angst, das Wort "Plattform" auszusprechen, weil alle Unternehmen, wenn sie ein wenig wachsen, etwas unter diesem Namen formen. Warum haben wir unsere "Plattform" gestartet:

    Das Unternehmen wächst aktiv, wir stellen nicht immer sofort Leute mit der gewünschten Erfahrung ein. Manchmal kommen Neulinge mit wenig Erfahrung, aber ihre Augen brennen. Nach den JUG-Treffen kommen die Leute und schauen sich um: "Oh, Cyril ist vorbeigekommen!" Sie kommen hierher, nur um zu lernen. Damit eine solche Person zunächst kein Feuerholz zerbricht und schneller beitritt, haben wir uns irgendwann entschlossen, eine solche Plattform zu schaffen, die die Eintrittsschwelle senkt. Sie können damit schnell Services mithilfe von Vorlagen und Bibliotheken erstellen.

    Irgendwann haben wir es herausgefunden und festgestellt, dass neue Teams viel Zeit damit verbringen, Projekte in JIRA einzurichten und Jenkins für sich selbst zu sammeln. . Und wir haben etwas getan, das all diese Dinge integriert: Die Entwicklerin drückte den Knopf und sie richtete das Projekt in JIRA ein, erstellte einen Job in Jenkins und so weiter, bis sie den Code generierte und eine Pull-Anfrage mit einer Art Service-Basis erstellte. Wenn die Assembly dieses Dings angezeigt wird, kann der Entwickler auf Bereitstellen klicken, und alles wird für einen Test bereitgestellt. Dank dessen beginnt der Entwickler schnell zu verstehen, wie alles abläuft, und erkennt die grundlegende Struktur des Service, der in diesem Produkt übernommen wird, und versteht seinen Stil.

    - Und müssen die Hackathon-Projekte den tatsächlichen Bedürfnissen der Bank entsprechen, oder können Sie dort etwas ganz anderes tun?

    - Es gab absolut verrückte Ideen, die nur zum Spaß gemacht wurden, es macht keinen Sinn, sie später ernsthaft zu bewerben, aber dabei hatten alle viel Freude. Zum Beispiel haben Cyril und ein großes Team bei einem der Hackathons einen intelligenten Kühlschrank gebaut. Das passt in der Regel nicht zu den Hauptprodukten der Bank, hat aber 24 Stunden Spaß gemacht. Wir saßen, löteten, parsten eine Art Lebensmittelgeschäft. Mitten in der Nacht erinnerten sie sich plötzlich daran, dass es keinen Kühlschrank gab. Eine Person aus dem Team holte ihn nachts und brachte ihn mit, verdiente solch einen ZIL:



    Ich nehme Alpha im Allgemeinen als einen Ort wahr, an dem Experimentierfreude herrscht. Wenn ein Team aus sieben Personen besteht, sind dies Entwickler auf allen Ebenen (von Java bis iOS), und sie können die Infrastruktur auch entsprechend der Devs-Religion organisieren, wodurch die Atmosphäre eines Startups erhalten bleibt. Dieses Team selbst kann alle seine Probleme lösen und Entscheidungen treffen.

    - Normalerweise wird das Wort „Bank“ nicht mit den Worten „Experimentierfreude“ assoziiert, sondern im Gegenteil mit Sicherheit, Vorsicht und Konservativismus. Wie viel ist es möglich, unter Ihren Bedingungen zu experimentieren? Können Sie etwas "Interessantes, aber noch nicht den Industriestandard" wie Kotlin verwenden? Und wie schnell wechseln Sie zu ihnen, wenn neue Versionen von Java oder Spring herauskommen?

    - Es ist klar, dass wir auf jeden Fall Stabilität brauchen. Gleichzeitig ist es jedoch nicht erforderlich, die neue Version direkt in die Produktion zu ziehen. Es sind ziemlich viele Aufgaben im technischen Rückstand. Wir schreiben einige Werkzeuge, wenn es keine fertigen gibt, die uns vollkommen befriedigen, können Sie mit ihnen experimentieren.

    Darüber hinaus haben Projekte wie Sense in einer Bank manchmal Pilotstatus. Das heißt, es gibt einen kleinen Kundenstamm, und dort können Sie einige Dinge ausprobieren. Und ein Teil des Stapels, der sich jetzt in Alpha befindet, stammte von Sense, einige von anderen Projekten. Sagen wir einfach, es gibt Raum zum Experimentieren. Natürlich kämpfen wir nicht um Release-Kandidaten und Technologien mit drei Sternen auf GitHub. Aber um neue Technologien einzuführen, gibt es kein grundsätzliches Problem.

    Die Entscheidung treffen die am Produkt arbeitenden Teams. Wenn es ein Produkt gibt, auf dem drei Entwicklungsteams sitzen und eines Kotlin in die Schlacht ziehen möchte, muss er die Javisten von den anderen Teams überzeugen. Und um es im gesamten Unternehmen bekannt zu machen, und dies wurde Anfängern empfohlen, muss er die Leute von anderen Produkten überzeugen.

    Über die Geschwindigkeit des Übergangs zu neuen Versionen - von Fall zu Fall, hängt davon ab, wie viel wir wirklich brauchen. Unter Java 9 scheint noch kein Projekt verschoben worden zu sein, es wurde jedoch vor nicht allzu langer Zeit veröffentlicht. Aber mit Spring 5 experimentieren wir gerade, beim letzten Joker habe ich nur darüber gesprochen. Die Zeit naht, es gibt interessante Features und sobald zum Beispiel Spring Boot 2.0 herauskommt, wird es möglich sein, einen Teil der darauf befindlichen Microservices zu überholen. Höchstwahrscheinlich wird es eine recht schnelle Migration einiger Microservices geben, aus der Kategorie "Es gab eine Veröffentlichung - einige Microservices werden in der nächsten Woche oder Ende dieser Woche erscheinen." Da ich die Meilensteinversionen bereits ausprobiert habe und in der Veröffentlichung sicherer bin, werde ich wissen, welche Bugs dort bereits geschlossen sind, welche kritischen noch vorhanden sind.

    - Und strenge Anforderungen seitens der Gesetzgebung („solche und solche Informationen zu speichern“) und der Sicherheit („damit diese Informationen Außenstehenden nicht zur Verfügung stehen“) führen nicht dazu, dass man sich statt einer Fantasie mit tausend langweiligen Anforderungen an Punkte auseinandersetzen muss?

    - Im Gegenteil, dies ist genau ein großartiger Raum für Experimente. In der Vergangenheit hat Joker Ilya Sergeev einen Bericht über unsere Protokollierungsinfrastruktur erstellt, in dem wir eine Reihe verschiedener Technologien ausprobiert haben, die wir zuvor noch nicht ausprobiert hatten. Und diese Infrastruktur entstand, als eine bestimmte Menge von Informationen mit einer bestimmten Speicherdauer und mit Zugriff für einen bestimmten Personenkreis gespeichert werden musste.

    Vorher haben wir die Protokolle direkt in Elastic geladen. In diesem Fall ist es jedoch praktisch, Dashboards und Monitore zu erstellen. Wenn Sie jedoch jemanden zulassen, der versucht, eine Menge Daten auf einmal von dort zu entladen, ist es wahrscheinlich, dass er alles ablegt. Und wir haben die Protokollierungsinfrastruktur über Kafka und die Warteschlangen aufgebaut, damit diejenigen, die damit arbeiten müssen, jederzeit in diese Warteschlange gelangen und die neuesten Daten von dort entladen können. Und wie viel sie gespeichert werden und in welcher Form - das ist, sagen wir, ihre Aufgabe.

    Wer mit uns experimentieren will, findet immer worauf.

    Aus Sicherheitsgründen haben wir natürlich Einschränkungen bei der Vergabe von Zugriffen. Aus der Kategorie "Nicht jeder Produktionscluster kann auf das gesamte Internet zugreifen." Bei Piloten etwas mehr Handlungsspielraum. Seriöse Produkte, bei denen es viele Kunden gibt, sind die Risiken größer - es gibt schwerer. Manchmal verhandeln wir mit den Sicherheitsleuten. Manchmal bauen wir die Infrastruktur und die Tools so auf, dass kein Zugriff erforderlich ist - wir versuchen, nichts manuell zu konfigurieren, alles erfolgt automatisch.



    - Von der Seite gesehen scheint die Bank eine strenge Organisation mit Strafen für eine Minute Verspätung zu sein - aber haben Sie in der Praxis feste Arbeitszeiten oder nicht?

    - Nein. Cyril ist noch nicht im Büro erschienen, weil gestern die neue Hardware eingetroffen ist, wir begonnen haben, auf neue Protokollierungscluster umzusteigen, wir haben neue Schemata eingeführt, alle haben sich verspätet verteilt, und Cyril wurde mitgerissen und saß bis in die Nacht - heute wird er später als gewöhnlich kommen.

    Mit dieser Freiheit führen einzelne Teams jedoch häufig ihre eigenen Disziplinierungspraktiken ein. Jetzt wird es ein tägliches Scrum-Meeting des Teams geben, bei dem beschlossen wurde, eine kleine Geldstrafe zu verhängen, wenn es zu spät für DSM ist. Das Team hat DSM um 11.30 Uhr und die Bank hat bereits einen konkreten Betrag angesammelt. Wir werden ein bisschen mehr sammeln und für dieses Geld in die Bar gehen.

    - Wie ist die Kommunikationsstruktur zwischen der IT-Abteilung und der Alfa-Bank insgesamt? Muss ein gewöhnlicher Entwickler viel mit Nicht-IT-Mitarbeitern interagieren und Anweisungen von ihnen erhalten?

    - In der Regel bespricht der Product Owner eines bestimmten Produkts die Pläne im Product Committee der Bank und versteht mit dem Team die technischen Details der Implementierung dieses Plans. Gleichzeitig erhält er nicht nur „zwei TK-Bögen von der Bank“, alles ist viel flexibler. Unsere Produkt-Overs selbst bringen Ideen mit und arbeiten nicht klar nach Richtlinien.

    Tatsächlich wird die Entscheidung nicht nur von einem Produktverkäufer getroffen. In der Regel ist das gesamte Team an der Erstellung des Produkts beteiligt, und manchmal stellt sich die Hauptfrage:



    Wenn das gesamte Team versteht, was und warum getan wird, wird die Erstellung von Qualität einfacher. Das ganze Team ist verantwortlich, daher hat jeder das Wahlrecht.

    - Und wie viel braucht ein Entwickler in Alpha, um sich in eine Bankspezifität wie die Besonderheiten der Kreditgewährung zu vertiefen?

    - Es kommt auf das Team und den Entwickler an. Es gibt Leute, die tief in das Thema vertieft sind, ich kenne sogar diejenigen, die angefangen haben, Rechnungswesen zu beherrschen, nur weil sie interessiert waren. Aber als ich zu Alpha kam, bin ich im ersten Jahr fast nicht in die Details eingedrungen. Ich hatte einige notwendige Unterlagen, um mit Bankdienstleistungen, APIs, zu interagieren und einige Informationen zu erhalten, aber es war nicht notwendig, die Besonderheiten der Bank im Handumdrehen zu verstehen.

    Es ist klar, dass je länger Sie hier arbeiten, desto mehr Sie versuchen, alles sofort auf einen Blick zu erfassen und Prozesse und Architekturen zu erstellen, desto mehr müssen Sie verstehen, wie es von Anfang bis Ende funktioniert. In der Anfangsphase gibt es jedoch keine Möglichkeit, mit dem Kopf in den Whirlpool einzutauchen und die Zahlungen und Buchungen zu verstehen. Der Analyst im Team schließt normalerweise diese Frage.

    - Zu der Frage „Je mehr Sie versuchen, alles auf einmal zu erfassen“: Sie haben bereits gesagt, dass Sie zu einer allgemeineren Rolle „außerhalb der Produktteams“ gewechselt sind - können Sie weitere Details angeben?

    - Ja, selbst wenn Erfahrung gesammelt wird ... Ich werde es nicht einmal Wachstum nennen, sagen wir "Richtungswechsel" des Entwicklers. Meistens taucht ein Entwickler in das Produktteam ein und versteht nach und nach die Besonderheiten, Prinzipien und Prozesse. Wenn er nach den ersten Monaten assimiliert ist und die Situation „alles ist neu“ nicht mehr hat, beginnt er, sich mit anderen Hilfsmitteln zu beschäftigen. Und wenn er soweit wächst, dass er alle Technologien versteht und neue hinzufügen kann, versteht er es, dies mit anderen Entwicklern zu besprechen. Meistens fällt er in diesem Moment auf und hört auf, im Vollzeit-Team zu arbeiten. Er experimentiert eher mit Technologien, erstellt einige Prototypen, hilft Neulingen, sich daran zu gewöhnen, arbeitet mit einem technischen Rückstand und zieht andere an. Sieht aus, wo etwas instabil ist, wo etwas hochgezogen werden muss.

    Darüber hinaus passen solche Rollen nicht in die Standarddefinitionen von „Architekt“ oder „Teamleiter, der ein Teamleiter ist“. Weil eine solche Person verpflichtet ist, Code zu schreiben, ist sie verpflichtet, sich mit der Infrastruktur zu befassen, denn wozu wird sie sonst dort benötigt? Einfach draufsitzen und links und rechts Trinkgeld geben? Wenn es für mindestens ein oder zwei Monate aus den Entwicklungsprozessen herausfällt, wird es aufhören, die Entwickler in den Teams zu verstehen und etwas Neues zu bringen. Und solche Leute sollten etwas in die Teams bringen und andere auf dieses Niveau bringen, wenn eine Person bereits alles versteht und auch neue Dinge bringen kann.



    - Sie haben über die Unabhängigkeit der Teams und die Interaktion innerhalb des Teams gesprochen - aber wie stark ist die Interaktion zwischen den Teams? Und wie oft wechseln die Leute von einem Team zum anderen?

    - Interaktion ist natürlich genug. Wenn das Team nur einen Javisten hat, ist er möglicherweise gelangweilt und möchte möglicherweise über Java-Themen kommunizieren. Unsere Mitarbeiter nehmen aktiv an Besprechungen und Konferenzen teil. Sie befinden sich also auf jeden Fall in der Community, aber wir haben auch eine eigene Community von Java-Entwicklern. Wir veranstalten Abendsitzungen, in denen wir einfach interessante Themen diskutieren: Menschen werfen Themen auf, wir stimmen für sie ab, bauen und diskutieren sie. Entweder innerhalb einer Stunde oder (wenn der Wunsch zu diskutieren nicht aufhörte) bis ins Unendliche, geschieht dies normalerweise am Freitagabend. Jemand probt manchmal einen Bericht vor einer Konferenz. Manchmal diskutieren wir über Bankenthemen, manchmal über allgemeine technologische Themen, und ein Kotlin-Fan kann einwerfen: „Und lasst uns die Coroutinen in Kotlin besprechen“. Und sie ging ...

    Zu einer anderen Mannschaft zu gehen ist normalerweise kein Problem. Teams kommunizieren miteinander und wenn eine Person etwas anderes machen möchte, kann sie zwei Javisten wechseln und eine neue finden ... Und eine Profiländerung ist auch möglich: Wenn Sie etwas völlig Neues für sich selbst lernen möchten, können Sie zu Ihrem Teamkollegen gehen und sagen: „Petya, es wäre interessant für mich, die Entwicklung dort zu versuchen. Kannst du mich unterrichten, kannst du mein Mentor werden? " Er gibt dir ein kleines Rätsel und macht es mit dir. Dies geschieht regelmäßig, und die Leute entwickeln sich: Beispielsweise entwickelt sich ein Entwickler in einem vollen Stapel, Tester gehen in die Entwicklung.

    Wenn Sie überhaupt ein neues Projekt durchführen möchten, können Sie bei einem Hackathon einen Prototyp erstellen oder bei einem der internen Mitaps darüber sprechen.

    - Die Alfa-Bank bietet Produkte wie eine mobile Anwendung an, die für ihre normalen Kunden (einschließlich der Leser von Habr) deutlich sichtbar sind. Können Sie ein Beispiel für ein Projekt nennen, an dem Sie ebenfalls arbeiten oder gearbeitet haben, das aber für normale Personen nicht offensichtlich ist?

    - Kürzlich schrieben sie in den Nachrichten über eine Überweisung durch die Blockchain zwischen Alfa Bank und Sberbank, aber es ist weniger aufgefallen, dass dies nicht unsere erste Erfahrung mit der Blockchain ist: Letztes Jahr waren Alfa Bank und S7 die ersten in Russland gehaltenein Akkreditiv mit seiner Hilfe. Für die bereits erwähnte Ilya Sergeyev war es interessant, mit der Blockchain zu arbeiten, aber kein neues Produkt zu lancieren, nur um es auszuprobieren. Und dann entstand das Bedürfnis der Bank, die Papierauflage zu reduzieren. So trafen sich zwei Einsamkeiten.

    - Die technologischen und rechtlichen Aussichten für die Blockchain sind noch immer nicht vollständig geklärt. War es für das Unternehmen beängstigend, Ressourcen in diese zu investieren?

    - Wir lancieren manchmal Dinge, die auf den ersten Blick Fragen aufwerfen: „Abheben / nicht abheben“. Wenn Sie etwas an einem Produkt ändern, das von Millionen von Menschen verwendet wird, können Sie gleichzeitig viele Bewertungen "ausgezeichnet, endlich" und viele Bewertungen "warum wiederholen" erhalten. Und wenn Sie neue Technologien einführen, wissen Sie erst dann genau, was passieren wird, wenn Sie es am Prototyp testen.

    Stabilität ist uns auf jeden Fall wichtig, wir sind immer noch eine Bank, aber wenn wir nicht experimentieren und etwas Neues auf den Weg bringen, können wir zurückbleiben.

    Kirill Tolkachev


    Wir haben Kirill nicht gefragt, wer später an diesem Tag aufgetaucht ist, aber später haben wir Joker auf unserer Konferenz getroffen und dort ein paar Fragen gestellt:

    "Sie sind bereits" Java-Autorität "in Alpha, von Alpha-Entwicklern können Sie im Kontext von Ihnen hören" und hier bin ich Ich habe Cyril gefragt: "- und besteht ein Großteil der Arbeit aus Diskussionen mit weniger erfahrenen Entwicklern? Schreiben Sie jetzt selbst viel Code?

    - Der vorhandene technische Stapel wurde gebildet, einschließlich von mir, und von selbst. Wenn die Jungs Fragen dazu haben, antworten wir. Oft kommen Menschen mit Fällen, an die wir nicht denken konnten, erzählen uns interessante Geschichten und wir überlegen gemeinsam, wie wir das beheben können. Ein kürzlich angekommener Entwickler kann aktiv sagen, was er nicht mag, fragen, warum wir so machen, sind wir verrückt. Und durch Kommunikation finden wir eine Option, die es uns ermöglicht, ihn von Schmerzen zu befreien. Oder wir verstehen, dass nicht alles so einfach ist, es gibt immer noch eine Reihe anderer Einschränkungen, die diesen Prozess betreffen.

    Über das, was ich selbst mache - oft beginne ich eine Arbeit, aber ich beende sie nicht immer. Mein Problem ist, dass die Zeit in Tagen nur 24 Stunden beträgt, und um es vorteilhaft zu nutzen, müssen Sie nicht immer etwas selbst tun. Wenn ich mich für eine Woche hinsetze, werden viele Aufgaben und wichtige Dinge an mir vorbeigehen.

    - Zu den Worten „Wir entscheiden, wie das behoben werden soll“: Können Sie ein aktuelles Beispiel für eine Dose nennen, die Sie reparieren mussten?

    - Vom letzten, was unangenehm war: Wir haben interne Balancer auf HAProxy, die den Datenverkehr dynamisch an Anwendungen weiterleiten. Es gibt eine Nuance, die darin besteht, dass unsere Anwendung über einen Port für die interne Erkennung verfügt, der automatisch im System ausgewählt und an eine ganze Gruppe von Anwendungen angehängt wird.

    Hier haben wir diesen Port zwischen zwei Gruppen von Anwendungen geschnitten, die für unterschiedliche Funktionen verantwortlich sind. Die Leute begannen herumzustöbern. Zuerst wurde der Support angestachelt, dann die Entwickler, und es war nicht sofort klar, was passierte. Und hier half der Frühling, das Problem zu lösen. Auf dem Endpunkt, der Informationen über den Dienst zurückgibt (welche Festschreibung, aus welchem ​​Repository all dies gesammelt wurde - interne Endpunkte), gab er Folgendes zurück: Sie ziehen einmal, es wird eine Instanz der Anwendung aus einer Gruppe abgerufen, und dort gibt es das zurück Anwendung X (identifiziert durch den Header X-Anwendungs-ID). Wenn Sie denselben Endpunkt ein zweites Mal ziehen, leitet der Balancer die Route zu einer anderen Anwendung weiter. Y Es dauerte einige Zeit, bis herausgefunden wurde, was jemand falsch konfiguriert hatte, und wir haben es möglich gemacht, ihn falsch zu konfigurieren und dieselben Anforderungen an verschiedene Anwendungen weiterzuleiten.

    - Ich habe Maxim bereits eine ähnliche Frage gestellt, aber da Sie und Evgeni Borisov einen so aussagekräftigen Bericht über Spring Boot on Joker haben, dass er nicht in einen Zeitrahmen passte, möchte ich die Messwerte vergleichen: Was halten Sie von der Verwendung neuer Versionen von Spring / Spring Boot in der Produktion? ? Und wie wird die Frage des Übergangs zu neuen Versionen in Alpha gelöst?

    - Die Berichte über Spring Boot besagen nicht, dass sie nicht in einen Steckplatz passen, sie passen nicht mehr in einen Trainingstag, und Zhenya und ich haben zwei Schulungen über Spring Boot durchgeführt, die reibungslos in die Spring Cloud flossen.

    Und über den Übergang - es kommt auf die Situation an. Es gibt Technologien, mit denen wir natürlich die Meilensteinversionen überprüfen. Es gibt Technologien, die wir uns gerade ansehen, zum Beispiel schauen wir uns jetzt gRPC an. Wir versuchen es irgendwie im Frühling zu vermasseln - ich habe einen Starter geschrieben, nachgesehen, einige raue Stellen gefunden und festgestellt, dass ich auf neue Veröffentlichungen warten muss. Ich warte auf neue Veröffentlichungen, bam, und in ihnen die Funktionen, die ich brauche. Zum Beispiel Abstraktionen in Bezug auf Ermittlung, Lastenausgleich usw.

    Oft muss man parallelen Plattformen folgen. Vom schlimmsten - Node.js. Beispiel: Mit demselben gRPC sehen Sie sich die Implementierung des Ausgleichs und der Wiederherstellung von Verbindungen für einen Knoten an. Der Code enthält Kommentare im Sinne von "Zu erledigen: Implementieren" mit dem Hinweis "Vielleicht wird er eines Tages von jemandem benötigt." Nach dem Kodex zu urteilen, glaubten die Leute im Allgemeinen nicht, dass es im Prinzip jeder brauchen würde. Da ich kein Node-Experte bin, habe ich nicht einmal versucht, es zu beenden - etwas in ein System zu implementieren, das mir zu lange unbekannt war, ohne Abstraktion. Und es stellt sich heraus, dass selbst wenn die Technologien uns aus der Sicht des Servers zufrieden stellen, Clients auf verschiedenen Plattformen sie nicht verwenden können, da für einen zuverlässigen Betrieb keine API erforderlich ist. Es gibt nicht immer Menschen, die bereit sind, solche Dinge zu regieren, in öffentliche Entscheidungen zu investieren, fördern Sie Ihre Ideen. Wir freuen uns immer, wenn ein Entwickler auftaucht, der nicht nur intern entwickeln, sondern auch externen Code für uns „schärfen“ kann. Dank dieser Leute können wir manchmal nicht auf die Betreuer einer Lösung warten, sondern entweder einen lokalen Fix herausgeben oder Korrekturen direkt in der offiziellen Version erhalten.

    Aus der Sicht der Spring-Infrastruktur - wir sehen uns die Meilensteine ​​an, wir haben uns sowohl Spring Boot 2.0 als auch Spring 5.0 angesehen, als es noch nicht veröffentlicht wurde.

    - Danke für die Antworten! Und wir werden die Fortsetzung der Post vorbereiten .


    Jetzt auch beliebt: