Wie kann ich einen anderen Ansatz im Software Engineering erklären als den, der derzeit in Codebase verwendet wird? [Duplikat]

Wo ich arbeite, haben sich die Entwickler jedes Jahr geändert, wobei jeder Entwickler seine eigene Vorgehensweise hinterlässt und danach weitermacht, der Codebasis fehlt die richtige Dokumentation, sie wird nicht im Hinblick auf Leistung oder einfache Migration oder Upgrades entwickelt , konzentrierte sich nur auf die Entwicklung neuer Funktionen und die Behebung von Fehlern.

Was mich in eine unangenehme Lage bringt, der CTO hat sich einmal geändert, und der aktuelle CTO ist der älteste in der Codebasis. Wenn ich etwas vorschlagen oder vorschlagen möchte, muss es durch ihn gehen, ich dachte an viele Dinge, die helfen könnten aus meiner Sicht, habe mich aber seit Beginn meiner Anstellung aus Angst zurückgehalten, dass meine Ideen weit von der Denkweise oder Vorgehensweise des CTO entfernt erscheinen könnten.

Wie würde jemand einen geeigneten und gut durchdachten Ansatz vorschlagen, um dies anzugehen? Mein Ziel ist es, die Codebasis tatsächlich von nodejs 4 auf nodejs 6 zu migrieren, die Anwendungsarchitektur zu überarbeiten und die nosql-Datenbank einzuführen und vielleicht in Zukunft auf micro zu migrieren -Dienstarchitektur.

Was ich suche, ist, wie ich mich meinem CTO nähern kann, um als Team zusammenzukommen und ein skalierbares und neues Technologiesystem auf der alten Einstellung aufzubauen, da ich beabsichtige, während der Migration dabei zu sein und zu sehen, wie dieses Unternehmen aus einer Position heraustritt zum nächsten.

"Oh hallo Mark, könnten wir zu Node.js 6 migrieren? Es würde uns erlauben, dies und das zu tun, während wir jetzt dies und das nicht tun können und einen besser lesbaren Code haben, da jeder Entwickler seinen eigenen Stil hat."
Ihr Hauptproblem ist nicht nodejs4/6, monolith/microservices, sql/nosql. Es ist die Fluktuationsrate, die wirklich hoch erscheint. Die Architektur zu ändern, während sich die Entwickler immer wieder ändern, wird nicht viel ändern.
Es scheint so, ja, und Ihr Punkt ist gültig, mein Teamkollege, der hier im letzten Jahr gearbeitet hat und viele neue Komponenten gebaut hat, wird sehr bald gehen, sollte mich das davon abhalten, einen anderen Ansatz als die vorherigen Entwickler zu verfolgen. oder einfach ihr Vermächtnis weiterführen, was für mich nicht cool ist
Haben Sie Grund zu der Annahme, dass Ihr CTO für Ihre Pläne nicht aufgeschlossen wäre? Sie scheinen davon auszugehen, dass er sich allein aufgrund seines Alters gegen Veränderungen wehren wird, was eine eher stereotype und grenzwertig anstößige Annahme ist.
Ich habe nichts über sein Alter erwähnt, ich habe den Ältesten in der Codebasis erwähnt (am erfahrensten), aber ich habe mich trotzdem an ihn gewandt, ohne in bestimmten Fällen, in denen wir Mongodb verwenden könnten, er hat sich dagegen gewehrt, weil AWS nicht auf RDS eingeführt wurde Zum Beispiel habe ich mich wegen eines Upgrades von node.js gemeldet, in der Antwort ging es um instabile npm-Pakete, die möglicherweise neue Fehler in neueren Funktionen einführen, weshalb die Codebasis gesperrt ist
Haben Sie eigentlich Gründe, all diese neuen Technologien einzuführen? Wenn das, was da ist, stabil, funktionsfähig und leistungsfähig ist, dann ist es ziemlich willkürlich und sinnlos (Upgrades beiseite).
Was ich erwähne, ist nicht wirklich neu, es ist mehr von heute und ja, viele Probleme, die durch diese technischen Upgrades in unserem aktuellen Kontext gelöst werden können

Antworten (3)

Eigentlich enthält Ihr Beitrag zwei Probleme.

Problem A

... der Codebasis mangelt es an angemessener Dokumentation, sie wurde nicht mit Blick auf Leistung oder einfache Migration entwickelt, Upgrades im Hinterkopf, sie konzentriert sich nur auf die Entwicklung neuer Funktionen und die Behebung von Fehlern.

Das erste Problem hängt mit den Entwicklern selbst zusammen. Dies wird nicht durch ein Upgrade von NodeJS oder die Verwendung einer NoSQL-Datenbank gelöst.

Was zu tun ist

Das Team muss einige spezifische Regeln haben, die jeder Entwickler beim Codieren anwenden muss. Diese Regeln sollten gemeinsam oder mit einem kleinen Teil des Teams erstellt werden. Sprechen Sie mit Ihrem Vorgesetzten und bitten Sie ihn, ein Treffen mit dem gesamten Team zu organisieren. Dies wird einige Zeit in Anspruch nehmen.

ProblemB

... mein Ziel ist es, die Codebasis tatsächlich von nodejs 4 auf nodejs 6 zu migrieren, die Anwendungsarchitektur zu überarbeiten und eine nosql-Datenbank einzuführen und vielleicht in Zukunft auf eine Microservice-Architektur zu migrieren.

Das können je nach Projekt und Bedarf gute Ideen sein. Zum CTO zu kommen und zu sagen "Hey, wir sollten nodeJS komplett aktualisieren und die Datenbank ändern" wird nicht funktionieren. Die Antwort wird wahrscheinlich lauten "Dafür haben wir keine Zeit" .

Was zu tun ist

Finden Sie das Warum? . Warum sollten Sie NodeJS aktualisieren? Wird es die Geschwindigkeit der Anwendung verbessern und somit zu einer besseren Kundenzufriedenheit führen?

Für jeden Vorschlag müssen Sie eine Erklärung haben und Ihrem CTO zeigen, dass diese Änderungen dem Team/Kunden/Unternehmen einen Vorteil bringen können.

Wenn Ihre Ideen und Erklärungen aufgelistet und strukturiert sind, können Sie den CTO treffen und mit ihm sprechen.

Ich bin nicht auf die Einzelheiten der Vorteile jeder vorgeschlagenen Änderung eingegangen oder wie sie die Situation beheben oder ändern würde. Meine Hauptherausforderung besteht nicht darin, Probleme im Vergleich zu Lösungen zu finden oder sie zu strukturieren und aufzulisten. Es geht darum, sich einer Mentalität zu nähern, die sich seit geraumer Zeit auf eine bestimmte Strategie in der Entwicklung stützte, und was ich vorstellen möchte, ist ein technischer Ansatz für ein messbares Computerproblem, und die Herausforderung für mich besteht darin, wie ich Menschen dazu bringen kann, unser eigenes internes zu entwickeln Strategie, deshalb neige ich eher dazu, mich auf die Lösung von Problem A zu konzentrieren

Im Grunde versuchen Sie hier, Ihre Idee an den CTO zu verkaufen. Damit das funktioniert, muss man verstehen, was der CTO langfristig erreichen will.

Was Sie vorschlagen, erscheint Ihnen wie Verbesserungen, aber sie sind mit Kosten und Risiken verbunden. Die Kosten sind die Verfügbarkeit und Zeit der Entwickler, und die Risiken hängen mit Systemausfallzeiten, der Migration selbst und völlig kaputten Dingen zusammen.

Sie müssen den Nutzen einer neuen Architektur gegen das Risiko und die Kosten abwägen, denn genau das wird er tun. Hier kommt Ihr Wissen ins Spiel. Damit er alles akzeptiert, müssen Sie ihn davon überzeugen, dass die Verbesserungen die Entwicklerzeit und mögliche Risiken wert sind. Jetzt und in Zukunft.

Realisieren...

migrieren Sie die Codebasis von nodejs 4 auf nodejs 6, überarbeiten Sie die Anwendungsarchitektur und führen Sie die nosql-Datenbank ein und migrieren Sie vielleicht in der Zukunft auf die Microservice-Architektur

„nur weil“ kann leicht und wahrscheinlich zu Recht als bloßer Beitrag zum Problem wahrgenommen werden.

Was Sie fragen, ist jedoch so ungewöhnlich. Was Sie zuerst tun müssen, ist, den CIO um einige Zeit zu bitten, einen Plan zu entwickeln, um die App um einige vorhersehbare und gängige Muster und APIs herum auszurichten ... die möglicherweise nicht die ausgefallenen neuen Dinge enthalten ... Realistisch gesehen, Konsolidierung um das, was bereits vorhanden ist am häufigsten verwendet wird, bringt Ihnen und dem CIO den größten Nutzen bei geringstem Aufwand.

Wie kann ich einen anderen Ansatz im Software Engineering erklären als den, der derzeit in Codebase verwendet wird? [Duplikat]
AntwortenHierDatenschutz-Bestimmungen1y, 0v