it-swarm.com.de

Wie kann die Konsistenz in der gesamten Anwendungsarchitektur aufrechterhalten werden, wenn ein Team wächst?

Als einziger Entwickler in einem Startup hatte ich den Luxus, viele Entscheidungen in der Architektur und den Frameworks unserer Anwendung treffen zu können.

Schneller Vorlauf 4 Jahre und eine Akquisition später, ich habe ein Team von 5 und oft fühlt es sich an wie der wilde Westen. Menschen, die eine Entwurfsentscheidung treffen, die ihnen gefällt: Ganzzahlen und Aufzählungen für DB-Typen an einer Stelle und Zeichenfolge an einer anderen Stelle, dieses Framework für ein Problem und dann ein anderes Framework für dasselbe Problem an anderer Stelle usw.

Wie erzwinge ich die Konsistenz? Es fühlt sich für mich wichtig an, aber meine Teammitglieder scheinen die Methode "Wenn es funktioniert, funktioniert es" zu abonnieren.

Ich denke, ein großer Teil meiner Frage ist: Ist es unrealistisch von mir, solche Standards zu erwarten? Ich kämpfe mit der Idee, als Diktator zu wirken, der die Kreativität unterdrückt, aber zu tun, was immer sie wollen, scheint nicht skalierbar zu sein.

50
Deekor

Was macht dich so besonders?

Meine CPU sagt, dass es funktioniert und ich nach Hause gehen möchte. Warum störst du mich?

Sie können mit dieser Einstellung umgehen, indem Sie alle dazu zwingen, Pull-Anfragen zu stellen. Aber jetzt stehen die Fristen vor der Tür. Schlechter Code drückt auf die Tore Ihres unberührten Schlosses und Sie geben schließlich dem Druck nach. Oder du gewinnst nur, um zu finden, dass alle gehen und niemand dein unberührtes Schloss benutzt.

Es gibt viele Tools, die bei diesem Problem helfen. Quellcodeverwaltung, Codeüberprüfungen, Codierungsstandards usw., aber das Herz und die Seele des Problems sind Ihre subjektiven Meinungen darüber, was am besten ist, müssen als relevant angesehen werden. Dafür muss man sich ihren Respekt verdienen und bewahren. Tun Sie das und das ist viel einfacher. Wenn Sie dies nicht tun, werden Sie durch kein Werkzeug oder keine Übung gerettet.

Der beste Weg, dies zu tun, ist früh zu kommunizieren. Sagen Sie mir nicht "Wir verwenden in diesem Shop keine Zeichenfolgen für unsere DB-Typen" 6 Monate nachdem ich mich für die Idee entschieden habe. Mir zu sagen, dass es seit 2 Jahren in der Dokumentation vergraben ist, ist keine Rechtfertigung dafür, mich das tun zu lassen.

Aus irgendeinem Grund haben Sie Dinge, die Sie interessieren. Wenn Sie sich für sie interessieren und einen Punkt haben, lassen Sie diese Dinge vor, während und unmittelbar nach der Codierung jedes Moduls klar kommunizieren.

Code-Stalking ist eine wunderbare Praxis. Investieren Sie in die Tools und Methoden, die Sie benötigen, damit Sie den Code innerhalb von Minuten nach dem Schreiben überprüfen können. Paarprogramm und das Werkzeug ist einfach ein Gaststuhl.

Warum? Jede Sekunde, die vergeht, nachdem ich Code geschrieben habe, erhöht die Kosten für die Änderung exponentiell. Das liegt daran, dass meine Erinnerung an den Code eine Halbwertszeit hat. Ich fange an, es zu vergessen, sobald meine Blase eine Pause verlangt.

Reduzieren Sie die Dinge, die Ihnen wichtig sind, auf die zugrunde liegenden Prinzipien. Anstatt mich mit einer Liste von 101 Regeln zu schlagen, geben Sie mir die 10 Prinzipien, gegen die sie verstoßen, damit ich selbst herausfinden kann, welche Regel 102 sein sollte.

Ermöglichen Sie mir, meine eigene Vision durchzusetzen, indem Sie mir helfen, Ihre zu sehen, und wir kommen großartig miteinander aus.

ist es unrealistisch von mir, solche Standards zu erwarten? Ich kämpfe mit der Idee, als Diktator zu wirken, der die Kreativität unterdrückt, aber zu tun, was immer sie wollen, scheint nicht skalierbar zu sein.

Dann diktiere nicht! Machen Sie dies zu einer positiven Erfahrung. Dies ist kein New-Age-Hippie-Unsinn. Es ist grundlegende Psychologie. Sie versuchen, menschliches Verhalten zu ändern. Zufällig und positiv ist am stärksten (fragen Sie einfach Las Vegas). Wenn Sie negativ werden, müssen Sie mit Ihrer Verstärkung übereinstimmen. Das ist ein unerreichbarer Schmerz. Seien Sie positiv, wenn Sie die Weisheit verbreiten, und Sie können lässig darüber sein.

Ich weiß, woher du kommst, weil ich dort gewesen bin. Du hattest die Kontrolle und jetzt ist es weg. Du willst es zurück. Nun komm drüber hinweg. Jetzt hast du ein Team. Sie müssen nicht kontrolliert werden. Was sie brauchen, ist Führung. Was Sie brauchen, ist keine Kontrolle. Es ist Einfluss. Es funktioniert besser und ist viel weniger Arbeit. Meistere das und entspanne dich. Das sollte Spaß machen.

Wenn Sie es richtig machen, können Sie in den Urlaub fahren und das wird immer noch funktionieren. Wie? Indem wir nicht nur ein Führer sind, sondern auch die anderen dazu bringen, Führer zu sein. Sobald Sie Ihre Vision in das Team eingebracht haben, können sie arbeiten, während Sie weg sind, indem Sie einfach nachahmen, was Sie getan haben. Mentor der Neulinge und ermutige sie, auch andere zu beeinflussen.

Ich weiß das es schwierig ist. Wir sind nicht in diesen Beruf gegangen, weil wir gut mit Menschen umgehen können. Wir kommunizieren am besten mit Code. Das ist gut. Mach es einfach schnell und oft. Zeig mir, warum deins besser ist. Hör zu, wenn ich sage, dass es nicht so ist. Mach das, während ich noch darüber nachdenke. Ich liebe es zu codieren. Es gibt nur wenige Menschen auf dem Planeten, mit denen ich darüber sprechen kann. Sei einer von ihnen.

55
candied_orange

Lassen Sie die Leute zuerst Dinge pflegen, die sie nicht geschrieben haben. Für Entwickler ist es sehr einfach, sich daran zu gewöhnen, Frameworks und Techniken zu verwenden, an die sie gewöhnt sind. Es ist unglaublich, zwischen Frameworks und Methoden wechseln zu müssen. Wenn jemand gezwungen ist, sich außerhalb seiner eigenen Ecke des Codes zu bewegen und dies so oft zu erleben, wird dies zu Beschwerden und hoffentlich zu produktiven Diskussionen führen, die dazu führen können, dass Menschen sich auf etwas standardisieren möchten.

Als nächstes ziehen Sie Anfragen und Codeüberprüfungen. Lassen Sie niemals zu, dass Code ohne vorherige Codeüberprüfung mit Ihren Hauptzweigen zusammengeführt wird. Jeder kann das. Wenn jemand etwas sieht, das anders ist als das, was er getan hätte, kann dies zu Diskussionen und Teamwork führen, um zu einer besseren Lösung zu gelangen. Es macht auch jeden zu einem Verwalter der Codebasis, was (hoffentlich) die Leute dazu bringt, sich um sie und den Status des darin enthaltenen Codes zu kümmern.

Schließlich haben Design-Diskussionen. Sie können formell oder informell sein, haben sie aber. Lassen Sie diejenigen, die teilnehmen möchten, dies tun. Besprechen Sie, welche Frameworks Sie verwenden möchten, welche Vor- und Nachteile Enums und Ints usw. haben. Treffen Sie dann eine Entscheidung und dokumentieren Sie sie irgendwo (wie in einem Standarddokument). Dann müssen Sie auf etwas hinweisen, wenn Probleme auftreten. Haben Sie auch keine Angst, eine Standardentscheidung zu überdenken. Die Technologie ändert sich (schnell) und Ihre Bedürfnisse als Team und als Unternehmen.

Helfen Sie den Menschen zu sehen, was Sie sehen und fühlen, als hätten sie einen Anteil an der Qualität des Codes. Führen Sie dann vorsichtig Diskussionen, um einen Standard zu finden, wenn Meinungsverschiedenheiten auftreten.

23
Becuzz

Führen Sie jedes Mal Codeüberprüfungen durch, wenn jemand Code in den Hauptzweig/die Hauptleitung einbinden möchte, und halten Sie die Benutzer bei der Überprüfung des Codes an diese Standards.

Und ich meine nicht, dass nur Sie die Codeüberprüfungen durchführen sollten. Jeder sollte den Code aller anderen überprüfen. Dies verbreitet das Wissen über das System im gesamten Team, schafft aber auch eine Situation, in der Carol Bobs Code überprüft und sagt: "Ich sehe, dass Sie dort eine Ganzzahl verwendet haben. Ich verwende immer eine Aufzählung." Sie entdecken die Diskrepanzen, die Sie gesehen haben, und wenn sie sich darum kümmern, werden sie erkennen, dass jeder auf die gleiche Seite kommen muss.

Die akzeptierten, vereinbarten Standards werden entstehen. An diesem Punkt dokumentieren Sie sie und stellen sicher, dass die Leute ihnen folgen. Dies würde Dinge wie "Aufzählungen in der Datenbank für ..." usw. einschließen. Sie können auch dokumentieren, welche Frameworks verwendet werden sollen usw.

6
Matthew

Wenn möglich, können Sie Tools/Skripte schreiben, um Ihre Projekte automatisch zu analysieren und festzustellen, welche Standards, Tools und Ansätze das Projekt verwendet. Sie können dies tun, indem Sie ein benutzerdefiniertes Tool als Teil eines CI-Builds ausführen.

Lassen Sie die Ausgabe der Tools in ein "Scorecard" -Dokument schreiben, z. ein Google Sheet mit einer Zeile pro Einheit (z. B. pro 'Anwendung' oder Projekt oder API oder was auch immer) mit Spalten für die verschiedenen Metriken/Standards, die befolgt werden. Dies gibt den Menschen einen Überblick darüber, welche Standards es gibt, wie gut sie angenommen werden usw. und gibt dem Chaos Ordnung.

Sie können Spalten auch manuell aktualisieren lassen, aber viel Glück beim Aktualisieren: D.

1
mcintyre321

Zusätzlich zu den Antworten sollten Sie Ihr Team darüber informieren (- === -), was Sie als Softwareentwickler von dem Moment an erwarten, in dem sie interviewt werden in das Unternehmen eintreten.

1 - Erstellen und befolgen Sie Codebasis-Konventionen

Dies ist eine der grundlegendsten und zugleich vorteilhaftesten Maßnahmen, die Sie zur Verbesserung der Codequalität ergreifen können. Aufgrund der folgenden Konventionen ist der Quellcode in der gesamten Codebasis einheitlich, wodurch der kognitive Aufwand für das Suchen und Lesen von Codedateien verringert wird.

2 - Implementieren Sie klare Softwarearchitekturen

Die Codebasis eines Softwareprojekts, das keinem klaren Architekturstil folgt, verschlechtert sich allmählich, wenn neuer, unstrukturierter Code hinzugefügt wird, der schwieriger zu ändern ist. Daher ist es wichtig, die Stunden für das Design und die Erhaltung einer angemessenen Softwarearchitektur einzuplanen.

3 - Weniger ist besser: Sprachen, Frameworks und Tools

Mit jeder zusätzlichen Sprache, jedem Framework und jedem Tool, die Sie in Ihr System einführen, fallen zusätzliche Entwicklungs- und Betriebskosten an. Sie sollten immer die langfristigen Kosten einer technologischen Entscheidung bewerten, bevor Sie ein kurzfristiges Problem lösen. Vermeiden Sie redundante Technologien und holen Sie das Beste aus Ihrem aktuellen Stack heraus.

4 - Beziehen Sie Ihr Team in Entscheidungen zum Systemdesign ein

Der effektivste Weg, eine gemeinsame Wissensumgebung aufzubauen, besteht darin, das Team in alle Entscheidungen zum Systemdesign einzubeziehen. Die Vorteile sind vielfältig:

  • Einzelpersonen fühlen sich geschätzt und Teil des Teams
  • Wichtige Entscheidungen werden vom gesamten Team angefochten, bevor sie getroffen werden
  • Die Stärken und Schwächen des Systemdesigns werden von allen klarer verstanden
  • Schafft ein Gefühl der kollektiven Rechenschaftspflicht und des Vertrauens

5 - Die All-in-Regel

Ich bin der Ansicht, dass die Bemühungen zur Überarbeitung eines Systemdesigns vollständig (all-in) durchgeführt werden sollten, anstatt teilweise abgeschlossen zu werden. Es besteht ein großes Risiko, dass Ihr Systemdesign beeinträchtigt wird, wenn Entwickler nach Belieben verschiedene Codierungsstile und Architekturmuster lokal anwenden können.

Wenn Sie die vorherigen Vorschläge erfolgreich umgesetzt haben, wird Ihr Team dieses Verhalten von betrügerischen Entwicklern zu diesem Zeitpunkt höchstwahrscheinlich als unprofessionell und verantwortungslos bewerten.


Ich habe kürzlich einen Blog-Beitrag zu diesem Thema geschrieben. Dort finden Sie detaillierte Informationen zu diesen Themen: https://thomasvilhena.com/2019/11/system-design-coherence