Bei dieser Frage geht es um die Bewertung des Kosten-Nutzen-Verhältnisses oder des ROI eines potenziellen Projekts.
Ich arbeite in einem 6-8 Jahre alten Softwareprojekt. Es hat viele Probleme und auch Misserfolge sowie einige gescheiterte Leute auf seinem Weg. Gerade jetzt, nachdem das Projekt (die Softwareanwendung) von den Toten auferweckt wurde, suchen die Entwickler, wenn die neue Anforderung kommt, im Code (nicht in den Arbeitsfunktionen in Bezug auf die Verwendung) nach dem entsprechenden Code. Es gibt Ideen zum Erstellen, Umschreiben des Projekts von Anfang an. Ich frage mich, ob es aus Ihrer Sicht sinnvoll ist, im alten Code etwas zu suchen, das der neuen Anforderung für die aktuelle Anwendung entspricht? Denn wenn es anders ist, dann wenden sich die Entwickler an den Anforderer, beschreiben, was sie im Code gefunden haben, und besprechen erneut die Anforderung.
Auf der einen Seite fördert es das Requirements Engineering und den Anforderungserfassungsprozess, auf der anderen Seite kann es Verschwendung oder unnötige Zeitverlängerung sein. Weil es besser und schneller sein kann, mit dem neuen Code für das neue Feature von vorne anzufangen. Und vor allem, wenn das neue System oder das Umschreiben des Systems der Fall sein kann.
Auch wenn es Meinungen zu diesem Thema gibt, wäre es hilfreich, eine Methodik zu finden, damit ich empfehlen könnte, ob die Beteiligten besser dran sind, weiterhin in den alten Code zu investieren oder von Grund auf neu zu erstellen?
Ihre Frage ist ziemlich komplex und lässt sich nicht eindeutig beantworten. Angesichts der Vieldeutigkeit der Probleme, die Ihre Frage aufwirft, werden Sie feststellen, dass die meisten StackoverFlow-Teilnehmer dazu neigen, sie als meinungsbasiert abzutun. Trotzdem ist die Frage eine echte Frage, die meiner Meinung nach eine Antwort verdient.
Der Legacy-Code ist den Programmierern, die ihn geschrieben haben, vertraut, sodass sie dort natürlich zuerst nach neuen Anforderungen suchen werden. Dem Anforderer ist es wahrscheinlich egal, wie die Aufgabe ausgeführt wird, aber er neigt dazu, den vorhandenen Code zu reparieren. Wenn sie nicht wissen, wie Code geschrieben ist und funktioniert, werden sie der Ansicht sein, dass eine Reparatur immer schneller und billiger wäre als ein Austausch. Je nach neuen Anforderungen ist das oft der Fall.
Die Zunahme von Patches im Laufe der Zeit kann jedoch zu technischen Schulden führen , die nicht nur die Verbesserung der Anwendung gefährden, sondern auch ihre Leistung beeinträchtigen können. Siehe Arbeiten von Martin Fowler, Ward Cunniham und Steve Mconnell, insbesondere dessen Webinar „ Managing Technical Debt“ .
Darüber hinaus kann das Aufkommen neuer Sprachen und Frameworks zu effektiveren, sichereren und/oder effizienteren Lösungen führen. Der Wechsel zu diesen neuen Ansätzen kann je nach Persönlichkeit des Entwicklers als willkommene Herausforderung oder schreckliche Idee angesehen werden. Ich würde ein paar Zielanwendungsarchitekturen identifizieren und die Vorteile, Nachteile und interessanten Punkte (die nicht in eine der beiden Kategorien fallen) aufzeigen.
The Mythical Man-Month: Essays on Software Engineering von Fred Brooks ist ein klassisches Buch über Software-Engineering, das einen Überblick über diese Probleme bietet. Suchen Sie nach „ dem zweiten Systemeffekt “.
Bitte durchsuchen Sie https://stackoverflow.com/ und https://softwareengineering.stackexchange.com/ nach relevanten Einträgen.
Todd A. Jacobs
Wahrheitssucher
Todd A. Jacobs