☝🏽 🚊 ⏏️ Entwicklungsregeln bei Yandex.Health 👊 🤞🏽 🍏

Vielen scheint es, dass Yandex ein großes monolithisches Unternehmen mit streng regulierten Prozessen ist, aber das ist nicht so. Wir suchen ständig nach neuen Richtungen, starten neue Projekte und probieren neue Märkte aus. Der Service für Online-Konsultationen mit dem Yandex.Health-Arzt ist eines der klassischen internen Startups.

Ich leitete die Entwicklung von Health zu einer Zeit, als der Dienst noch eine Seite mit einem kurzen Überblick über das interne Wiki war. In diesem Beitrag möchte ich die Entwicklungsansätze vorstellen, die wir in zweieinhalb Jahren Arbeit am Service entwickelt haben.

Haftungsausschluss:
Ein Startup hat seine eigenen Eigenschaften. Unsere Hauptaufgabe ist es, die maximale Anzahl von Experimenten pro Zeiteinheit durchzuführen und Produktmerkmale mit der höchstmöglichen Geschwindigkeit auszugeben. Gleichzeitig müssen wir die Qualität des Produkts so hoch halten, dass es keine Schande ist. [Ein Ort für eine Flamme über das mangelnde Gewissen einiger] . Ich stelle fest, dass eine hohe Geschwindigkeit der Bereitstellung von Funktionen unter anderem die Aufrechterhaltung eines Codes von relativ hoher Qualität impliziert. Andernfalls erstickt das Produkt früher oder später an Fehlern.

Alle folgenden Punkte sind irgendwie gelitten, fast jeder hat einen Fall aus dem wirklichen Leben.

Codequalität und Architektur

Wir minimieren die Zeit, um Funktionen in die Produktion zu bringen und gleichzeitig eine akzeptable Qualität beizubehalten.
Jede Aufgabe beinhaltet zwei Lösungen: schnell und korrekt. Für jede Funktion denken wir über beide Optionen nach, damit es möglich ist, die schnelle Lösung auf die richtige zu aktualisieren, wodurch die unnötige Arbeit des „Auswerfens“ auf ein Minimum reduziert wird. Nachdem wir eine schnelle Lösung eingeführt haben, suchen wir eine Weile und verstehen, ob die richtige benötigt wird.
Kritisch. Oft beträgt der Zeitunterschied zwischen dem „Lösen des ersten Weges, den Sie durch das Scoring einer Krücke erreichen“ und dem „Lösen schön und genau“ zehn Minuten. Deshalb denken wir immer vor dem Schreiben nach.
Wenn Sie zwischen geringfügiger Optimierung und Lesbarkeit / Architektur wählen können, wählen Sie die zweite. Zwei Millisekunden lösen nichts, und mit diesem Code müssen wir noch leben und warten.
Wir denken an die Zukunft. Die nahe Zukunft ist wichtiger als ferne Perspektiven. Wenn die Entscheidung schwierig (lesen Sie „lang“) und flexibel oder einfach, aber genagelt sein kann, lohnt es sich, sie zu nageln und bei Bedarf umzugestalten. Es ist jetzt besser, einen Tag mit einer einfachen Lösung und einen Monat mit einem möglichen Refactoring in einem Jahr zu verbringen, als jetzt zwei Wochen (ja, das nennt man technische Schulden). Es ist wichtig, dass solche Entscheidungen es wert sind, mit dem Team besprochen zu werden. Alleine können Sie die Wahrscheinlichkeit einer Erweiterung dieser Funktion in naher Zukunft falsch einschätzen.

Neue Technologie

Neue Technologien sind cool, lasst sie uns nutzen. Unser Produkt ist jedoch kein Testgelände. Wenn Sie einen neuen Algorithmus oder eine neue Technologie anwenden möchten, können Sie dies unter den folgenden Bedingungen tun:

Die Technologie bringt einen spürbaren Gewinn mit sich (Optimierung, Qualität der Architektur, Code, Skalierbarkeit und all dies sollte wirklich benötigt und nicht weit hergeholt werden).
Die Technologie passt normal in den aktuellen Stapel (Sie müssen keinen Teil der Dienste in Go schreiben, wenn der gesamte Code in Python geschrieben ist).
Die Technologie beeinträchtigt nicht die Qualität der Architektur und die Lesbarkeit des Codes (dies ist subjektiv, daher wird es mit dem Team besprochen).
Die Implementierung und Unterstützung einer neuen Technologie (einschließlich der Suche nach neuen Entwicklern) dauert nicht länger als die Arbeit im Rahmen der aktuellen Technologie. Auch hier hängt alles vom erwarteten Gewinn ab und wird mit dem Team besprochen.
Jede neue Technologie wird mit dem Team besprochen: Wenn es cool ist, ist es für jeden richtig, es zu verwenden, wenn nicht wirklich, dann können Sie dies in einer Gruppendiskussion schnell verstehen.
Sie müssen die Algorithmen, die bereits in vorgefertigten Bibliotheken implementiert sind, nicht unabhängig implementieren (außer in dem Fall, dass es sich um ein kleines Teil eines riesigen Frameworks handelt und es keinen Sinn macht, alles für eine Lösung zu ziehen).
Wenn Sie etwas Cooles und Bequemes getan haben, teilen Sie die Lösung mit dem Team (oder besser mit Yandex).

Kommunikation

Wir diskutieren die Lösung gemeinsam. Je komplexer und kritischer die Funktionalität ist, desto wichtiger ist eine solche Diskussion. Wenn jemand die Lösung nicht mag, überzeugen wir uns gegenseitig, bis eine Einigung erzielt wird. Oder die Diskussionszeit wird eine angemessene Zeit nicht überschreiten.
Wenn es nicht möglich war zuzustimmen, ist das letzte Wort bis zum Kopf. Wir haben eine vernünftige Demokratie, nicht den polnischen Sejm des 17. Jahrhunderts . Gleichzeitig erhält der Führer ein großes Minus an Karma und muss moralisches Leiden erfahren. Und schon gar nicht oft, um dieses Recht zu nutzen.
Sobald wir uns entschieden haben, machen wir es wie vereinbart. Auch wenn ich nicht einverstanden bin. Keine "Ich weiß besser als alle diese Produktexperten, wie man einen Service erbringt, also werde ich tun, was ich für notwendig halte."
"Nicht im Produkt - nicht fertig." Jeder folgt seinen eigenen Aufgaben. Wenn die Funktion zum Testen bereit ist, müssen Sie sicherstellen, dass sie zum Testen bereitgestellt wird. Wenn sie zur Veröffentlichung bereit ist, müssen Sie sicherstellen, dass sie so schnell wie möglich in das Produkt aufgenommen wird. Die Personen, die für die Entstehung der Veröffentlichung verantwortlich sind, erinnern sich nicht immer an alle Funktionen. Fühlen Sie sich frei, an sie zu erinnern. [Ein Ort für eine Flamme über die Verteilung der Verantwortung zwischen den Rollen in einem Team.]
Es ist notwendig, den Kopf einzuschließen. Wenn die Aufgabe seltsam, unverständlich oder zu lang erscheint, sollte dies dem verantwortlichen Manager klar und laut mitgeteilt werden. Und tun Sie dies, bis Sie ein klares Verständnis dafür haben, warum alles so sein sollte. Es kommt vor, dass die richtigen Fragen zur richtigen Zeit Wochen der Entwicklung sparen.

Zeitmanagement

Wenn die Aufgabe nicht innerhalb einer angemessenen Zeit passt, müssen wir laut darüber sprechen. Sie sollten nicht mehrere Monate lang sitzen und die Aufgabe mit einer Einschätzung von drei Tagen abbrechen. Wenn es stark schleppt, läuft etwas schief. Vielleicht liegt ein Missverständnis in der Produktion vor oder wir haben den Arbeitsaufwand unterschätzt. In jedem Fall sollten solche Aufgaben erneut besprochen werden (und infolgedessen manchmal verschoben oder sogar begraben werden).
Die auftretenden Probleme sollten unabhängig voneinander gelöst werden. Wenn jedoch klar ist, dass sich der Prozess verzögert, sprechen Sie unbedingt darüber und bitten Sie die Kollegen um Hilfe. Es ist sehr schlimm, mehrere Tage im Zustand „Ich muss alles selbst tun und meine Kameraden nicht ablenken“ zu bleiben.
Niemand schaut, wann jeder von uns kommt und geht, bis wir Erfolg haben, und unser Regime beginnt nicht, die Arbeit des Teams zu stören. Aber nur nachts zu sitzen, weil Sie keine Zeit haben, etwas zu tun, ist nicht notwendig. Wenn dies zur Gewohnheit wird, liegt das Problem tiefer - bei der Planung, Neubewertung der eigenen Fähigkeiten usw. Während der Entwickler nachts Überstunden macht (und daher alles pünktlich ist), sind die Chancen, dass jemand dieses Problem sieht und löst, stark verringert.
Es kommt vor, dass wir eine wichtige Funktion zum vereinbarten Termin (oder so bald wie möglich) starten müssen. In diesem Fall machen wir Überstunden. Darüber hinaus erhält der Führer ein großes Minus im Karma und muss moralisches Leiden erfahren. Und diese Gelegenheit sicherlich nicht oft zu nutzen. Solche Überstunden werden ausgeglichen. [Ein Ort für eine Flamme über Überstunden und Entschädigung] .

Todsünden

Dies ist ein separater Abschnitt. Hier habe ich versucht aufzulisten, was ich für falsch und schädlich halte, wenn ich in einem Team arbeite. Jeder Artikel hat sein eigenes Gewicht. Einige sprechen von sehr großen Problemen, andere sind nicht so kritisch. Also, was sollte auf jeden Fall vermieden werden:

Arbeit ohne Kopf: "Mir wurde gesagt, ich soll es tun - ich habe es getan." Jedes Teammitglied muss die Essenz der von ihm erstellten Funktion und ihre Auswirkungen auf das Produkt verstehen.
Werfen Sie Merkmale, die nicht mit den Worten "Ich habe alles getan" in den Stoß entleert wurden. Was wir tun, sollte in der Produktion funktionieren. Die Funktion befindet sich zwar nicht im Produkt, ist jedoch noch nicht bereit.
Stimmen Sie zu, es auf eine Weise zu tun, und tun Sie es dann ruhig auf Ihre eigene Weise. Oben ging es bereits um "Ich weiß besser als jeder andere, was besser ist." Aber noch einmal daran zu erinnern, dass dies schlecht ist, wird nicht schaden.
Verschärfen Sie wichtige Funktionen und vertiefen Sie sich in die Diskussion seltener und unrealistischer, aber möglicherweise möglicher Probleme. Wenn Sie in angemessener Zeit nicht herausfinden können, wie Sie ein kleines und selten reproduzierbares Problem umgehen können, sind wir uns einfach einig, wie wir damit leben sollen.
Sprechen Sie die Probleme nicht rechtzeitig aus und versuchen Sie, alles selbst zu lösen (normalerweise nachts). Ein solcher Heldentum führt nur zu einem Versagen der Begriffe, Müdigkeit und einem Gefühl der Unterschätzung: „Ich mache hier Kunststücke, aber ich werde auch für die langsame Arbeit kritisiert!“
Es ist schmerzhaft, auf Kritik am Code zu reagieren und die Beziehung zu klären. Selbst wenn ein Kollege sagt, dass der Code so lala koprolit ist ("Schreiben wir alles neu!"), Behandeln Sie dies mit Verständnis und diskutieren Sie, warum er so denkt. Für Sie persönlich ist dies nicht weniger nützlich als für den gesamten Service.
Geh zu der Person. Wenn wir einen Code oder eine Lösung kritisieren, kritisieren wir nur den Code oder die Lösung, aber auf keinen Fall die Person, die ihn geschrieben oder vorgeschlagen hat. Haben Sie angesichts des vorherigen Absatzes keine Angst vor Kritik. Besser eine vernünftige Zeit, um mit Kollegen zu streiten, als eine erfolglose Entscheidung an prod zu senden.

Insgesamt

Hier können Sie mehr über eine Million Dinge schreiben. Aber je kürzer der Beitrag, desto einfacher ist es, ihn bis zum Ende zu lesen, und ich hoffe es wirklich. Und ja, ich nehme Kritik nicht schmerzhaft auf (unter der Bedingung, dass Sie nicht persönlich werden;). Also lasst uns diskutieren!