Mein Manager hat mich kürzlich zum "Software Designer" befördert. Mir ist nicht bekannt, dass dieser Titel existiert. Soweit ich weiß, erstellt SAs Code-Design auf hoher Ebene und erstellt Diagramme.

Es fällt mir schwer zu verstehen, was ich für ein Code-Design auf hoher Ebene tun soll. Laut meinem Manager sollte ich alle Klassen und Methoden innerhalb dieser Klassen entwerfen. Das heißt, ich würde die gesamte Codestruktur entwerfen und mein Team die Funktionalität jeder Funktion oder Klasse implementieren lassen. In einem CRUD-System sollte ich beispielsweise planen können, welche Funktion verwendet werden soll oder welche Klassen erstellt werden sollen.

Aufgrund meiner Erfahrung im Software-Design fand ich dies äußerst unmöglich. Als Entwickler erstelle ich immer meine eigenen Klassen, definiere und implementiere meine eigenen Funktionen. Ich habe noch nie erlebt, Funktionen für andere zu entwerfen.

Meine Fragen sind:

• Ist das üblich? Ändert sich bei einem sehr großen System die Codebasis nicht ständig?
• Kann das gemacht werden?

Mir ist klar, dass ich hier vielleicht eine offensichtliche und dumme Frage stelle, aber ich war bis jetzt immer ein regelmäßiger Entwickler und habe daher keine Erfahrung mit dem Entwerfen ganzer Systeme.

Vorbemerkungen zu Titeln:

• Manchmal stimmt das, was Sie wirklich tun, überhaupt nicht mit Ihrem offiziellen Titel überein. Zum Beispiel wurde ich vor Jahren als „Analyst-Programmierer in der Forschungs- und Entwicklungsabteilung“ eingestellt. Allerdings hat niemand eingestellt, weder analysiert noch programmiert, noch geforscht oder entwickelt. Was ich (und andere) tatsächlich getan haben, war das Codieren. Ein Affe könnte die Hälfte der Dinge tun, die ich getan habe. Jeder Praktikant könnte die andere Hälfte machen.

• Oft spielt der Titel keine Rolle. In einigen Unternehmen erledigen Sie möglicherweise viele verschiedene Aufgaben, und es gibt einfach keinen Titel, der all das beschreibt. In einem Unternehmen übernahm ich die Aufgaben eines Architekten, eines Teamleiters, eines Managers, eines UX-Mitarbeiters, eines Programmierers und eines Produktivitätsspezialisten und stellte sicher, dass zwei Teams korrekt miteinander kommunizierten. Dafür gibt es keinen einzigen Titel.

• Schließlich können Titel in verschiedenen Unternehmen unterschiedliche Bedeutungen haben, oder Personen, die überhaupt Titel vergeben, haben keine Ahnung von der tatsächlichen Bedeutung des Titels, falls vorhanden. In einigen Fällen gibt es nur modische Titel und Schlagworte. Sie brauchen keinen Systemadministrator - das ist altmodisch. Sie benötigen einen DevOps-Spezialisten. Sie sprechen nicht über Business Intelligence oder Data Mining, wenn Sie versuchen, jemanden einzustellen: Sie sprechen über Big Data!

Vergessen Sie also die Titel und konzentrieren Sie sich darauf, was genau Sie tun sollen. Zum Glück macht Ihre Frage genau das.

Ist das üblich? Ändert sich bei einem sehr großen System die Codebasis nicht ständig?

Ich habe es nicht gesehen und ich glaube nicht, dass es nachhaltig sein könnte.

Kann das gemacht werden?

Ja, aber auf Kosten normaler Leute, die das Team verlassen.

Was Ihr Manager möglicherweise im Sinn hat, ist, dass Sie das Design erstellen und es in Form von UML-Diagrammen präsentieren. Es ist altmodisch, aber wen interessiert das? Die Praxis war in einigen Unternehmen sehr beliebt und funktioniert in anderen immer noch recht gut. Es mag ein geeigneter Ansatz sein, wenn Sie sehr geschickt sind, aber alle anderen Mitglieder Ihres Teams sind Anfängerprogrammierer: Sie haben einfach nicht genug Erfahrung, um das richtige Design selbst zu erstellen, und Sie sind in einer sehr guten Position, um zu helfen Sie.

Wenn ich Sie wäre, würde ich zunächst mit Ihrem Manager sprechen, um festzustellen, ob er das wirklich im Sinn hat. Wenn ja, spielen Sie das Spiel und versuchen Sie diesen Ansatz ein oder zwei Wochen lang . Was könnte möglicherweise passieren?

Entweder werden Sie feststellen, dass der Ansatz für Ihr Team gut funktioniert. In diesem Fall danken Sie Ihrem Manager für seine Erkenntnisse, oder der Ansatz funktioniert nicht.

Sprechen Sie in diesem Fall zuerst mit Ihrem Team, um herauszufinden, warum es nicht funktioniert hat und was getan werden sollte, um den Prozess zu verbessern (mit anderen Worten, machen Sie eine Retrospektive). Implementieren Sie dann entweder die Änderungen am Prozess, wenn Sie dazu in der Lage sind, oder besuchen Sie Ihren Manager und besprechen Sie dies mit ihm.

Dann wiederholen. Alle zwei Wochen (oder was in Ihrem Kontext angemessen erscheint).

Im Idealfall ist Software Architect ein anderer Begriff für Senior Software Engineer , möglicherweise mit einigen zusätzlichen Verantwortlichkeiten oder um dieser Person allgemein anzuerkennen, dass sie der offizielle Ansprechpartner für technische Probleme mit den Systemen ist, mit denen sie arbeiten. oder dass sich weniger vertraute Mitglieder des Entwicklungsteams auf sie verlassen können, wenn sie nicht wissen, warum ein Teil des Systems auf eine bestimmte Weise entworfen wurde. oder haben Probleme mit einem Problem, wenn sie keine gute / akzeptable Lösung für ein Problem finden können.

Meiner Meinung nach sollte ein Software-Architekt nicht jemand sein, der in einem sprichwörtlichen „Elfenbeinturm“ arbeitet und Entwürfe erstellt oder einseitige Entscheidungen für andere Entwickler trifft. Entwurfsentscheidungen müssen weiterhin von den Personen getroffen werden, die aktiv am Schreiben und Verwalten des Codes beteiligt sind, und Entwicklungsteams müssen die kollektive Verantwortung tragen, wobei einzelne Entwickler für die Qualität ihres eigenen Codes, das Verständnis des Entwurfs eines Systems und verantwortlich sind dafür, dass keine Änderungen eingeführt wurden, die die Architektur "brechen" oder die zu inakzeptablen technischen Schulden führen.

Während es manchmal wertvoll sein kann, das übergeordnete Design eines Systems zu erfassen, um einem Softwareteam dabei zu helfen, Ideen zu kommunizieren und Wissen auszutauschen (insbesondere für Neulinge und unerfahrene Entwickler), besteht die Hauptaktivität des Designs darin, den Code selbst zu schreiben (einschließlich automatisierter Tests); Für einen Softwarearchitekten wäre es sinnvoll, das Eigentum an der Konstruktionsdokumentation zu übernehmen, obwohl dies nicht das Gleiche ist, als würde man sagen, dass sie es schreiben. Darüber hinaus stellen sie sicher, dass das Team die erforderlichen und ausreichenden Unterlagen erstellt und diese auf ihre Richtigkeit überprüft.

Für alle praktischen Zwecke ist es wenig oder gar nicht sinnvoll, zu versuchen, die Rolle des Software-Designs von der Entwicklung zu trennen, da sie im Wesentlichen dasselbe sind - tatsächlich ist die Realität normalerweise ziemlich schädlich, weil sie dazu führt, dass Entwickler zu einer Mentalität führen werden als "Code-Affen" der Produktionslinie behandelt, denen es verboten ist, für sich selbst zu denken.

Ihrer Beschreibung nach möchte Ihr Manager, dass Sie eine Führungsposition einnehmen und nicht wissen, wie Sie dies artikulieren sollen

Er hat Sie befördert und möchte, dass Sie die Software entwerfen und die Aufgaben aufteilen. Seine Verwirrung darüber, wie man artikuliert, ist natürlich. Er versetzt Sie in eine Führungsposition, die leicht mit seiner Rolle als Manager verwechselt werden kann.

Traditionelle Entwicklungsteams haben einen einzigen Manager, der zwischen externen Aktivitäten (Finanzierung suchen, Politik, Talente für die Kopfjagd, Verkauf der Ideen und Produkte usw.) und internen Aktivitäten (Koordinierung der Entwicklung) aufgeteilt ist. Diese Aktivitäten stehen jedoch in Konflikt und erfordern unterschiedliche Fähigkeiten. Normalerweise ist "der Manager" gut in den externen Aktivitäten und schlecht in den internen.

Diese Rollen können getrennt werden. Tatsächlich ist eines der Hauptmerkmale der Scrum-Methodik. Die erfolgreichen und produktiven Teams, die ich kenne, haben diese Rollen getrennt. Und die meisten wissen nicht einmal, dass sie das tun: Einer der Programmierer begann, das Team zu organisieren, und der Manager ließ es zu.

Dies funktioniert nur, wenn zwischen "dem Manager" und dem "Hauptentwickler" ein Vertrauensverhältnis besteht. Viele Teams scheitern. Wenn einer der Entwickler die Führung übernimmt, kann sich der Manager bedroht oder eifersüchtig fühlen. Das Team kann den Respekt des Managers verlieren, weil er oder sie ständig unterwegs ist und nicht versteht, wie wichtig die externen Aktivitäten sind. Es ist wichtig, sich dessen bewusst zu sein und diese Probleme zu vermeiden.

So teilen Sie die Aufgaben

Um die Aufgaben aufzuteilen, müssen Sie seinem Beispiel nicht folgen.

Es ist wichtig, Proof of Concepts und funktionale explorative Prototypen zu missbrauchen, um den Fortschritt des Teams für ihn sichtbarer zu machen. Wichtig ist, dass er das Gefühl hat, dass die Entwicklung voranschreitet.

Eine Möglichkeit, dies zu erreichen, besteht darin, einen Nur-SQL-Prototyp zu erstellen. Erstellen Sie Tabellen, füllen Sie sie mit Daten, erstellen Sie reine SQL-Testfälle, die die Abfragen ausführen, die Hauptbildschirme und Routinen ausführen würden. Wenn Sie sicher sind, dass die Simulation gut ist, teilen Sie die Arbeit zwischen Ihren Nachwuchsentwicklern auf, um die Bildschirme und Routinen zu erstellen. Während Ihre Nachwuchsentwickler arbeiten, erstellen Sie die Prototypen für den nächsten Entwicklungszyklus.

Jeder ist beschäftigt, die Produktivität ist hoch, der Manager ist glücklich.

Probieren Sie es für ein paar Sprints aus, aber Sie werden die Entwickler, die Sie verwalten, ernsthaft ärgern und sie werden wiederum stöhnen, wer auch immer zuhört.

Ich gehe davon aus, dass Sie die allgemeinen Architekturentscheidungen (Push vs Pull; Nachrichtenmuster; sollte Service x DDD sein oder ist CRUD in Ordnung) für das Team festlegen. Verwenden Sie dann den Codeüberprüfungsprozess und das Pairing, um alle auf dem Laufenden zu halten und ihnen zu helfen, wenn sie nicht weiterkommen.

Es muss wirklich nicht von oben nach unten sein, Tod durch UML. Was Sie suchen, sind Kurse am falschen Ort; Geschäftslogik ist nicht dort, wo man es erwarten würde und so weiter.

Seien Sie nicht zu hart im Team, wenn sie etwas Wissen lernen, arbeiten Sie zuerst an neuen Prinzipien und beseitigen Sie dann alle verbleibenden schlechten Praktiken.