Vor zwanzig Jahren war ich auf dem Gebiet der Technologie tätig, zehn Jahre später wechselte ich in die Führungsposition und jetzt bin ich wieder zur Technologie zurückgekehrt, diesmal als Berater. Einige der Änderungen haben mich sehr glücklich gemacht, während andere mich genauso überrascht haben. Im Folgenden werde ich kurz auf die wichtigsten Dinge eingehen, die mich in der Blüte des Lebens fast umgebracht haben.
Schön zuerst: Unix und Entwickler wieder vereint
In den achtziger und frühen neunziger Jahren wurde die meiste professionelle Softwareentwicklung auf teuren Unix-Workstations wie Sun Sparc oder NeXT durchgeführt. In den neunziger Jahren wurde der Markt von WinTel erobert und jeder begann unter Windows mit Tools von großen Anbietern wie MS Visual Studio oder einigen kostenlosen Optionen wie Eclipse zu programmieren. Linux galt damals noch als etwas mehr für Hobbyisten in der Desktop-Welt.
Im Jahr 2001 arbeitete ich bei einem Startup. Es gab nur einen Linux-Entwickler für unser gesamtes Team, und es fiel ihm schwer, den Zugriff auf Versionskontrolltools und den Outlook-E-Mail-Client zu sperren. Normalerweise schickte er uns einen Code per Brief und bat darum, ihn auszufüllen. Ich erinnere mich, dass ich damals selbst XEmacs benutzt habe - wie in guten alten Zeiten.
Schneller Vorlauf in die Gegenwart. Unix ist unter Entwicklern, insbesondere auf dem Mac, zu einer sehr beliebten Plattform geworden, da es den Unix-Kernel verwendet. Darüber hinaus gibt es Linux unter Windows. In dieser Hinsicht war meine Rückkehr zur IT im Gegensatz zu vielen anderen nicht mit Schwierigkeiten verbunden. Es ist lustig, dass viele meiner jungen Kollegen Windows kaum noch verwalten und sich unter Linux viel sicherer fühlen.
Release Management ist kein Beruf mehr
Es war einmal eine verdammt schwierige Aufgabe, Konflikte zu verzweigen, zusammenzuführen und zu lösen, die oft die Intervention eines engagierten Release-Spezialisten erforderte. In den Tagen, als ClearCase auf dem Versionskontrollmarkt regierte, gab es genug Arbeit für ein großes Team - zumindest nach meiner Erfahrung bei HP im Jahr 2002.
Die Idee, dass ein Entwickler Änderungswünsche selbst einreichen kann, ist eigentlich noch recht jung. Anscheinend erhielt sie den Beginn des Übergangs der Entwicklung zu Linux und eine neue Welle verteilter Versionskontrollsysteme: BitKeeper, Git und so weiter. Ältere Systeme wie ClearCase, CVS, SVN oder PerForce konnten keine eigenen Änderungen vornehmen, sodass sie sich in allen am Workflow Beteiligten widerspiegeln würden. Entweder der Repository-Eigentümer hat es getan oder die Person, die für das Release-Management verantwortlich ist, oder jeder Entwickler hat alles für sich selbst organisiert. Jetzt wurde der Prozess stark vereinfacht, und es ist jetzt möglich, ohne zusätzliche Teilnehmer eine gemeinsame Arbeit in einem Team aufzubauen.
Wo sind die QS-Teams? Unit Testing und kontinuierliche Integration
Ich habe zum ersten Mal von Kent Beck, einem der Autoren des Agilen Manifests und Erfinder der extremen Programmiermethodik, von Unit-Tests und kontinuierlicher Integration gehört . Vor zwanzig Jahren waren seine Ideen revolutionär, aber sie erreichten nicht sofort den Status eines Entwicklungsstandards, den sie jetzt haben.
Meiner Meinung nach ist es eine Schande, dass die kontinuierliche Integration in Agile und Scrum nicht mehr im Vordergrund steht. Aber ich bin schon froh, dass diese Praxis heute sehr beliebt geworden ist. Ich nahm an dieser Konferenz teil und erinnere mich, dass Joshua Bloch, Autor von Java Collections, auf die Bühne trat, um über kontinuierliche Integration zu sprechen. Er sagte: "Vielen Dank (Agile oder JUnit), dass Sie der kontinuierlichen Integration einen Reiz verliehen haben." Und er hatte recht. Früher galt das Schreiben von Tests als langweilig, und nur wenige Leute taten es. Deshalb stellten die Chefs spezielle Leute ein, QS-Ingenieure, die nach Fehlern für die Entwickler suchten! Verrückt werden, dieser Lafa war ...
Unit-Tests und kontinuierliche Integration haben die Notwendigkeit solcher Personen fast beseitigt - jetzt sind Entwickler dafür verantwortlich, Tests selbst zu schreiben, und die Infrastruktur für kontinuierliche Integration startet alles pünktlich und meldet Fehler. Dies macht die Software zuverlässiger und verkürzt den Entwicklungszyklus. Außerdem haben die Innovationen den Entwicklern geholfen, eine ganzheitlichere Sicht auf die Dinge zu gewinnen und zu lernen, wie man Code schreibt, damit er leicht getestet werden kann.
Docker: Keine Unordnung mehr auf dem Weg zur Produktion
Container, nämlich Docker, haben alle unnötigen Elemente aus der Paketverwaltung entfernt und die Umweltprobleme minimiert, die auftreten, wenn der Code Tests besteht und in Produktion geht. Zuvor müssen Sie jedoch einen guten DevOps-Techniker beauftragen, um das Docker-Ökosystem einzurichten.
Früher kam es vor, dass das System in einer völlig anderen Umgebung erstellt wurde, in der es bereitgestellt werden sollte (das heißt, sie haben beispielsweise Code unter Windows geschrieben und unter Unix bereitgestellt). Dies verursachte unweigerlich Fehler und häufte zusätzliche Arbeit in jedem Test-Release-Zyklus an.
Darüber hinaus hat in der Vergangenheit ein Release-, Test- oder DevOps-Spezialist Code aus einem Tag in der Quellcodeverwaltung entnommen und entschieden, was mit Kompilierung, Test und Migration geschehen soll. Normalerweise würde dies eine ganze Reihe fest codierter Pfade und Variablen aufdecken, fehlende Bibliotheken und Dateien, die überarbeitet oder optimiert werden mussten, um ordnungsgemäß zu funktionieren.
Docker vereinfachte den Prozess und schuf Bedingungen für die kontinuierliche Integration und Bereitstellung, indem die relevanten Funktionen erneut in die Hände von Programmierern gelegt wurden.
Open Source: Zu viele Möglichkeiten
In der Welt der Open-Source-Software gibt es jetzt offen gesagt eine große Auswahl. Ich habe hier Jenkins eingerichtet und wollte mich in BitBucket integrieren. Eine Suche nach Plugins für "bitbucket" ergab mehr als vierhundert Ergebnisse, von denen viele Open Source sind.
Dies schafft zwei Probleme:
- Es ist schwieriger, aus einer Vielzahl von Optionen auszuwählen
- Mit solch einer Fülle werden einige der Instrumente definitiv aussterben und ihre Unterstützung wird aufhören.
Aber es gibt auch Vorteile: Es ist fast nicht erforderlich, die grundlegende Infrastruktur und die Tools selbst zu erstellen - finden Sie das, was Sie benötigen, und verwenden Sie es. Vor zwanzig Jahren musste man Bibliotheken und Datenstrukturen für die häufigsten Operationen schreiben, und irgendwo hat es sogar Spaß gemacht. Heutzutage gibt es so viele verschiedene Bibliotheken und Frameworks für jede Sprache, dass 99% der Entwickler leben können, ohne einen einzelnen B-Baum, eine Hash-Tabelle oder sogar einen OAuth-Connector zu schreiben.
Agile und Scrum haben die Welt erobert
Vor zwanzig Jahren war Agile bereits lebendig und gesund (das Agile Manifest wurde 2001 veröffentlicht), aber seine Popularität begann später zu wachsen - auch außerhalb der IT und manchmal in verzerrter Form. In Führungskreisen wurde er zu einem Lieblingssprichwort : "Das Geschäft muss agil bleiben, sonst wird es nicht überleben."
Ich erinnere mich an die Zeiten, als der Veröffentlichungszyklus ziemlich lange dauerte (drei Monate, und dies ist in einem Startup). Nach der Rückkehr von der Besprechung, bei der er die Spezifikationen Zeile für Zeile analysierte, konnte sich der Entwickler an den Tisch setzen und mehrere Wochen lang ruhig spielen, ohne sich Sorgen machen zu müssen, dass er über den Stand der Dinge berichten musste. Und jetzt jeden Tag Stand-up-Rallyes, alle zwei Wochen Sprints - Sie können sich nicht wirklich entspannen!
Agile verteilte auch Verwaltungsfunktionen neu - jetzt kommunizieren Entwickler direkt mit Benutzern oder Produktmanagern. Lehnen Sie sich in Ruhe zurück wird nicht mehr funktionieren. Dementsprechend ist die Kommunikationsfähigkeit viel wertvoller geworden als zuvor.
Schließlich hat sich das Entwicklungstempo mit Agile beschleunigt. Es geht nicht einmal um Stand-up-Meetings und andere Scrum-Projekte. Die Tools selbst haben uns Zeit gespart: Whiteboards in Jira, Änderungsanforderungen, Tools für die kontinuierliche Entwicklung und Bereitstellung - all dies ermöglicht eine schnellere Arbeit. Dies trägt einerseits zu alltäglichen Sorgen bei, andererseits spüren Sie die Rückkehr der Tatsache, dass Sie die Produkte in kurzer Zeit einführen und Aufgaben umfassend erledigen.
Abschließend
Wenn Sie auch die IT verlassen haben und daran denken, zurückzukehren, unterstütze ich Sie und wünsche Ihnen viel Glück. Persönlich habe ich meine Fähigkeiten gerne aktualisiert (obwohl ich auf dem Weg fast gestorben wäre). Die Grundprinzipien der Programmierung sind gleich geblieben, also denke ich, dass ich es irgendwie schaffen werde. Das Toolkit hat sich jedoch stark verändert, was sich auf die Produktivität auswirkt.
Sie haben wahrscheinlich ein wiederkehrendes Thema in dem Artikel entdeckt: Ein moderner Entwickler hat ein viel breiteres Aufgabenspektrum als vor zwanzig Jahren. Er schreibt Code, führt Versionskontrolle durch, testet, was er geschrieben hat, arbeitet mit Containern und so weiter. Natürlich kocht das Gehirn manchmal, aber Sie müssen keine verknüpften Listen mehr selbst erstellen.