Der Code, in dem wir leben

Traditionell wird der Softwareentwicklungsprozess mit der Konstruktion verglichen. Der Begriff „Architekt“ stärkt nur die assoziative Verbindung zwischen diesen Prozessen. Aber die modernen Realitäten haben dieses Modell irrelevant gemacht, weil es Mechanismen gibt, die es nicht erklären kann:

• Wenn wir ein physisches Objekt oder Produkt herstellen, warum wird die Software dann nie als vollständig betrachtet?
• Wenn wir über technische Lösungen sprechen, warum können wir dann nie sicher vorausplanen?
• Wenn wir Architekten oder Bauherren sind, warum scheitern dann so viele Projekte?
• Und schließlich, mit so vielen Tipps, Best Practices, Prinzipien, Büchern und Softwareentwicklungsberichten, warum werden so viele Projekte zu einem unerträglichen Arbeitsplatz?

Ich schlage eine Übersetzung von Sarah Mays brillantem Bericht "Livable Code" vor, der sich in der Nähe des Textes befindet, in dem sie alle diese Themen betrachtet.

Warum ist es wichtig, ein Modell zu haben?

Das Modell ermöglicht es uns, eine Analogie zwischen einem ungewohnten oder schwer verständlichen Prozess und etwas Vertrautem, Verständlichem zu ziehen. Darüber hinaus sollte es nicht nur geeignet sein, eine Situation zu beschreiben, in der alles in Ordnung ist, sondern das Modell sollte uns wie jede gute Analogie in Grenzsituationen leiten.

Der Softwareentwicklungsprozess ist eine Kombination aus zwei miteinander verbundenen, interagierenden, aber dennoch getrennten Einheiten: Code und Team.

Bestätigung hierfür ist das Gesetz von Conway. Die Beziehung dieser Entitäten sagt uns, dass Probleme im Code mit Problemen im Team zusammenhängen und umgekehrt. Daher haben wir zwei Möglichkeiten, sie zu lösen: auf der Code-Seite und auf der Team-Seite.

Einige Probleme scheinen nur Probleme mit dem Code zu sein, andere nur mit dem Team. Tatsächlich sind alle Probleme mit beiden Komponenten. Daher sollte das neue Modell für moderne Realitäten geeignet sein und die Beziehung zwischen beiden Komponenten des Entwicklungsprozesses widerspiegeln.

Beschreibung des neuen Modells

Der Bereich, in dem sich die Anwendung befindet

Der Bau des Gebäudes besteht aus drei Phasen: Planung, Bau und Wartung. Bisher sah die Softwareentwicklung ähnlich aus: Das Ergebnis der Entwicklung war ein fertiges Produkt. Es wurde vom Benutzer installiert und zur Unterstützung einer separaten Gruppe übertragen, und die Entwickler begannen, etwas anderes zu tun.

In der Welt der Webanwendungen, Bereitstellungen und Veröffentlichungen mehrmals täglich ist jedoch nichts vollständig. Eine ähnliche Situation ist bei mobilen Anwendungen und Spielen zu beobachten, wenn diese automatisch über Steam auf der Konsole aktualisiert werden (meist im ungünstigsten Moment). Darüber hinaus müssen Anwendungen in einem sich ändernden Geschäftsumfeld flexibel und in der Lage sein, sich zu ändern. Der Entwicklungsaufwand muss enorm sein, um diese Flexibilität zu gewährleisten. Dasselbe ist von Gebäuden nicht zu erwarten.

Die Infrastruktur, die wir bei der Entwicklung von Anwendungen verwenden, ähnelt eher einem Gebäude. Was wir schaffen, sind nicht die Gebäude selbst, da die meisten Anwendungsanwendungen Platz in vorgefertigten Strukturen beanspruchen. Es klingt wie ein Schritt vom Architekten zum Innenarchitekten, aber in einem solchen Modell steckt viel Kraft. Die darin enthaltenen Gebäude bilden die Grundlage für unsere Anwendungen: Die Grundlage ist das Betriebssystem, die Parkebene ist die Programmiersprache, das Gebäude selbst ist das verwendete Framework, und wir entwickeln bereits darin enthaltene Anwendungen.

Der von den Gebäuden bereitgestellte Innenraum (Struktur) ist veränderbar, es ist jedoch schwieriger, ihn zu ändern als Ihren eigenen Code. So sehr der Abriss der Wand schwieriger ist als das Bewegen der Möbel. Das Gebäude selbst (Rahmen) schränkt somit die Möglichkeiten und das Erscheinungsbild Ihres Interieurs (Anwendung) in gewisser Weise ein.

Jedes Gebäude ist für seine eigenen Zwecke optimiert. Eine Bewerbung kann in jeder von ihnen platziert werden, aber einige Räume sind besser dafür geeignet, und einige sind schlechter. Daher wird der Code, den Sie in einem vorgeformten Bereich platzieren, auf eine bestimmte Weise von diesem Bereich generiert.

In unserer Branche wird immer noch viel gebaut, aber die meisten von uns arbeiten immer noch an Innenräumen (Anwendungen).

Neues Ziel in der Entwicklung

Wenn Sie noch hinzufügen, dass Projekte niemals als abgeschlossen betrachtet werden, kommen Sie zu dem Schluss, dass Code nicht das ist, was wir erstellen, sondern wo wir leben . So können Sie das eigentliche Entwicklungsziel aus einem anderen Blickwinkel betrachten. Der Ort, an dem wir leben, muss lebenswert sein : geeignet, komfortabel und komfortabel zum Leben. Und nicht nur für uns selbst, sondern auch für diejenigen, die mit uns leben. Im Falle von Code reicht es nicht aus, das Produkt fertigzustellen und fortzufahren. Es muss auch lebenswert gemacht werden : verständlich, unterstützt, erweiterbar - für das Team, das darin "lebt".

Was ist lebenswerter Code?

Lebenswert in Bezug auf zu Hause bedeutet, dass Sie in einem Raum leben, in dem Sie alltägliche Aktivitäten mit Komfort und Leichtigkeit ausführen können. Im Schlafzimmer befindet sich eine Leselampe, auf dem Couchtisch liegen Servietten, im Wohnzimmer eine Joystick-Box und im Flur ein Fahrradhalter.

Aber was lebenswert für eine Gruppe von Menschen bedeutet, hängt von sich selbst ab. Ein komfortables Zuhause für junge Eltern mit einem Kind ist nicht wie ein Zuhause für Studenten oder ältere Menschen oder für alleinerziehende Eltern mit einem Teenager.

Lebenswert für Code bedeutet dasselbe: Sie können ändern oder hinzufügen, was Sie möchten, aber ohne übermäßige Komplexität und Ärger. Wenn Sie wissen, was wo ist, springen Sie einfach an die richtige Stelle im Code und arbeiten Sie damit. Hier gilt das gleiche Prinzip: Die Tatsache, dass für ein Team lebenswert ist, ist nicht für ein anderes geeignet. Was für einen Senior und vier Junioren bewohnbar ist, unterscheidet sich von der Bewohnbarkeit für fünf Senioren und unterscheidet sich stark von der Bewohnbarkeit für ein ausgelagertes Team.

Die Menschen kommen und gehen, daher ist das Erstellen und Verwalten von Code in einem lebenswerten Zustand ein fortlaufender Prozess. Das Äußere eines neuen Teammitglieds ist mit einem neuen Nachbarn vergleichbar: Er hat ein seltsames Sofa, das er aus irgendeinem Grund wirklich liebt. Sie stimmen daher widerwillig zu, ihn ins Wohnzimmer zu setzen. Und nach ein paar Tagen schlägt ein Nachbar vor, Vorhänge und Jalousien auszutauschen, weil es ergonomischere gibt. Und das Schlimmste ist, dass er Geschirr mit Tabs statt mit Leerzeichen wäscht! Aber jetzt lebst du zusammen, also musst du verhandeln.

Es stellt sich heraus, dass Ihre Stimmung und Kondition mehr von denen abhängt, mit denen Sie zusammenleben, als von bestimmten Dingen in der Wohnung und noch weniger von der Aufteilung. Auch beim Code: Ihr Wohlbefinden hängt hauptsächlich von denen ab, mit denen Sie arbeiten, und noch viel weniger vom Code selbst oder dem Framework.

Wie ein Projekt überladen wird

Aber was ist, wenn Ihr Code wie dieser Raum aussieht? Wie macht man es für das Team geeignet? Wo soll ich anfangen?

Einverstanden, es ist schwierig, sich hier fortzubewegen, ganz zu schweigen davon, wie man die Dinge in Ordnung bringt. Warum erreichen Häuser diesen Zustand? Es wird oft gesagt, dass dies Faulheit ist. Psychologen denken anders: Das Haus gerät aufgrund einer Reihe von scheinbar unbedeutenden Fehlentscheidungen in einen solchen Zustand.

Stellen Sie sich vor, wie alles anfangen könnte. Es gibt einen kleinen Raum, in dem Sie versucht haben, den Raum zu optimieren: mehrere Regale und Schubladen hinzugefügt, ein Fensterbrett verwendet. Für eine Weile war alles in Ordnung: Sie hielten täglich Ordnung. Aber der Abend kam nach einem anstrengenden Tag, an dem Sie nicht rauskamen. Am Morgen haben Sie verschlafen, und als Sie nach Hause zurückgekehrt sind, haben Sie direkt an Ihrem Schreibtisch zu Abend gegessen und vergessen, den Teller abzunehmen. Eltern brachten Ihre alten Sachen über das Wochenende. Es war keine Zeit, sie zu zerlegen, und Sie stellten die Kisten so auf, wie sie sind. Und Sie haben das Gefühl, dass der Raum nicht mehr in Ordnung ist, aber sein Zustand ist so bedrückend, dass Sie nicht verstehen können, wo Sie anfangen sollen, die Situation zu korrigieren, und bald wird daraus eine IT. Eine Reihe kleiner Fehlentscheidungen: Der Raum ist schon ein schreckliches Durcheinander, warum nicht Bücher auf den Boden werfen?

Das gleiche passiert mit Code. Sie öffnen eine Datei, die bereits fehlerhaft ist, ein halbes Dutzend Muster, die nicht mehr funktionieren. Und der Manager steht hinter Ihnen und wartet darauf, dass der Fehler behoben wird. Das erste, was mir in den Sinn kommt, ist, den Fehler so schnell wie möglich mit Klebeband zu beheben und hier rauszukommen.

Diese scheinbar kleinen, lokalen Lösungen sind genau das, was den Code unbelebbar macht . Es gibt jedoch Möglichkeiten, aus diesem Loch herauszukommen, das wir für uns selbst graben.

Rettung durch Gewohnheitsänderung

Ist Ihnen aufgefallen, dass es in den meisten überfüllten und gepflegten Häusern oft viele Zeitschriften gibt, Zeitungsausschnitte mit einem schönen und gemütlichen Interieur? Es gibt auch Fotos, Projekte, Tipps zur kompetenten Wohnraumgestaltung.

Menschen, die in überfüllten Häusern leben, wollen anders leben, sie schauen sich all diese Magazine an und wollen verdammt noch mal dasselbe Interieur, aber sie wissen nicht, wie sie das erreichen sollen. Und sie denken, dass nur eine Kardinalentscheidung es ihnen ermöglicht, ihr Haus so wie auf dem Bild zu gestalten.

Es gibt eine Hoarders-Show im amerikanischen Fernsehen. Menschen, die in einem ewigen Chaos leben, erklären sich damit einverstanden, daran teilzunehmen, damit ein Team von Fachleuten aufräumt und ein Designer-Interieur in ihrem Haus schafft. Nun, und wie immer, am Ende des Programms, schöne Fotos VOR und NACH. Interessanterweise geben die meisten Teilnehmer zu, dass ihr Zuhause am Ende in seinen ursprünglichen Zustand zurückgekehrt ist. Es ist ganz einfach: Die gleiche Abfolge kleiner falscher Entscheidungen führte sie zum vorherigen Ergebnis.

Es stellt sich heraus, dass eine effektivere Methode darin besteht, schrittweise länger zu arbeiten, nicht mit dem Inhalt des Hauses, sondern mit den Menschen selbst. Ziel ist es, ihre Gewohnheiten so zu ändern, dass die Aufrechterhaltung der Ordnung Teil ihres täglichen Lebens ist. Leider finden Produzenten diese Option für eine Reality-Show zu langweilig.

Der überfüllte Code verhält sich genauso: Wir bekämpfen ihn jeden Tag, nur um das aktuelle Problem zu lösen, und träumen davon, alles neu zu schreiben. Wenn wir jetzt nur alles wiederholen könnten, würden wir definitiv nicht dieselben Fehler machen! Wir müssen jQuery auf Ember umschreiben! Wir müssen den Monolithen in Mikrodienstleistungen schneiden!

Manchmal funktioniert es, zumindest lange genug, um einen triumphalen Blog-Beitrag zu schreiben. Aber dann geht das Licht aus, die Kameras funktionieren nicht mehr, das Filmteam verlässt die Website, und wenn Sie Ihre Gewohnheiten nicht geändert haben, sind Sie wieder in einem Chaos und sogar schneller als Sie denken.

Die Leute denken, dass große Fehler uns töten: Das Haus ist zu klein, das Layout ist nicht erfolgreich, der falsche Rahmen, der Monolith, nicht genug Ressourcen. Es ist nicht so. Wir werden durch sehr kleine Entscheidungen getötet, die durch Gewohnheiten und Denkweisen verursacht werden.
Sie können alles umschreiben, was Sie wollen. Aber wenn Ihr Team seine Gewohnheiten nicht ändert, befinden Sie sich in einem komplexen Netzwerk von Microservices, genau wie Sie ein komplexes Netzwerk von Klassen und Modulen in einem Monolithen hatten.

Teamgewohnheiten

Es ist zu beachten, dass es sich nicht um Einzelpersonen handelt, sondern um Teamgewohnheiten und -normen. Dies erklärt, warum das Bild des Entwicklers als einzelner Fachmann, Handwerker, die Realität nicht widerspiegelt. Dies ist kein separater Entwickler faul und unprofessionell. Dies ist ein Team mit einer lahmen Teamwork-Kultur.

Genau wie bei Mitbewohnern: Jeder sollte täglich putzen, Geschirr nachspülen, Bad und WC regelmäßig reinigen, das gemeinsame Wohnzimmer aufräumen. Es gibt jedoch komplexere Aktivitäten zur Steigerung der Lebensfähigkeit , die "nur Interessierten" überlassen werden können. Wiegen Sie beispielsweise Küchenschränke oder wählen Sie einen geeigneten Tisch im Wohnzimmer, anstatt zu sperrig zu sein.

Aber die tägliche Arbeit ist das, was jeder tun muss. Das heißt, Sie können Mitarbeiter im Team haben, die an der globalen Umgestaltung von Architekturen interessiert sind, zu große Module aufteilen und die Interaktionen zwischen ihnen und denjenigen, die dies nicht möchten, optimieren. Jeder ist nicht verpflichtet, sich an der Umlagerung von Möbeln zu beteiligen, sondern muss das Geschirr spülen.

Zwei Extreme sind nicht zu vertreten, oder warum Bücher nicht funktionieren

Wunderschönes Interieur, nicht wahr? Alles ist perfekt aufeinander abgestimmt und durchdacht, sonst nichts. Mit einem Wort - ein Traum. Genau wie eine Beschreibung von Mustern, die eine schöne Version eines perfekt konsistenten, perfekt abstrakten Codes zeigt. So schön, dass sich das Auge freut.
Ja, die Wohnung auf dem Bild ist wunderschön, aber du kannst nicht darin leben. Wohnungen aus den Seiten von Zeitschriften werden absichtlich der Unordnung beraubt, weil Unordnung etwas Individuelles ist.

Woraus dieses Durcheinander besteht, sind verschiedene Dinge für jeden. Wenn Sie gerne lesen, dann sind dies Bücher, wenn Sie Computerspiele mögen, dies ist eine Konsole und Joysticks, und wenn Sie Outdoor-Aktivitäten mögen, ist es ein Fahrrad oder ein Kajak. Die Dinge, die Sie benutzen, sollten zur Hand sein, also müssen Sie sich mit einem gewissen Durcheinander abfinden. Hauptsache, es sollte nicht zu viel davon geben.

Magazine über schöne Innenräume in der Welt der Softwareentwicklung zeigen unrealistisch sauberen Code und setzen daher die falschen Richtlinien. Dies sind Bücher über Softwareentwicklung, Designmuster, Tipps aus Blogs und Artikeln. Code, der alle Anforderungen erfüllt, perfekt konsistent und abstrakt ist - ist in der realen Welt nicht realisierbar. Auch wenn Sie es schaffen, können Sie nicht darin leben.

Wir brauchen ein bisschen Chaos, um uns wohl zu fühlen. Dies gilt sowohl für die Wohnung als auch für den Code.

Beide Extreme sind unbelebbar . Wenn Sie einen Code haben, den Sie nicht verstehen und nicht wissen, wie Sie damit arbeiten sollen, liegt er an einem dieser Extreme. Entweder ist es zu verschmutzt, dass es unmöglich ist, geeignete Ideen von unangemessenen zu unterscheiden, oder es ist so rein, dass es einfach unmöglich ist, geeignete Ideen zu finden.

Darüber hinaus können diese beiden Extreme gleichzeitig im selben Projekt existieren. Manchmal sogar in der Nachbarschaft. Lebenswerter Code liegt irgendwo dazwischen. Es ist nicht nur ein komfortabler Wohnraum, sondern befindet sich auch zwischen Fotos auf den Titelseiten von Zeitschriften und überfüllten Wohnungen.

Daher müssen Sie in der Lage sein, ein wenig Unordnung zu ertragen, da dies den Raum bewohnbar macht .

Manifest

Sie können sagen: „Das ist natürlich alles sehr interessant, aber was ist, wenn mein Code bereits völlig durcheinander ist? Oder was ist, wenn das Projekt nicht so schlecht ist, ich aber sichergehen möchte, dass es sich nicht in die falsche Richtung bewegt? “

Angenommen, Ihr Code sieht aus wie ein überfülltes Wohnzimmer mit engen Verständnispfaden. Keine Sorge, du bist kein schlechter Mensch - das kann jedem passieren.

Wenn Sie das Problem aus technischer Sicht betrachten, schreit es einfach: „Rewrite! Wie ist es möglich, etwas an einem solchen Ort ohne freien Platz zu organisieren? Nehmen Sie einfach alles hier raus und fangen Sie von vorne an! “Diese Top-Down-Planung eignet sich gut für bestimmte Engineering-Aufgaben, aber nicht für die meisten Programme. Dies liegt nicht daran, dass wir schlechte Ingenieure sind oder es nur schlecht versuchen, sondern daran, dass der technische Ansatz in unserem Bereich nicht funktioniert. Und der Code funktioniert als Raum, in dem Menschen leben. Sie müssen verstehen, dass Menschen genau das sind, woran Sie arbeiten müssen.

Hier ist, wie es geht. Es gibt vier Regeln, die für jede Sprache und jeden Rahmen gelten.

Tu nichts

Fast wie in der Medizin. Versprechen Sie beim Öffnen einer bereits überfüllten Datei, dass Sie sie nicht verschlimmern werden. Auch wenn Sie keine Zeit haben, um die Dinge zu reparieren, die bereits schrecklich sind. Wenn Sie bei einer Codeüberprüfung feststellen, dass eine Person gegen diese Regel verstößt, erinnern Sie sie einfach daran, worauf Sie sich geeinigt haben.

Glauben Sie an konsequente Verbesserungen

Ein Stapel von fünf Büchern auf dem Boden und eines, das in einem Bücherregal aufgeräumt ist, ist besser als ein Stapel von sechs Büchern. Vielleicht verschiebt derjenige, der diesen Code das nächste Mal berührt, ein anderes Buch vom Haufen ins Regal. Wenn Sie auf die Zeit warten, um sie alle auf einmal zu platzieren, wird dies niemals passieren.
Die Verwendung dieses Ansatzes kann ein Problem sein. Aufeinanderfolgende Verbesserungen sind für viele schwierig, sodass sie weiterhin mit dem brennenden Wunsch leben, ein Modul, ein Subsystem oder eine Anwendung vollständig neu zu schreiben. Infolgedessen nimmt der Stapel der Bücher nicht ab und bleibt von Iteration zu Iteration auf dem Boden.

Machen Sie das Housekeeping zum Bestandteil des Workflows

Starten Sie keine User Stories für das Refactoring. Warten Sie nicht zwei Wochen, um eine Datei zu reparieren. Erfahren Sie, wie Sie einfache Regeln in Ihre tägliche Arbeit integrieren. Die Scout-Regel lautet: Verlasse das Camp sauberer als vor deiner Ankunft. Wenn Sie es ständig befolgen, werden Sie nach und nach "schlechte Angewohnheiten" los.

Bleiben Sie in Kontakt

Seien Sie darauf vorbereitet, immer mit jedem Mitglied des Teams darüber zu kommunizieren, was Sie tun. Der vorherige Absatz bedeutet nicht, dass Sie verbergen müssen, was Sie tun. Sie müssen nur in Betracht ziehen, die Dinge umzugestalten und in Ordnung zu bringen, als Teil von allem, was Sie tun.
Wenn Sie umgestalten:

1. Bitte nicht um Erlaubnis. Dies ist Teil Ihres Jobs. Aber seien Sie offen für Diskussionen über Ihre Entscheidungen.
2. Scheuen Sie nicht die Verantwortung für Ihre Fehler und lernen Sie von jedem. Auch Fehler gehören zum Job. Durch sie verstehen wir, woran wir arbeiten. Du wirst sie tun, demütige dich. Manchmal können Sie das Refactoring nicht abschließen, manchmal können Sie im Gegenteil zu hinreißend werden, aber das Wichtigste ist, immer wieder aus Ihren Fehlern zu lernen.
3. Fragen Sie nach Tipps, aber befolgen Sie diese nicht immer. Ihre Aufgabe als Entwickler ist es, zu bestimmen, was Sie umgestalten müssen und was nicht. Sie müssen die Freiheit haben, diese Entscheidungen zu treffen und Fehler zu machen.
4. Mach alles zusammen, weil du hier lebst. Es ist sehr wichtig. , , , .

Fazit

— . — . , , , , .

. — . , , , , .

Referenzen

2. , ,