JH Regenwasser "Wie man Katzen weidet": auf der anderen Seite der Entwicklung

Wir teilen weiterhin Auszüge aus dem Handbuch mit denen, die sich darauf vorbereiten, das Entwicklungsteam zu leiten. Im vorigen Teil haben wir über alles Außerirdische gesprochen, was auf den technischen Leiter in der neuen Position wartet, jetzt kehren wir zu dem Vertrauten und Vertrauten zurück - dem Programmieren selbst. Hier kann sich der Entwickler von gestern in seinem Element fühlen, muss sich aber nicht entspannen - der Verantwortungsbereich wächst und verlagert sich. Unter Katze präsentieren wir einen kurzen Überblick über alle neuen Verantwortlichkeiten und Anpassungstipps, die Rainwater in seinem Buch bringt.

Der grundlegende Unterschied liegt in zwei Nuancen. Erstens tritt der Vorsprung viel früher in den Prozess ein und wird erst am siegreichen Ende beendet. Zweitens, während sich der Entwickler auf die ihm zugewiesene enge Aufgabe konzentriert, überprüft sein Chef das Produkt in seiner Gesamtheit, ohne zu vergessen, auf Details einzugehen, wenn die Situation dies erfordert. Lassen Sie uns gemeinsam mit dem Autor versuchen, die Rolle des Teamleiters in jeder Phase der Anwendungserstellung zu skizzieren.

Definition von Anforderungen und Spezifikationen

Ein guter Techlide beginnt mit dem Produkt zu arbeiten, auch wenn es sich im perinatalen Zustand befindet - dh in Form einer allgemeinen Idee, einer Anfrage oder einer Liste von Funktionen. Hier müssen Sie jedoch sofort klarstellen: Rainwater ist der festen Überzeugung, dass der Entwickler nicht in die Arbeit eines Vermarkters oder Produktmanagers eingebunden werden sollte - oder vielmehr, er sollte dieses Szenario mit aller Kraft vermeiden. Nicht, dass es für den „Techniker“ unmöglich oder verwerflich gewesen wäre, die Marktrealität und die kommerziellen Anforderungen zu verstehen, aber die Kombination dieser beiden Rollen ist sehr schwierig. Unter anderem besteht ein höheres Risiko, dass der interne Entwickler gewinnt und die Eigenschaften des Produkts eher auf die Interessen des Programmiererteams als auf den Endbenutzer zugeschnitten sind. Es ist viel einfacher und sicherer zu arbeiten, wenn die allgemeine Vision des Produkts in Bezug auf seine Funktionalität bereits von sachkundigen Personen erstellt und auf ihre Lebensfähigkeit getestet wurde.

Für die Vermischung der beiden Rollen setzen sich Entwickler, die in unserer Klassifizierung häufig zur Rasse der Cowboys gehören, häufig ein - sie sehnen sich nach "Garagen" -Zeiten, in denen winzige Teams das gesamte Produkt von und nach herstellten und es keiner externen Interaktion bedurfte. Der Autor hat es eilig, alle diesbezüglichen Illusionen zu zerstreuen: Unter modernen Bedingungen sollte die Interaktion zwischen technischen und nichttechnischen Gruppen während des gesamten Anwendungslebenszyklus regelmäßig stattfinden. Die ersten Sitzungen dienen der gemeinsamen Ausarbeitung von Spezifikationen. Der Entwicklungsleiter (oder einer der führenden Entwickler) macht sich mit der Produktbeschreibung vertraut, schließt alles aus, was ihm aus technischer Sicht ungerechtfertigt oder unrealistisch erscheint, und greift den endgültigen Plan auf, um ihn in die Sprache der Technologien zu übersetzen. Dann treffen sich von Zeit zu Zeit Gruppen, um „die Uhr zu überprüfen“ und sicherzustellen, dass die Implementierung nicht zu sehr vom ursprünglichen Plan abweicht.

Die empfohlene Häufigkeit solcher Besprechungen beträgt ungefähr einmal pro Woche, obwohl Sie natürlich das allgemeine Entwicklungstempo und die Merkmale der Organisation von Prozessen für ein bestimmtes Unternehmen anpassen müssen.

Regelmäßige Treffen sind auch aus einem anderen Grund erforderlich - Versuche, vom ursprünglichen Kurs abzuweichen, dürften nicht nur von der Entwicklungsseite ausgehen. Die meisten Anwendungen werden ständig mit zusätzlichen Tools und Funktionen erweitert, um wettbewerbsfähig zu bleiben. Daher kann der Prozess des Betrachtens, Bewertens und Wegwerfens von Ideen unendlich oft wiederholt werden, und zwar nur in einem kleineren Maßstab als bei primären Spezifikationen. Für Tehlid ist es äußerst wichtig, sich über die Pläne für die Produktentwicklung auf dem Laufenden zu halten - dies gibt ihm nicht nur organisatorischen Handlungsspielraum (Zuweisung von Verantwortlichkeiten, Festlegung von Begriffen), sondern ermöglicht es Ihnen auch, die Konsequenzen für das Gesamtsystem, sein Wohlbefinden und seine Auswirkungen im Voraus zu berechnen Nachhaltigkeit.

Bevor Sie sich bereit erklären, eine neue Funktion zu übernehmen, sollten Sie sich eine Reihe von Fragen stellen:

• Welche Auswirkungen wird die vorgeschlagene Änderung kurz- und langfristig auf die Systemarchitektur haben?
• Wie wird sich die vorgeschlagene Änderung auf die Netzwerkinfrastruktur auswirken, in der sie stattfinden wird?
• Wie wird sich die vorgeschlagene Änderung auf die Fähigkeit des Benutzers auswirken, effektiv und produktiv mit diesem Produkt zu interagieren?
• Welche Auswirkungen wird die vorgeschlagene Änderung auf das Handeln der Mitarbeiter haben, die eng mit ihm zusammenarbeiten müssen - umsetzen, begleiten?

Solche Überlegungen werden dazu beitragen, Fallstricke zu identifizieren und allgemeine Anweisungen für den Dialog mit anderen Gruppen festzulegen.

Design

Wenn die Anforderungen von allen Prozessbeteiligten genehmigt und gesegnet wurden, ist die Zeit gekommen, die Rainwater für die Koordinierung von Architektur- und Entwurfsentscheidungen hält. Mit anderen Worten, der technische Leitfaden muss das System beschreiben, das die in der Phase der Spezifikationen angegebenen Funktionen ausführt, und die für bestimmte Verfahren verantwortlichen Komponenten überdenken. Es ist wichtig, in dieser Reihenfolge zu handeln:

Zuerst Architektur, dann Komponenten.

Der Autor betont dies oft, weil viele Entwickler, die mit der Kunst des Produktdesigns nicht vertraut sind, in diese Falle tappen. Es erscheint logisch, eine Liste von Anforderungen zu erstellen, die erforderlichen Komponenten für jede Komponente vorzuschreiben und das Produkt als eine einfache Kombination davon zu betrachten. In der Realität führt dieser mechanistische Ansatz jedoch zu starren, zufällig organisierten Monstern, die den Entwicklern, die an der Unterstützung des Projekts beteiligt sind, alle Säfte entziehen. Um dies zu vermeiden, müssen Sie vom Ganzen zum Besonderen den umgekehrten Weg gehen. Sie haben bereits eine gemeinsame funktionale Vision des Produkts mit einer Entwicklungsperspektive - Sie müssen sie in Ihrer allgemeinen technischen Vision mit einer Entwicklungsperspektive, dh Architektur, „spiegeln“.

Gebäudearchitektur

Wenn wir auf eine abgedroschene Metapher zurückgreifen, ist Architektur das Gerüst des Produkts, auf dem dann das Fleisch privater Entscheidungen über die Implementierung von Verfahren aufgebaut wird. Wir beleben diese Metapher ein wenig und fügen eine Klarstellung hinzu: Das Skelett muss geschärft werden, um neue Glieder wachsen zu lassen. Die beiden Hauptanforderungen an die Architektur sind eine klare logische Organisation der Komponenten und Flexibilität, die im Verlauf des Projekts neue hinzufügen.

Vielleicht kann diese Phase der Entwicklung als die verantwortungsvollste bezeichnet werden - Experten sagen, dass gerade die Vernachlässigung von Architekturproblemen am häufigsten zum Zusammenbruch von Projekten führt. Unter den häufigsten Fehlerursachen nennen sie:

• Mangel an Gedanken, schlampige Organisation (oder deren völlige Abwesenheit).
• Übermäßige Steifigkeit und Unkompliziertheit des Systems verhindern dessen Erweiterung gemäß den kommerziellen Anforderungen.
• Übermäßige Interkonnektivität der Komponenten, mangelnde Flexibilität bei der Konfiguration.
• Übermäßige Komplexität in den oberen Ebenen, was es schwierig macht, die Grundkomponenten zu modifizieren.

Entsprechend seriös und ressourcenschonend sollte die Aufgabe der Gebäudearchitektur angegangen werden. Denken Sie daran, dass Sie das Fundament legen, mit dem Sie bis zum Schluss arbeiten müssen - es muss allen Änderungen standhalten, die in Zukunft auf das Projekt warten. Dieser Prozess ist weitgehend kreativ und visionär, aber Standardmethoden zur Strukturierung sind nützlich, um das System auszugleichen. Zeichnen Sie beispielsweise ein Blockdiagramm mit einem vollständigen Satz von Verbindungen oder implementieren Sie sogar ein einfaches Layout (einen Satz von Low-Level-Komponenten mit Stubs und Rückgabewerten), um sicherzustellen, dass die Architektur in einer vertikalen Projektion funktioniert. Letzteres ist sehr wünschenswert, bevor mit der Entwicklung echter, vollwertiger Komponenten begonnen wird - die Beseitigung von Fehlern mit "Spielzeug" -Elementen ist viel einfacher und schmerzloser.

Am Ende der Arbeit in dieser Phase sollten Sie bereit sein, die folgenden Fragen zu beantworten:

• Wie wird der Benutzer mit dem System interagieren?
• Welche Komponenten müssen zusammengebaut werden, um das Funktionieren des Systems zu gewährleisten?
• Welcher Mechanismus für das Zusammenspiel von Komponenten stellt das Funktionieren des Systems sicher?
• Welche Technologien eignen sich am besten, um diese Anwendung zu erstellen?
• Wie soll das System an den Kunden geliefert werden?

Komponentenplanung

Wenn das allgemeine Gerüst entwickelt ist, ist es an der Zeit, sich insbesondere mit den derzeit relevanten Komponenten in der organischen Struktur auseinanderzusetzen und sie zu implantieren. Die Hauptschwierigkeit besteht darin, dem notwendigen Maß an Verbundenheit standzuhalten. Einerseits sollten Komponenten nicht als streng isolierte Behälter für bestimmte Betriebsabläufe betrachtet werden, sondern als ein System von Organen, von denen jedes mit dem anderen kommuniziert, sondern seine Funktionen erfüllt. Gleichzeitig sollte eine starke gegenseitige Abhängigkeit zwischen den Regionen vermieden werden, wodurch die Änderung einer Komponente zu einer ganzen Kette von Änderungen oder sogar Fehlfunktionen im gesamten System führt.

Der Technologie-Stack wurde in der letzten Phase skizziert, jetzt müssen Sie ihn im Detail verstehen. Bei der Wahl der Sprache, der Bibliotheken und darüber hinaus ist es sinnvoll, sich nicht nur von professionellen, sondern auch von streng pragmatischen Motiven leiten zu lassen. Haben Sie genügend kompetentes Personal, um Systeme zu unterstützen, die auf fortschrittlichen, seltenen oder komplexen Technologien basieren? Und umgekehrt, wenn Sie älteren Technologien den Vorzug geben, wie vielversprechend ist das? Werden sie während des gesamten Lebenszyklus weiter funktionieren, treten Kompatibilitätsprobleme auf? Alle Fragen im Zusammenhang mit Hardwarelösungen, Erstellung, Konfiguration und Wartung der Infrastruktur sollten mit der gleichen Sorgfalt behandelt werden.

Entwicklung und Qualitätskontrolle

Damit ist die Planung abgeschlossen und das Projekt geht an die Arbeit - die eigentliche Entwicklung der Anwendung beginnt. Die Rolle des technischen Leiters in diesem Prozess besteht hauptsächlich in der Überwachung, damit alles in Übereinstimmung mit den Bedingungen und Standards verläuft. er ist in der Regel nur in Fällen höherer Gewalt direkt an der Codeerstellung beteiligt. Zum größten Teil übt der Leiter die Funktionen einer Code-Polizei aus, das heißt, er überprüft den Code regelmäßig kritisch, um sicherzustellen, dass er nicht dem architektonischen Rahmen und den Grundprinzipien der Programmierung widerspricht.

Bei Inspektionen kann ein technischer Leiter auf verschiedene Arten von Fehlern stoßen. Regenwasser konzentriert den Leser auf zwei Sorten:

• Verletzung von Standards . Dazu gehört das Stylen, Benennen, Kommentieren - im Allgemeinen alles, was einem Dritten hilft, zu verstehen, was im Code vor sich geht, sowie Nachlässigkeit im Sinne mehrerer Exit-Points oder gehasster GoTo-Operatoren. Es muss sichergestellt sein, dass alle am Entwicklungsprozess Beteiligten dieselbe Sprache sprechen - dies macht den Code transparent und ermöglicht es Ihnen, fehlerhafte Bewegungen schnell zu enträtseln. Die Namen der Parameter und Variablen sollten klar ihren Inhalt angeben, Kommentare sollten helfen, den Code der Gedanken eines Entwicklers zu verfolgen und seine Entscheidungen zu rechtfertigen. Übrigens, wenn sich jemand aus dem Team hartnäckig weigert, den Code zu kommentieren, lohnt es sich darüber nachzudenken, warum. Oft ist dies nur Faulheit oder eine Besonderheit des Denkens, aber in einigen Fällen kann es sich als Symptom herausstellen, dass der Mitarbeiter selbst nicht wirklich versteht, was er tut - verwirrt oder einfach Teile des Codes eines anderen aus gutem Grund kopiert. Es ist auch notwendig, diejenigen, die die Fehlerbehandlung regelmäßig vernachlässigen, sorgfältig zu überwachen: Die Unfähigkeit, Fehlerquellen zu identifizieren, ist ein schwerwiegender Fehler für den Entwickler.
• Schwache Konnektivität und starke gegenseitige Abhängigkeit sind zwei Störungsbereiche, die zusammen betrachtet werden können, da die Anwesenheit des einen die Anwesenheit des anderen impliziert. Tatsächlich hängt hier alles vom Verzweigungsgrad und seiner Art ab. Bei einem hohen Verzweigungsgrad in Bezug auf die Ausgabe erfordert die Funktionsweise des Verfahrens den Zugriff auf viele andere Verfahren, was natürlich unerwünscht ist. Die Verzweigung am Eingang wirkt sich dagegen positiv aus, da sie auf eine strikte Verkapselung hinweist. Wenn Sie bei der Analyse des Codes für diese Parameter Zweifel haben, ist es hilfreich, ein Blockdiagramm mit einer markierten Hierarchie von Objekten zu erstellen. Es zeigt sofort alles, was Sie wissen müssen: Ist es möglich, den Stammbaum des Objekts zu verfolgen, ist die Anordnung der Pfeile logisch, oder sieht alles chaotisch aus?

Wenn die Codepolizei Verstöße in diesen und anderen Bereichen aufdeckt, sieht das Festnahmeverfahren folgendermaßen aus: Der Code wird mit den erforderlichen Kommentaren an den Entwickler zurückgesandt, die Arbeit an der entsprechenden Komponente wird ausgesetzt, bis die Mängel behoben sind. Es ist sehr wünschenswert, dass der Entwickler dies selbst erledigt, wenn auch mit Trinkgeldern - wenn Sie alles für ihn tun, geht die Mentoring-Komponente der Code-Inspektion verloren.

Verschieben Sie die Überarbeitung nicht bis zu besseren Zeiten. Erstens kann es in der Zukunft stark zurückkehren und viel mehr Ressourcen erfordern, um den ganzen Schneeball der Probleme zu beheben. Zweitens funktioniert die Theorie der zerbrochenen Fenster auch in der Programmierung - unordentlicher, verwirrter Code erzeugt noch unordentlicher, verwirrter Code, einfach weil er gültig scheint.

Wenn man schließlich von Qualitätskontrolle spricht, muss man das Problem des berüchtigten menschlichen Faktors ansprechen. Rainwater empfiehlt, dass der Manager eine mittlere Position einnimmt. Ein gewisser Grad an Beständigkeit gegen Störungen des Codes ist natürlich und harmlos. Die völlige Bereitschaft, den Anweisungen eines anderen zu folgen und die Meinung eines anderen anzunehmen, sollte Sie sogar alarmieren - häufig bedeutet dies, dass es dem Entwickler in der Tat egal ist, was er veröffentlicht. Andererseits behindert die Unfähigkeit, fundierte Kritik wahrzunehmen, sowohl das berufliche Wachstum als auch die Teamarbeit. Dementsprechend muss der Technlide eine dickere Haut bekommen und keine Angst haben, auf sich selbst zu bestehen, ohne eine negative Reaktion auf ihr Herz zu haben.

Testen

Hierbei ist es wichtig, dass der Leiter zwei Grundregeln beachtet: Das Testen sollte durchgeführt werden und die Organisation seines Verhaltens liegt in Ihrer Verantwortung. Wenn das Unternehmen eine Testabteilung hat, die natürlich in die Prozesse involviert ist, gibt es keine Probleme damit. Wenn nicht, müssen Sie für diese Angelegenheit eine Ressource aus Ihren eigenen Reserven zuweisen.
Im zweiten Szenario gibt es laut Autor bestimmte Vorteile: Testen ist eine nützliche Fähigkeit für den Entwickler. Es ist besonders nützlich, Neuankömmlinge für diese Aufgaben zu gewinnen, damit sie sich schnell qualifizieren können. Zunächst können Sie Testaufgaben bis zur Hälfte ihrer Arbeitszeit übernehmen.

Andernfalls muss zur Gewährleistung einer guten Inspektionsqualität sichergestellt werden, dass das Produkt nicht die ganze Zeit in derselben Gruppe kocht - idealerweise sollte es „nebenbei“ getestet werden. Wenn ein Unternehmen mehrere Entwicklungsteams hat, kann es sinnvoll sein, mit anderen Führungskräften eine gemischte Gruppe zu bilden.