Starten einer kohärenten Architektur in einer Legacy-Anwendung

Ich bin verantwortlich für eine große Asp.Net-basierte Website. Derzeit handelt es sich um eine Website (keine Webanwendung), einige Windows-Dienste und eine Reihe von Klassenbibliotheken.

Die Datenschicht verwendet eine Mischung aus LLBLGEN und Linq To LLBGen sowie eine Reihe von Instanzen von Legacy-Inline-SQL, die nicht überarbeitet wurden.

Es gibt einige Implementierungen vom Typ Manager, aber in vielen Fällen weist die Anwendung das Anti-Pattern für die intelligente Benutzeroberfläche auf (dh zu viel Geschäftslogik im Code hinter Klassen).

Die Website ist relativ stark frequentiert und die Leistung ist in Ordnung, aber wir erweitern unsere Entwicklungskapazität auf ein Team von etwa 10 Mitarbeitern. Zunehmend wird klar, dass wir ein übergreifendes mehrschichtiges Design zusätzlich zur vorhandenen Middleware benötigen.

Meine Frage ist, wo ich anfangen soll? Wir haben 10 Jahre Code (einige davon sind noch immer nur mit ASP Classic migriert), viele verschiedene Ansätze und Stile.

Das Refactoring der gesamten Codebasis ist nicht realistisch und wahrscheinlich nicht wünschenswert

Ich weiß, dass dies keine neuartige Situation ist. Gibt es nützliche Ideen oder Konzepte, wie man dieses Problem angehen kann?

Ich habe auch in ähnlichen Situationen gearbeitet und kann Ihnen den folgenden Rat geben.

1. Sie müssen die technische Verschuldung reduzieren . Jetzt. Warum? Weil technische Schulden wie finanzielle Schulden sind. Sie werden Zinsen dafür zahlen.
2. Da eine Umgestaltung der gesamten Codebasis nicht möglich ist, fragen Sie sich: Was verhindert dies? Ist es einfach zu viel Arbeit? Warum?
3. Erstellen Sie einen Plan, um die technische Verschuldung rechtzeitig zu reduzieren. Zum Beispiel durch das Einrichten von Regeln als " jedes Codebit, das vom Team berührt wird, muss nach dem neuen Standard repariert / überarbeitet werden ". Typischerweise müssen Komponententests geschrieben, Code in die richtigen Ebenen verschoben werden usw. Auf diese Weise können Sie viel Code reparieren, ohne auf lächerlich teure und kostengünstige "Refactoring" -Projekte zurückgreifen zu müssen.
4. Wickeln Sie den Mist. Entkopplung ist der Schlüssel zu Refactoring und guter Architektur. Wenn Sie die Codebasis irgendwie partitionieren können, können Sie möglicherweise kleinere Bits umgestalten.
5. Erhöhen Sie die technische Verschuldung nicht weiter. Erhöhen Sie die technische Verschuldung nicht weiter. Erhöhen Sie die technische Verschuldung nicht weiter. Unterlassen Sie...

Sie haben Recht, dass eine Umgestaltung der gesamten Codebasis nicht wünschenswert ist. Refactoring ist etwas, das Sie vor der Neuentwicklung tun, um diese Entwicklung reibungsloser zu gestalten. Wenn Sie nicht vorhaben, den gesamten Code in Ihrer Codebasis zu ändern, wird sich durch Refactoring eine ineffiziente Zeitnutzung herausstellen.

Einige Ratschläge zusätzlich zu dem, was Sklivvz sagt:

1. Teilen Sie den Code in häufig und selten geänderte Abschnitte auf. Nur die häufig geänderten Abschnitte müssen vollständig in die neue Architektur integriert werden. Integrieren Sie den selten geänderten Code mit so wenig Änderungen wie möglich in die neue Architektur (oder ohne Änderungen, wenn Sie damit durchkommen können). Widerstehen Sie der Versuchung des vollständigen Umschreibens, es kostet mehr, als Sie davon profitieren. Schätzen Sie, dass der vorhandene Code funktioniert, auch wenn er hässlich ist.

2. Finden Sie heraus, was Ihr Refactoring-Ziel ist. Möchten Sie es einfacher machen, Inhalte auf die Website zu bringen? Haben Sie viele Fehler und möchten die vom Benutzer wahrgenommene Qualität verbessern? Möchten Sie stattdessen die Entwicklungszeit für Features reduzieren? Oder möchten Sie hauptsächlich eine bessere UX? Ihre Architektur sollte es einfach machen, Code umzugestalten, um die von Ihnen festgelegten Ziele zu erreichen. Vergessen Sie niemals, dass der Hauptnutznießer Ihres Refactorings Ihr Benutzer / Kunde / Unternehmen sein sollte. Saubererer Code ist kein Ziel an sich, sondern eine Methode zum Zweck, und am Ende ist ein Benutzer beteiligt.

3. Versuchen Sie, so viele Referenzarchitekturen wie möglich zu finden, und haben Sie keine Angst, sie zu kopieren. Das Rad nicht neu erfinden. Wenn jemand anderes eine Architektur hat, die für Websites wie Ihre gut funktioniert, lernen Sie von ihm.

4. Denken Sie an die Personalverwaltung. In meinen eigenen Migrationsprojekten war es am schwierigsten, die Menschen dazu zu bringen, die neuen Wege zu lernen und sich an sie zu halten. Sie benötigen Referenzimplementierungen und eine Möglichkeit, die Architektur allen Teammitgliedern (sowohl alten als auch neuen) beizubringen. Um den Widerstand gegen Veränderungen zu verringern, bitten Sie alle Mitglieder des Teams um Input, bevor Sie Entscheidungen treffen. Stellen Sie sicher, dass das neue Design die Dinge aus der persönlichen Perspektive der Entwickler tatsächlich verbessert und kein so großer Sprung ist, dass sie sich überfordert fühlen.

Das Wichtigste, was ich beim Versuch gesehen habe, mit einer alten Codebasis umzugehen, ist, NICHT ständig zu ändern, wofür Sie fotografieren. Das heißt, finden Sie Ihre gewünschte Architektur heraus und bleiben Sie dann bei diesem Plan! Eines der großen Probleme meiner letzten Position war, dass die Codebasis verschiedene Vorstellungen davon hatte, wie sie im Laufe der Zeit aussehen sollte. Jedes Mal, wenn eine neue Idee ausprobiert wurde, wurde ein Teil des Codes konvertiert, ein anderer Teil nicht, und dann hatte jemand anderes eine „bessere“ Idee. Es wurde im Laufe der Zeit immer inkohärenter und wurde schließlich verschrottet.

Es gibt ein wirklich schönes kostenloses Buch / PDF über das Reengineering von Legacy-Software: http://scg.unibe.ch/download/oorp/

Im Titel steht OO, aber die meisten Ideen gelten für jede Software. Es wird erläutert, wo Sie anfangen sollen, wie Sie während der Umstrukturierung mit verschiedenen Teilen eines Systems umgehen sollen und vieles mehr.

Wenn es keine kohärente Architektur hat, liegt es daran, dass das Management das Problem nicht versteht / sich nicht darum kümmert. Einfach weg codieren. Sie sollten eine neue gute Architektur einführen, wenn Sie neuen Code schreiben.

Sie sollten Dinge nur dann neu entwerfen, wenn sie wirklich schwerwiegende Fehler aufweisen. Sie müssen sie erweitern und können sie einfach nicht oder sie entsprechen einfach nicht den Anforderungen.

Ich sage im Grunde nur, dass Sie sich um Themen kümmern, die Ihre Manager tatsächlich interessieren, und nicht um Themen, die sie interessieren würden, wenn sie Ihr Wissen hätten.

Wenn Sie eine Neuarchitektur an das Management verkaufen können, beginnen Sie mit dem Testen. Wenn sie nicht in Tests investieren möchten, werden Ihre Bemühungen Ihnen nur Ärger bereiten.