Wie kann die Konsistenz in der Anwendungsarchitektur aufrechterhalten werden, wenn das 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.

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

Wie kann ich die Konsistenz durchsetzen? 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 für mich unrealistisch, solche Standards zu erwarten? Ich kämpfe mit der Idee, als Diktator zu wirken, der die Kreativität unterdrückt, aber das zu tun, was sie wollen, scheint nicht skalierbar zu sein.

Was macht dich so besonders?

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

Sie können mit dieser Einstellung umgehen, indem Sie jeden dazu zwingen, Pull-Anfragen zu stellen. Aber jetzt stehen die Fristen vor der Tür. Schlechter Code drückt auf die Tore deines unberührten Schlosses und du gibst endlich dem Druck nach. Oder du gewinnst nur, um zu finden, dass alle gehen und niemand deine unberührte Burg 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ühzeitig 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, dass ich das zulasse.

Aus welchem ​​Grund auch immer Sie Dinge haben, 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 Kodierung jedes Moduls klar kommunizieren.

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

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

Reduzieren Sie die Dinge, die Sie interessieren, auf die zugrunde liegenden Prinzipien. Anstatt mir eine Liste mit 101 zu befolgenden Regeln vorzulegen, geben Sie mir die 10 Grundsätze, gegen die sie verstoßen, damit ich selbst herausfinden kann, welche Regel 102 gelten soll.

Ermächtige mich, meine eigene Vision durchzusetzen, indem du mir hilfst, deine zu sehen, und wir kommen großartig miteinander aus.

ist es für mich unrealistisch, solche standards zu erwarten? Ich kämpfe mit der Idee, als Diktator zu wirken, der die Kreativität unterdrückt, aber das zu tun, was sie wollen, scheint nicht skalierbar zu sein.

Dann diktieren Sie nicht! Machen Sie dies zu einer positiven Erfahrung. Das ist kein New-Age-Hippie-Quatsch. Es ist Grundpsychologie. Sie versuchen, das menschliche Verhalten zu ändern. Zufällig und positiv ist die Verstärkung (fragen Sie einfach Las Vegas). Wenn Sie negativ werden, müssen Sie mit Ihrer Verstärkung im Einklang stehen. Das ist ein unerreichbarer Schmerz. Seien Sie positiv, wenn Sie die Weisheit verbreiten, und Sie können beiläufig sein.

Ich weiß, woher du kommst, weil ich dort war. Sie hatten die Kontrolle und jetzt ist es weg. Du willst es zurück. Na 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. Meistern Sie das und entspannen Sie sich. 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. Betreue die Neulinge und ermutige sie, sich zu verbessern und auch andere zu beeinflussen.

Ich weiß dass es hart ist. Wir haben diesen Beruf nicht ausgeübt, 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. Tun Sie dies, 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.

Lassen Sie zuerst die Leute Dinge pflegen, die sie nicht geschrieben haben. Für Entwickler ist es sehr einfach, sich daran zu gewöhnen, gewohnte Frameworks und Techniken zu verwenden. Es macht Spaß, zwischen Frameworks und Methoden wechseln zu müssen. Wenn jemand gezwungen ist, sich außerhalb seiner eigenen Ecke des Codes zu bewegen und dies häufig zu erleben, wird dies zu einigen Beschwerden und hoffentlich zu einer produktiven Diskussion führen, die dazu führen kann, dass Menschen sich auf etwas standardisieren wollen.

Ziehen Sie als Nächstes Anforderungen und Codeüberprüfungen ab. Lassen Sie niemals zu, dass Code ohne vorherige Codeüberprüfung mit Ihren Hauptniederlassungen 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 Teamarbeit führen, um eine bessere Lösung zu finden. Es macht auch jeden zum Verwalter der Codebasis, was die Leute (hoffentlich) dazu bringt, sich darum und um den Zustand des Codes zu kümmern, der in die Codebasis einfließt.

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 vs. Ints usw. 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 Normungsentscheidung erneut zu treffen. Die Technologie ändert sich (schnell), ebenso wie 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. Dann treiben Sie die Diskussionen sanft voran, um einen Standard zu finden, wenn Meinungsverschiedenheiten auftauchen.

Führen Sie Codeüberprüfungen jedes Mal durch, wenn jemand Code in die Hauptniederlassung / den Hauptstrang einbinden möchte, und halten Sie die Leute bei der Überprüfung des Codes an diesen Standards fest.

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, führt aber auch dazu, dass Carol Bobs Code überprüft und sagt: "Ich sehe, dass Sie dort eine Ganzzahl verwendet haben. Ich verwende immer eine Enumeration." Sie entdecken die Diskrepanzen, die Sie gesehen haben, und wenn sie sich darum kümmern, werden sie feststellen, dass jeder auf die gleiche Seite kommen muss.

Die akzeptierten, vereinbarten Standards entstehen, an welchem ​​Punkt Sie sie dokumentieren und sicherstellen, dass die Leute ihnen folgen. Dies würde Dinge wie "Aufzählungen in der DB für ..." usw. beinhalten. Sie können auch dokumentieren, welche Frameworks verwendet werden sollen usw.

Wo immer 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. B. ein Google Sheet mit einer Zeile pro Einheit (z. B. pro' Anwendung 'oder Projekt oder API oder was auch immer), wobei Spalten für die verschiedenen Metriken / Standards befolgt werden. Dies gibt den Menschen einen Überblick darüber, welche Standards es gibt, wie gut sie angenommen sind usw. und bringt Ordnung in das Chaos.

Sie können Spalten auch manuell aktualisieren lassen, aber wir wünschen Ihnen viel Glück, dass Sie auf dem neuesten Stand sind: D