Mach es nicht in der Produktion

Ungefähr im März 2017 wurde ich gebeten, vor dem Start eine Codeüberprüfung des Produkts durchzuführen. Das Unternehmen hatte Probleme mit Speicherlecks, spontanen Abstürzen, langsamem Laden, einem Anstieg des CPU-Verbrauchs und eine Veröffentlichung war in wenigen Wochen geplant. Sie haben diese Geschichte vielleicht schon gehört - nicht von mir und nicht von dieser Firma. Sie ist überraschend typisch.

Wir haben uns am Wochenende getroffen und uns gemeinsam den Code angesehen. Nach ungefähr einem halben Tag wurde eine Quelle bekannter Probleme entdeckt, und ein weiterer halber Tag dauerte, um ein Fixdokument für Entwickler zu schreiben. Die Einführung war ein Erfolg, aber die Geschichte ließ mich nachdenken: Wie hat das Produkt einen solchen Zustand erreicht?

Als ich mit den Entwicklern sprach, schienen sie kluge Leute zu sein. Das einzige offensichtliche Problem war der Mangel an Erfahrung. Ich bin schon einmal darauf gestoßen. Dies ist ein weit verbreitetes und ganz normales Phänomen. In diesem Fall wurde jedoch ein abscheulicher Fehler festgestellt: Erfahrung war nicht für alle Entwickler ausreichend.

Kürzlich wurde eine Entwicklungsabteilung eingerichtet und ein Team in Abwesenheit eines technischen Direktors eingestellt. Selbst ein Technikfreak hat es schwer, einen anderen Programmierer zu testen - ich kann mir keinen Test ohne technisches Wissen vorstellen. Sie stellten den ersten Entwickler ein, er überprüfte den zweiten Entwickler - und so weiter, bis ein Team gebildet wurde.

Wenn Sie Glück haben und der erste Entwickler über umfangreiche Erfahrung und den Wunsch zu trainieren verfügt, sind Sie bei den Damen. Wenn Sie jedoch Pech haben - und die Chancen dafür sehr hoch sind -, erhalten Sie ein schnelles Team, das sehr fragile Software erstellt.

"Handeln Sie schnell und brechen Sie alles", sagen sie. Dies ist jedoch eine ziemlich schlechte Idee, wenn das Unternehmen auf eine kleine Anzahl großer Kunden angewiesen ist. Defekte Produkte schrecken sie normalerweise ab, was wiederum Ihr Unternehmen trifft. Sie können die effektive Strategie auf verschiedene Arten beschreiben, aber der Ausdruck „langsam und stetig auf das Ziel zu“ ist eindeutig nicht beeindruckend.

In der Tat gibt es ein Gleichgewicht zwischen schneller und langsamer Bewegung. Es ist schwierig, dieses Gleichgewicht zu finden, da jedes Produkt sein eigenes Gleichgewicht hat. Ich nehme an, dass Intuition auf Erfahrung basiert, und dies ist eine schreckliche Antwort für einen Anfänger.

Was tun mit dem neuen Entwickler?

Es erscheint natürlich, im Internet nach einer Antwort zu suchen. Es stellt sich heraus, dass es unglaublich effektiv ist .

Aber es ist auch unglaublich gefährlich .

Ich habe nach der Produkteinführung mit diesem Unternehmen zusammengearbeitet. Ich habe eine beträchtliche Menge Code durchgesehen, Entwickler geschult und neue Projekte für sie erstellt. Alles verlief reibungslos.

Einmal wurde meine Aufmerksamkeit von einem Stück Code angezogen. Ich hätte schwören können, dass ich ihn schon einmal gesehen habe. Durch das Googeln der Zeile habe ich natürlich eine genaue Kopie des Codes in einem Blog-Beitrag gefunden. Natürlich habe ich den ganzen Artikel gelesen - bis auf den Absatz: "Mach das nicht in der Produktion . "

Aber diese Zeilen betrachten mich direkt von der Codebasis in der Produktion.

Es dauerte nicht lange, bis viele Codeteile aus ähnlichen Artikeln gefunden wurden. Ein Haftungsausschluss wurde fast überall geschrieben, oder es war eindeutig nicht genug. Alle haben einen kleinen Teil des Problems gelöst, aber viele Freiheiten zugelassen, um den Code leichter lesbar zu machen. Dies kann verstanden werden. Die meisten Leser schätzen die Kürze beim Erlernen eines Konzepts.

Der Code aus diesen Blogeinträgen verbreitete sich als Infektion in der Codebasis und verursachte hier und da Probleme ohne Grund oder Muster. Und es gab keine offensichtliche Heilung, außer den gesamten Code hintereinander zu lesen und die Probleme einzeln manuell zu beheben. Ohne Unit-Tests und automatische Bereitstellung dauerte es fast ein Jahr . Ich bin mir ziemlich sicher, dass die Kosten für das Reparieren des Codes die Kosten für das Schreiben überschritten haben.

Aber welche Wahl hatten diese Entwickler? Sie mussten etwas veröffentlichen, und sie hatten noch nie zuvor eine Anwendung in der Produktion veröffentlicht. Deshalb taten sie, was jeder gesunde Mensch versuchen würde - und lernten dabei.

Produktionssysteme versagen auf unglaublich viele Arten. Ohne Erfahrung oder theoretisches Wissen über diese Fehler ist es schwierig, intuitiv zu verstehen, wie solche Probleme verhindert oder gelöst werden können. Es ist schwierig, ein neues Team zu benötigen, um ein perfektes Ergebnis zu erzielen, insbesondere ohne irgendeine Art von Führung.

Bevor ich fortfahre, möchte ich darauf hinweisen, dass jede Person, die an diesem Chaos beteiligt war, gute Absichten hatte. Die Entwickler wollten ein gutes Produkt erstellen und entwickeln. Manager wollten das Gleiche. Blog-Autoren wollten nützliche Lösungen teilen. Alle haben versucht, sich gegenseitig zu helfen, und es ist wichtig, sich daran zu erinnern.

Das Problem liegt nicht bei Menschen.

Ich sympathisiere sehr mit den Entwicklern, die in dieser Position sind. Sie haben mehr Informationen als sie jemals brauchen werden, aber sie sind völlig unorganisiert. Dies ähnelt dem Versuch, ein Puzzle aus zehn Teilen zusammenzusetzen. Sie müssen es nur in einem Haufen von 10.000.000 Teilen finden, wobei alle Teile quadratisch sind und das Endergebnis unbekannt ist. Viel Glück.

Wenn Sie hier in der Hoffnung auf eine Antwort lesen, tut es mir leid: Ich habe keine einfache Antwort. Dieses Problem ist schwer zu lösen. Die Lösung ist zu groß für einen Artikel, sie ändert sich jeden Tag und unterscheidet sich in den Nuancen für jedes Projekt.

Dieses Problem veranlasste mich, ein Blog zu starten. Ich hatte das Glück, fast zwanzig Jahre lang von unglaublich talentierten Mentoren, Schriftstellern und Kollegen zu lernen. Ohne den Rat dieser Leute würde ich immer noch GOTO Anweisungen in QBasic (brrr) schreiben. Es ist Zeit, den Ball zu nehmen und in die Offensive zu gehen.

Zusammenfassend.

Dieser Blog widmet sich allen Aspekten der Entwicklung vorgefertigter Anwendungen: von der Automatisierung der Infrastruktur bis hin zu Tests, Design, Debugging, Dokumentation, Entwicklungsprozess und Sicherheit. Jeder Artikel ist unabhängig und für den Einsatz in der realen Welt geeignet - für den Einsatz in der Produktion geeignet .