Welche Fähigkeiten können in einem Projekt mit einer großen Codebasis gepumpt werden?

Wie man in Projekten mit Geschichte lebt und sich entwickelt. Was gibt dem Entwickler die Erfahrung, mit einer großen Codebasis zu arbeiten, und warum muss man sich nicht bemühen, alles von Grund auf neu zu schreiben, selbst wenn man es wirklich möchte.

Inhalt

1. Für wen ist dieser Text?
2. Was Sie aus einem Story-Projekt lernen können
3. Welche Fragen in einem Interview zu stellen
4. Tipps für diejenigen, die gerade mit einem Legacy-Projekt begonnen haben
5. Kurz

Ich bin Pavel Novikov und an der Entwicklung der mobilen Anwendungen "MyOffice Documents" und "MyOffice Mail" beteiligt. Dies ist eine Anwendung für die Zusammenarbeit mit Dokumenten und einem E-Mail-Client, die seit 2013 erstellt wird. Sie können daher als Projekte mit einer großen Codebasis bezeichnet werden, in denen es einen Ort gibt, der auch Legacy enthält.



Die hier beschriebene Erfahrung gilt nicht nur für die Arbeit an mobilen Anwendungen und skaliert für die Anwendungsentwicklung im Allgemeinen.

Haftungsausschluss für die Kleinen

In diesem Artikel habe ich Reflexionen über meine Arbeit gesammelt, basierend auf den Erfahrungen, die ich bisher gemacht habe. Artikel dieser Art sind immer sehr subjektiv. Ich bin sicher, es gibt Menschen mit Erfahrungen, die meinen Beobachtungen widersprechen. Ich würde diese Diskrepanzen gerne in den Kommentaren diskutieren.

Für wen ist dieser Text?

Der Text richtet sich sowohl an Personen, die sich als Junior betrachten, als auch an Personen, die in die Kategorie Mittel / Senior fallen.



Es gibt viel zu lernen, wenn man mit langlebigen Projekten auf jeder Entwicklungsstufe arbeitet. Lesen Sie die Beiträge von Vastrika: Login und K - Team, um die Ebenen auf der gleichen Wellenlänge zu verstehen . Ich mag seine Kategorisierung der Entwicklerebenen und werde mich in Zukunft daran halten.



Im nächsten Block werden wir kurz analysieren, was für die einzelnen Ebenen bei langen Projekten verwendet wird.

Junior

Die Aufgabe der Junior-Entwickler ist es, die Entwicklung technischer Fähigkeiten zu maximieren. Alles wird verwendet: Sprachen, Frameworks, Bibliotheken, Entwicklungsansätze usw. In jedem Projekt mit einem starken Team können Sie lernen, verschiedene Probleme zu lösen.



Bei ausgereiften Projekten haben Sie zum einen die Möglichkeit, tiefer in jedes Gebiet einzutauchen, und zum anderen können Sie Beispiele für erfolgreiche und erfolglose Entscheidungen studieren. Aus den Fehlern anderer zu lernen ist teuer. Vor allem, wenn erfahrene Kollegen in der Nähe sind, die Ihnen die Bedeutung dieser Fehler und deren Vermeidung ausführlich erläutern können.

Mitte

Die Aufgabe des mittleren Entwicklers besteht darin, seine Autonomie zu erhöhen. Sie sollten ein Teammitglied werden, dem fast jede Aufgabe im Projekt anvertraut werden kann. Dies bedeutet, dass je vielfältiger die Aufgaben eines Projekts sind, desto mehr potenzielle Wachstumsbereiche haben Sie.

Senior

Die Aufgabe des Senior-Entwicklers besteht darin, vollständig zu verstehen, dass Sie nicht für den Code bezahlt werden, sondern für die Lösung von Problemen. Manchmal (bisher noch häufiger) durch Schreiben von Code, manchmal durch Verwalten anderer Entwickler, manchmal durch Kommunikation mit Nicht-Entwicklern. Ausgereifte Projekte sind nur ein Lagerhaus von Aufgaben, die gelöst werden können und sollten.



Als nächstes werde ich näher auf einige Dinge eingehen, die Sie aus bestehenden Projekten lernen können.

Und hier Vermächtnis?

Zuerst müssen Sie die Terminologie verstehen. Das Konzept des "Legacy" hat vor langer Zeit eine negative Konnotation erhalten, aber wofür genau ist der Legacy-Code schlecht?



Michael Feathers, Gründer von R7K Research & Conveyance, argumentiert, dass Legacy-Code Code ist, der nicht durch Tests abgedeckt wird. Der Vorteil dieses Ansatzes besteht darin, dass er auf den ersten Blick objektiv ist. In Wirklichkeit kann es jedoch zwei Szenarien geben:

• Es gibt Tests, aber sie sind schlecht geschrieben: verwirrend, zerbrechlich, nicht offensichtlich strukturiert.
• Keine Benchmarks, aber der Code ist sehr gut gestaltet. Dies macht es möglich, es relativ sicher zu ändern, und in diesem Fall können Sie in Zukunft schnell Tests dafür schreiben.

Ein weiterer Blick auf das Vermächtnis des Entwicklers Dro Helper (Dror Helper): Nicht mehr entwickelt - kontinuierlich gepatcht und gehackt ("Legacy-Code - Code - Code, der ständig gebrochen und mit Krücken gestützt wird, anstatt ihn zu entwickeln") ...



Der Webentwickler Nicolas Carlo ist der Ansicht, dass es unangenehm ist, mit Legacy-Code zu arbeiten.



Aus all dem können wir schließen, dass das Erbe eher ein subjektives Merkmal des Codes ist. Der Code selbst kann funktionieren oder nicht, aber er wird zum Legacy, wenn ein Entwickler erscheint, der ihn nicht effektiv ändern kann.



Ein weiteres relativ objektives Merkmal für die Bewertung von Legacy ist die Antwort auf die Frage "Gibt es nicht unterstützte Abhängigkeiten im Projekt?". Der Code kann nur von bestimmten veralteten Compilerversionen erstellt werden. Oder die Autoren selbst haben eine externe Bibliothek gepatcht, die nun Teil des Hauptprojekts ist. In diesem Fall wird das Projekt tatsächlich spezifisch, und es sind zusätzliche Anstrengungen erforderlich, um es zu unterstützen.



Wenn das Projekt älter als sechs Monate ist, enthält es im Allgemeinen höchstwahrscheinlich Legacy.

Was können Sie aus einem Story-Projekt lernen?

Sie haben also eine Entscheidung getroffen und einen Job in einem Unternehmen bekommen, in dem bereits Code geschrieben wurde und viele andere Dinge passiert sind. Ich werde hinzufügen, dass Sie nicht an einen neuen Ort gehen müssen, um Ihre Profile zu aktualisieren. Legacy ist höchstwahrscheinlich in jedem Projekt vorhanden. Sie müssen nur wissen, wie es bewertet wird. Und was ich spreche, kann sicherlich auf die Dinge angewendet werden, an denen Sie gerade arbeiten.



In welchen Bereichen wird das Pumpen für Sie und das Projekt gleichermaßen nützlich sein? Hier müssen Sie verstehen, dass die Situation, in der Sie sich entwickeln, wo das Projekt schmerzt, ein ideales Umfeld für gegenseitiges Wachstum ist. Denn wenn Sie sich in der Arbeit an einigen linken Dingen entwickeln, kann dies für Sie persönlich ein Plus sein, aber es wird schwierig sein zu erklären, warum das Unternehmen Ihnen dabei helfen sollte.

Analysieren Sie das Projekt

Das erste, was Sie aus einem Heritage-Projekt lernen können, ist, es zu analysieren. Angenommen, Sie sind zu einem Projekt gekommen, bei dem es Lücken in der Dokumentation gibt oder überhaupt keine. In diesem Fall verfügen Sie nur über den Quellcode des Projekts. Daher ist es wichtig, dass Sie es analysieren und seine Struktur und sein Wesen schnell verstehen können. Dies ist wichtig, denn je früher Sie lernen, sich darin zurechtzufinden, desto eher profitieren Sie vom Projekt.



Das Wichtigste, was ich für ein tieferes Verständnis der Projektanalyse empfehlen kann, ist das Buch Effektives Arbeiten mit Legacy-Code von Michael Feathers. Sie ist alt und berühmt. Es beschreibt eine Vielzahl von Methoden zum Arbeiten mit Legacy-Code.



Ein weiterer Tipp ist der Besuch der Understand Legacy Code- Website.... Dies ist ein Blog, der sich einem Thema widmet - der Arbeit mit Legacy. Es ist wichtig, dass Sie den Newsletter dort abonnieren können. Ich bin sicher, dass viele Android-Entwickler über Mailings von Android Weekly und Kotlin Weekly Bescheid wissen. Der ULC-Newsletter ist ebenfalls sehr hilfreich. Es ist nicht aufdringlich, mit Anleitungen zu Refactoring und Codierung.

Refactor

Legacy-Projekte sind ein großartiger Ort, um Ihre Refactoring-Fähigkeiten zu üben. Sie kommen zu einem Projekt, das höchstwahrscheinlich Probleme hat, und Sie müssen es nicht nur ändern, sondern auch verbessern, erweitern und neue Funktionen sehen. Wie gut und effizient Sie (schnell und mit wenigen Regressionen) umgestalten können, hängt davon ab, wie nützlich und gut Sie als Entwickler sind.



In einem ausgereiften Projekt mit einer gesunden Ingenieurkultur sollte das Refactoring ein fortlaufender Bestandteil der Entwicklung sein.



Das Produkt, an dem Sie arbeiten, sollte Ihnen gefallen. Perfekt, wenn Sie es selbst verwenden können. In diesem Fall haben Sie die interne Motivation, lange an der Verbesserung der Qualität zu arbeiten.

Architektur entwerfen und gestalten

Dieser Punkt folgt dem vorherigen - Sie müssen zwangsläufig Software-Design und -Architektur einbauen. Mit der richtigen Entwicklungskultur müssen Sie keine wichtigen architektonischen Entscheidungen innerhalb enger Fristen treffen. Sie haben Zeit, die Architektur zu entwerfen, und es liegt in Ihrer Verantwortung, sie gut zu machen. Was empfehle ich hier immer? Bücher lesen.



Ich finde Bücher genauso wichtig wie andere Informationsquellen. Je mehr Erfahrung Sie mit Büchern sammeln, desto schneller verstehen Sie, wie Sie häufig auftretende Probleme lösen können. Es gibt immer typische Lösungen für typische / typische Probleme, die in Büchern zu finden sind. Die Arbeit mit jeglichem Vermächtnis beinhaltet auch die Lösung typischer Probleme.

(Robert C Martin). « », « »

(Martin Fowler). «. »

UML — .



PlantUML (PUML) — , UML-. git, , .

Wenn Sie mit einem Produkt arbeiten, das Sie nicht vollständig verstehen, müssen Sie irgendwie lernen, wie Sie die zu erledigende Arbeit bewerten. Und Sie werden immer etwas haben, das Sie nicht wissen, einige Fallstricke.



Die Fähigkeit, eine große, komplexe Aufgabe in eine Reihe kleiner, miteinander verbundener Teile zu zerlegen, ist eine sehr wertvolle Fähigkeit. Eine Möglichkeit, es zu entwickeln, besteht darin, kontinuierlich nachträglich an Zerlegungs- und Schätzfehlern zu arbeiten. Während des Analyseprozesses können Sie aus häufig auftretenden Fehlern eine Checkliste erstellen. In Zukunft kann er Ihnen helfen, diese Fehler wieder zu vermeiden.

Automatisieren Sie CI / CD und können Sie sie anwenden

Sie müssen verstehen, was mit Ihrem Code vom Moment des Schreibens bis zum Erreichen des Geräts des Benutzers passiert. Und Sie haben die Möglichkeit zu automatisieren und CI / CD anzupassen, zu warten und zu verbessern. In Unternehmen, in denen es kein dediziertes Infrastrukturteam gibt, können und sollten diese Operationen (davon bin ich überzeugt) von Mitgliedern des Kernentwicklungsteams entschieden werden. Moderne Tools (Cloud CI, Docker) sind nicht unglaublich komplex, vereinfachen jedoch das Leben eines Teams erheblich. Sie werden in der Lage sein, sie viel zu tun, wenn Sie diese Fähigkeiten beherrschen.

Kommunizieren

Je mehr Verantwortung Sie haben, desto mehr Menschen müssen Sie kommunizieren. Die Softwareentwicklung ist längst nicht mehr die Einzelperson: Fast alle großen Projekte werden von Teams durchgeführt. Je effektiver Sie lernen, mit Ihren Mitmenschen zu interagieren, desto mehr Nutzen können Sie bringen.



Sie müssen mit Menschen kommunizieren, die klüger und erfahrener sind als Sie. In großen Projekten gibt es immer „Oldtimer“, von denen man viel lernen kann. Außerdem wirst du Leute treffen, die dümmer sind als du. Die gute Nachricht ist, dass Sie höchstwahrscheinlich falsch in Ihrer Einschätzung der geistigen Fähigkeiten liegen - es ist sehr nützlich, solche Wahrnehmungsfehler korrigieren zu können.



Ich glaube, dass die Entwicklung von Kommunikationsfähigkeiten auf die Entwicklung eines Gefühls für Empathie reduziert werden kann. Je besser Sie lernen, die Motivationen und Ziele der Menschen um Sie herum zu verstehen, desto schneller können Sie für sie nützlich werden. Wenn Sie beispielsweise einem Unternehmen die Vorteile des Refactorings und der Bearbeitung technischer Schulden erläutern, sollten Sie Geschäftsbegriffe und keine Programmierbegriffe verwenden. Scheinbar offensichtliche Idee, aber ich habe wiederholt gesehen, wie einige kluge Leute mit anderen klugen Leuten kommunizieren und sich nicht verstehen können.

Welche Fragen in einem Interview zu stellen

Hier beginne ich mit den Fragen, die ich stellen würde, bevor ich an einem Projekt arbeite, über das ich nicht viel weiß.

Wie der Workflow funktioniert und warum genau

Normalerweise arbeiten sie jetzt auf Scrum- oder Kanban-Systemen. Gleichzeitig passen sie sie oft an sich selbst an: "Sie haben das Beste genommen, das Unnötige rausgeworfen." Die Frage ist: Was genau haben sie rausgeworfen und was sind sie gegangen? Weil der Scrum-Leitfaden, auf dessen Grundlage der Entwicklungsprozess erstellt wird, einige ziemlich interessante und nützliche Methoden enthält.



Sie sind sinnvoll, wenn sie erstens, bewusst und zweitens angewendet werden. Weil sie ein System bilden, das sich selbst kontrolliert und es Ihnen ermöglicht, nicht nur das Projekt, sondern auch Ihre eigenen Prozesse iterativ zu verbessern.



Wenn das Team beispielsweise an Scrum arbeitet, würde ich fragen, was in der letzten Retrospektive besprochen wurde. Wie aktiv ist das Team bei diesem Treffen? Werden die aufgeworfenen Fragen angesprochen?



Eine weitere interessante Frage zu internen Prozessen: Wie wird die Codeüberprüfung im Team durchgeführt? Gibt es interne Regeln für die Durchführung einer Überprüfung, die dazu beitragen können, die Zeit zu verkürzen? Gibt es eine gemeinsame Wissensbasis, in die die Ergebnisse von Holivars eingegeben werden, um nicht jedes Mal zu ihnen zu passen?

Wie Planung funktioniert, wer involviert ist und wie aktiv das Team ist 

Ich würde diese Frage stellen, um zu sehen, wie stark die Ingenieurkultur im Team ist. Es gibt eine Option, wenn nur der Teamleiter plant und das Team auf seiner Seite ist.

Eine andere Möglichkeit ist, wenn das gesamte Team an der Planung teilnimmt. Und wenn eine Aufgabe kommt, wird sie von jemandem gemalt, der über genügend Fachwissen in dieser Angelegenheit verfügt. Und dann diskutieren sie alle und treffen eine Entscheidung. Dies macht das Team selbstorganisierter und den Workflow angenehmer.

Wie viele Leute im Team haben das ganze Bild

Hier sind zwei Extreme möglich. Das erste Extrem ist, wenn Sie zu einem Team kommen, das seit 2 bis 4 Jahren an einem Produkt arbeitet. Wenn sich das Team gleichzeitig nicht viel verändert, sondern nur erweitert hat, ist dies sehr gut, da Sie immer Leute haben, an die Sie sich wenden können, um Hilfe zu erhalten. Sie können etwas vorschlagen, den Grund erklären und Ihnen die Geschichte des Projekts erzählen. Es ist sehr wichtig, den Kontext zu kennen und zu wissen, warum alles so angeordnet ist und nicht anders.



Das zweite Extrem ist, wenn Sie zu einem Team kommen, das keine von denen hat, die am Start waren. Zum Beispiel wurde das Projekt eingefroren, es wurde nicht eingefroren und eine große Codebasis blieb erhalten. Sie können nicht von Grund auf neu schreiben. Dementsprechend ist es notwendig, die Entwicklung wiederherzustellen. Das heißt, Sie erhalten ein Projekt, in dem Sie alles wieder ausgraben müssen.



Basierend auf diesen Informationen können Sie eine fundiertere Entscheidung darüber treffen, ob Sie dorthin möchten oder nicht, und möglicherweise einige Ihrer Anforderungen an die Vorschläge überschätzen, auf die Sie antworten müssen.

Wie wird der technische Schuldenbestand aufrechterhalten?

In jedem Projekt gibt es Probleme, und es ist wichtig zu verstehen, wie das Team mit ihnen arbeitet. Ich habe sehr gut über die Arbeit mit technischen Schulden geschriebenalexanderlebedevim Artikel „Lannisters zahlen immer ihre Schulden! (und auch technisch) " .



Wenn das Team über die Probleme Bescheid weiß, aber nicht weiß, wie es systematisch damit umgehen soll, ist dies ein schlechtes Zeichen. Aber Sie können dies und als Gelegenheit betrachten, die Person zu werden, die bei der Lösung dieser Probleme hilft.

Tipps für diejenigen, die gerade mit einem Legacy-Projekt begonnen haben

Widerstehen Sie der Versuchung, alles von Grund auf neu zu schreiben

Eine häufige Situation: Sie beginnen mit der Arbeit an einer vorhandenen Anwendung und sehen, dass alles "falsch" gemacht wird. Und mit diesem "nicht so" müssen Sie weiter arbeiten. In diesem Fall ist es ein ganz natürlicher Wunsch, alles noch einmal aufzunehmen und neu zu schreiben. Dies ist eine normale Reaktion.



Ich denke, dass es auf der Unwilligkeit beruht, auf die Fehler anderer zu antworten. Wenn nach Ihren Änderungen neue Mängel auftreten, müssen Sie diese schließlich herausfinden. Es ist besser, es komplett neu zu schreiben, und alles wird gut.



Wenn Sie bemerken, dass Sie solche Gedanken haben, stellen Sie sich ein paar Fragen:

Gibt es definitiv genug Probleme im Code oder verstehen Sie ihn einfach noch nicht?

Sind Sie sicher, dass Sie alle Integrationspunkte des umgeschriebenen Codes genau verstehen?

Kennen Sie das Projekt gut genug, um die bevorstehende Arbeitszeit richtig vorherzusagen?



Ich bin zwar davon überzeugt, dass die Absicht, alles sofort von Grund auf neu zu schreiben, eine schlechte Idee ist. Verbesserungen sollten iterativ und überschaubar sein.

Einmal habe ich gesehen, wie das Team sagte: "Es ist alles Blödsinn, lasst uns umschreiben", sechs Monate lang umgeschrieben und nicht umgeschrieben. Infolgedessen entwickelte sich eine ziemlich interessante Situation, als das Projekt erneut von Grund auf neu geführt werden musste, um ein neues Team zu rekrutieren, da das alte Team abgefallen war. Versuchen Sie, diesen ganz natürlichen Drang zu löschen, alles von Grund auf neu zu machen.

Projektänderungen vorhersagen

Sie müssen lernen, ein kleines Orakel zu sein. Wenn Sie lange mit einem Projekt arbeiten, lernen Sie, seine Produktkomponente zu verstehen, das Geschäft zu verstehen, wie dieses Projekt verdient, wie es lebt. Dies bietet die Möglichkeit, die langfristige Perspektive der von Ihnen getroffenen Entscheidungen zu bewerten.



Dies ist eine sehr nützliche Fähigkeit, da es eine schlechte Situation ist, wenn der Produktbesitzer zu Ihnen kommt und Sie auffordert, aus seiner Sicht etwas Einfaches zu tun. Fügen Sie beispielsweise ein neues Kriterium hinzu, um die Liste zu sortieren. Und von Ihrer Seite bedeutet dies, dass Sie diese gesamte Komponente neu schreiben müssen. Dies wäre nicht geschehen, wenn Sie im Voraus gedacht hätten, dass verschiedene Arten der Sortierung dieser Liste eine vollkommen logische Funktion sind. Obwohl sie überhaupt nicht darum gebeten wurde.



Gehen Sie einfach nicht bis zum Äußersten und versuchen Sie immer, die universellsten Entscheidungen zu treffen. Dies ist ein direkter Weg zur Zeitdehnung und zu Problemen bei der weiteren Unterstützung solcher Lösungen. Der springende Punkt dieser Fähigkeit ist genau das Gleichgewicht zu finden.

Recherchieren

Wenn Sie an einem langen Projekt arbeiten, ist es wichtig, wie sehr das Unternehmen dem Team vertraut. Bevor wir ein wichtiges Feature entwickeln, führen wir auf jeden Fall eine umfassende Untersuchung des Themenbereichs durch. Es mag wie ein Kapitänskapitän klingen, aber ich kenne Fälle, in denen Menschen sofort mit ihren Köpfen in den Strudel stürzten und scheinbar einfache Aufgaben zu langwierigen Umgestaltungen wurden, die einfach durch Forschung vor der Entwicklung vermieden werden konnten.

Nehmen Sie sich Zeit zum Dokumentieren

Dokumentieren Sie, was Sie verhandeln, dokumentieren Sie Prozesse und dokumentieren Sie die Architektur. Hier versuche ich, an dem Ansatz festzuhalten, dass Sie nicht einverstanden waren, wenn Sie ihn nicht aufgeschrieben haben. Denn in Projekten, die länger als ein halbes Jahr dauern, ist es wichtig zu lernen, keine Informationen zu verlieren.



Wenn Sie eine architektonische Entscheidung treffen, erscheint es Ihnen offensichtlich. Warum es irgendwie erklären? Sechs Monate oder ein Jahr später treten bei dieser architektonischen Lösung Probleme auf. Und Sie denken: „Warum habe ich das akzeptiert? Was war der Kontext? " Das Erlernen des Schreibens dieser Architekturentscheidungen ist eine großartige Investition und wird Ihnen in Zukunft in die Hände spielen.



Eine der Möglichkeiten, solche Aufzeichnungen zu verwalten, sind Architekturentscheidungsaufzeichnungen... Die Hauptidee ist, dass Sie für jede nicht triviale Architekturlösung eine Datei mit mehreren Elementen erstellen müssen: Titel, Datum, Kontext, Lösungsbeschreibung, erwartete Konsequenzen. Diese Datei wird mit dem Code gespeichert und ändert sich nach ihrer Erstellung nicht. Sein Hauptwert ist, dass es viel einfacher ist, die Motivation zu verstehen, die dazu geführt hat, wenn die Zeit gekommen ist, diese architektonische Lösung zu ändern.

Kurz

• Ein Projekt mit einer Geschichte ist ein guter Ort für einen Entwickler, um zu wachsen, wenn er sich nicht nur für das Schreiben von Code interessiert, sondern auch für Aufgaben, die dazu beitragen, sich nicht nur als Programmierer zu entwickeln.
• In Projekten mit Hintergrund wird das Problem nicht durch den Code verursacht, sondern durch die Leute, dh ein solches Management, wenn sie von Ihnen etwas sehr schnelles und konstantes verlangen, wie zum Beispiel in der Spieleentwicklung.
• . , , , .

GDG.