Kampf gegen (wahrgenommene) Überentwicklung versus mit dem Fluss gehen [geschlossen]

Ich bin einem Team beigetreten, das einen anderen Designansatz hat als ich. Ich glaube an den YAGNI-Designansatz. Wenn beispielsweise eine Methode (Schnittstelle, Klasse) nicht verwendet wird, muss sie entfernt werden. Das ist es.

Die Leute in meinem Team bauen eine modulare App, und eines der Module wird als "Framework" wahrgenommen. Die App ist der einzige Benutzer dieses Frameworks, und es gibt derzeit keine Pläne, mehr Clients zu haben. Teile des Codes in diesem Framework werden jedoch so geschrieben und verwaltet, als ob sie später verwendet werden könnten , und Konsistenz und Vollständigkeit überzeugen YAGNI. Es gibt Abstraktionen an Orten, die möglicherweise niemals Abstraktionen usw. benötigen.

Ich habe versucht, ein paar Dinge weg zu argumentieren, aber jeder Punkt braucht viel Zeit, um zu überzeugen, wenn überhaupt, und ich befürchte, dass zu viel "Drücken" dazu führt, dass das Team in entgegengesetzte Seiten zerfällt.

Ich kann "mit dem Fluss gehen" und zusätzlichen Code ohne persönliche Probleme schreiben. Es wird mir mehr Zeit , um Code, und höchstwahrscheinlich, später mehr Zeit zu halten , aber , jede Diskussion nicht etwas tut Extra auch Zeit in Anspruch nimmt und fügt Druck.

Die Frage ist, was bei unterschiedlichen Meinungen einen größeren Nachteil, unnötigen, aber "richtigen" Code oder ständige Argumente und eine gebrochene Teamdynamik bewirkt.

Die Aufrechterhaltung eines imaginären Rahmens ist eine architektonisch wichtige Entscheidung. Die Frage lautet daher: „Wie kommen wir auf die Idee und entwickeln sie weiter?“ Im Team. Sie müssen mit klar definierten Entscheidungsregeln beginnen, die klar sind und von allen im Team akzeptiert werden, da es kein Spiel ohne die Regeln gibt .

Wenn Sie in das Unternehmen eintreten, ist eine der wichtigsten Fragen, die Sie jemals stellen könnten, Folgendes:

Wie funktioniert der Entscheidungsprozess im Team und wie entwickelt er sich im Laufe der Zeit?

Kein Entscheidungsprozess ist schlechter als ein schlechter Entscheidungsprozess. Wenn es keinen Prozess gibt, muss jemand einen definieren. Andernfalls wächst die Menge an Unsinn zusammen mit der Menge an Meinungsverschiedenheiten mit dem Team.

Ich denke, damit schließen wir den Kreis - entweder haben Sie die Autorität und Befugnis, den Entscheidungsprozess zu definieren, wenn er fehlt, oder Sie stimmen dem aktuellen Prozess zu / und wie er sich entwickelt. Wähle ein.

Ständige Argumente und eine gebrochene Teamdynamik werden Sie nie weit bringen.

Ich würde versuchen zu verstehen, warum es überhaupt einen Rahmen gibt.

Der Grund ist höchstwahrscheinlich, dass erwartet wird, dass es später in anderen Systemen verwendet wird. Wenn dies der Fall ist, ist es sinnvoll, mehr zu tun, als derzeit erforderlich ist.

Der Grund dafür ist, dass wenn eine App in Produktion ist und eine neue App ausgeführt wird, die Aktualisierungen des Frameworks erfordert. Jedes Mal, wenn etwas im Framework geändert wird, möglicherweise Abstraktionen hinzugefügt werden, die zuvor nicht benötigt wurden, muss die ursprüngliche App aktualisiert werden und auch getestet.

Das ist eine Menge Refactoring und Retesting für etwas in der Produktion.

Wenn Sie das aktualisierte Framework nicht in die alte App aufnehmen möchten, müssen Sie zwei Frameworks verwalten, von denen eines bereits veraltet ist.

Die Pflege veralteten Codes ist auch für die Moral nicht sehr gut.

Wenn Sie neu in einem Team sind, sollte es Ihr erstes Anliegen sein , nicht zu versuchen, die Streitkräfte zu stören.

Ich gehe davon aus, dass Sie nicht in einer leitenden / Architektenposition sind und die Entscheidungen nicht bei Ihnen liegen.

Das zweite Problem ist Lernen . Eine Menge lernen. Erfahren Sie, warum sie die Entscheidungen getroffen haben, warum der Rahmen geschaffen wurde, was der Grund dafür ist. Wenn Sie über alle Informationen verfügen, können Sie eine fundierte Entscheidung darüber treffen, wie mögliche Probleme wie Überentwicklung und schlechte Kommunikation angegangen werden sollen.

Stellen Sie höflich Fragen . Versetzen Sie sich in die Position eines Schülers und nicht eines Meisters. Es wird den Leuten leichter fallen, Ihnen "beizubringen", warum sie die Dinge so gemacht haben.

Im Moment bist du der Ausgestoßene. Sie treten einem ausländischen Team bei, und Sie sollten dessen Bräuche lernen und sich anpassen.

Wenn Sie Ihre Arbeit richtig machen und höflich mit Menschen umgehen, werden die Menschen Ihnen im Laufe der Zeit natürlich zuhören. Und wenn Sie absolut Recht haben, dass Ihr Ansatz der beste insgesamt ist, können Sie die Menschen dazu bringen, sich zu ändern.

Ich habe kaum jemanden gekannt, der gerne mit einer Person arbeitet, die oft kritisiert, aber keinen Wert generiert. Seien Sie ein Hinweis auf Ihr Team, jemanden, mit dem sie stolz zusammenarbeiten können.

Empfohlene Lektüre: https://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034

Es gibt zwei grundlegende Dinge, von denen ich denke, dass sie passieren. Der erste ist kulturell. Sie sind neu im Team und haben noch nicht ganz herausgefunden, wie Sie mit diesem Team arbeiten sollen. Sie haben wahrscheinlich unterschiedliche Richtlinien und Praktiken, die möglicherweise tatsächlich für sie funktionieren. Möglicherweise haben sich auch einer oder mehrere von ihnen für Ihre Position beworben, sodass sie Ihre Bemühungen möglicherweise aktiv sabotieren oder Ihnen einfach nicht sagen, was Sie wissen müssen.

Das zweite ist, dass Sie möglicherweise das Design falsch verstanden haben. Der Teil, den Sie für toten Code halten, kann tatsächlich eine Verallgemeinerung anderer Teile des Entwurfs sein oder auf die Unterstützung von etwas hinarbeiten, das das Unternehmen eventuell unterstützen möchte. Es kann tatsächlich toter Code sein. Hör auf, davon besessen zu sein und verstehe, warum es da ist. Es kann tatsächlich Monate dauern, um herauszufinden.

In risikoaversen Branchen (z. B. Bankwesen, Medienwesen ...), in denen die geringe Wahrscheinlichkeit besteht, dass ein Codeabschnitt verwendet wird, bleibt dieser Codeabschnitt jahrzehntelang bestehen.

Um dies hervorzuheben, konzentrierte sich eine der fremden Datenbankstrukturen, die ich gesehen habe, auf 6 Tabellen. 3 von ihnen waren Mapping-Tabellen, die die anderen drei verbanden. Es ergab keinen Sinn, da der Code darauf hinwies, dass nur eine von ihnen als Viele-zu-Viele-Beziehung verwendet wurde und die anderen beiden Eins-zu-Viele-Beziehungen implementierten. Die ursprünglichen Designer waren gegangen und niemand konnte genau erklären, wie oder warum es funktionierte. Schließlich stieß ich auf ein Geschäftsdokument, in dem das Design erläutert wurde. Ich vermutete also, dass das Unternehmen danach gefragt hatte und einige DBAs nur so implementiert wurden, dass das Unternehmen sie verstehen konnte - trotz seiner offensichtlichen Einschränkungen. 30 Jahre später ist es immer noch da und verdient dem Unternehmen Geld - aber aus entwicklungspolitischer Sicht schwer zu verstehen, zu pflegen und weiterzuentwickeln.

Ich sehe einige gute Punkte darin, ein solches Stück aus der Anwendung zu entfernen, auch wenn es sonst niemand verwendet.

Dies kann die Entwicklung technischer Funktionen im Rahmen mit ihren richtigen Tests außerhalb des Funktionskontexts der Anwendung (und auf ihrer eigenen Roadmap) erzwingen.

Darüber hinaus ist es möglich, dass nicht jeder Entwickler dieses Framework berühren soll, sondern nur die meisten Senioren. Daher ist es von Vorteil, es wieder außerhalb der Anwendung zu installieren.

Ändern Sie für die nicht benötigten Abstraktionsschichten nichts, was bereits funktioniert, wenn sie bereits vorhanden sind.

Sie können sich jedoch für die Zukunft an Ihr Team erinnern, dass das Ziel des Frameworks darin besteht, Ihre Arbeit zu erleichtern, nicht zu verbessern.

Ich lese zwischen den Zeilen und neige mich zu Ihren Co-Teammitgliedern. Etwas "komplizierter als nötig" zu machen, ebnet nicht nur den Weg für mögliche zukünftige Funktionen, die möglicherweise nie benötigt werden, sondern dient auch dem Verständnis des Entwicklers für die Anwendung, es integriert ein Modell in die Software, es dokumentiert eine Idee.

Auf diese Weise wird die zukünftige Entwicklung eingeschränkt. Es verhindert, dass Entwickler, die das Design / die Absicht nicht vollständig erfassen, vom Weg abkommen.

Ein neuer Entwickler mag sich zunächst über das "unnötig komplizierte" Design ärgern, aber es führt ihn auch in die richtige Richtung, es lässt ihn in die Grube des Erfolgs fallen und macht es ihm schwerer, "Dinge auf seine Weise zu tun", was Dies wäre nur ein anderer Weg, der die Dinge wirklich komplizieren würde, da dies zu unterschiedlichen Ansätzen in derselben Anwendung führen würde, was es für den nächsten Mann noch schwieriger macht, sich darum zu kümmern.

YAGNI bedeutet nicht (oder sollte nicht) "Sie können das Design überspringen" oder "schnell und schmutzig machen". Wenn Ihr Team den Luxus hat, über Dinge nachzudenken, würde ich sagen, dass dies eher zu schätzen als zu kämpfen ist.