Refactoring vs. Rewrite: Wann sollten Sie Ihren Code überarbeiten oder neu schreiben?

Es gibt Szenarien, in denen Kunden mit einem bestehenden Quellcode zur Überarbeitung kommen, weil er viele Fehler hat und nicht effizient läuft, eine Situation, in der der Kunde beschließt, das Team der Softwareentwickler zu wechseln, oder vielleicht hat der Kunde einen Wunsch, einige Funktionen hinzuzufügen oder braucht einige Optimierungen auf seiner Website/Anwendung.

Es könnte ein Dilemma entstehen, bei dem die neue Agentur oder der neue Entwickler abwägen muss, ob er Refactor-Techniken anwenden oder den Code neu schreiben soll. Beide Möglichkeiten scheinen möglich zu sein und haben sich bei verschiedenen Gelegenheiten als die beste Lösung erwiesen. Nun stellt sich die Frage, in welcher Situation ein Entwickler oder eine Agentur entscheiden kann, ob er/sie Refactoring oder Neuschreiben des Codes durchführen soll. Denn es könnte katastrophale Folgen haben, wenn ein Entwickler beschließt, den Code zu refaktorisieren, während es besser ist, die Anwendung neu zu schreiben und umgekehrt.

In diesem Artikel werden wir kurz die Umstände erörtern, unter denen Sie entscheiden können, ob Sie Ihren Code refaktorisieren oder neu schreiben sollten. Folgen Sie mir, wenn wir uns beide Szenarien ansehen.

Anwendung umschreiben:

Viele Entwickler entscheiden sich dafür, den Code von Grund auf neu zu schreiben, da sie glauben, dass das Schreiben einfacher ist als das Lesen von Code. Sie könnten sich Gründe einfallen lassen, warum sie sich für das Umschreiben entschieden haben, was eigentlich vernünftig ist.

Diese Gründe könnten sein:

• sie können die Codes nicht verstehen

• die Fehlersuche wird immer schwieriger

• neue Codes können aktuelle Probleme beheben usw.

Wenn Sie sich dafür entscheiden, den Code von Grund auf neu zu schreiben, müssen Sie einige Faktoren berücksichtigen: Zeitfaktor: Es liegt auf der Hand, dass Sie viel mehr Zeit benötigen als der erste Entwickler, da Sie über viel mehr Informationen verfügen. Dies könnte zu Unzufriedenheit beim Kunden und bei den Nutzern führen.

• Zeitfaktor: Es liegt auf der Hand, dass Sie viel mehr Zeit benötigen werden als der erste Entwickler, da Sie über viel mehr Informationen verfügen. Dies könnte zu Unzufriedenheit beim Kunden und bei den Benutzern führen.
• Neue Innovation: Während Sie mehr Zeit damit verbringen, die App neu zu entwickeln, kommen neue Innovationen auf den Markt und die Konkurrenten der Kunden drängen darauf, gleichzuziehen. Dies könnte dazu führen, dass die Kunden Nutzer verlieren.
• Kundenzufriedenheit: Dies kann dazu führen, dass die Benutzer frustriert sind. Bestehende Nutzer werden Upgrades vorziehen oder neue Funktionen hinzufügen. Die Zufriedenheit der Nutzer muss bei der Gründung eines Unternehmens an erster Stelle stehen, und alles, was daran etwas ändern könnte, sollte vermieden werden.

Was ist Refactoring?

Code-Refactoring-Techniken sind einfach die Methodik der Umstrukturierung von bestehendem Code, ohne die Kernfunktionalität der Anwendung zu verändern. Oft können die meisten Probleme oder Fehler durch einfache kleine Änderungen behoben werden. Es ist in der Regel schwierig, an dem Code eines anderen zu arbeiten, aber das macht es nicht unmöglich. Das Refactoring des Codes nimmt oft mehr Zeit in Anspruch, aber es hilft Ihnen dabei, den Überblick zu behalten und Ihre Benutzer in Erwartung von Upgrades zu halten, es reduziert die Frustrationsrate auf der Benutzerseite. Das zeigt, dass das Risiko, Ihre Nutzer zu verlieren, gering ist. Es hilft Ihnen, Feedback zu erhalten und schrittweise an ihnen zu arbeiten.

Hier in Sloboda Studio hatten wir zwei Szenarien, in denen unsere Kunden, die zufällig Startups sind, mit einem bestehenden Quellcode zu uns kamen, der überarbeitet werden sollte. Wir hatten die Möglichkeit, die Anwendung neu zu schreiben, aber wir haben uns entschieden, tief in den Code hineinzuschauen und den Code zu überarbeiten. Damit haben wir großartige Ergebnisse erzielt.

Hier sind Beispiele für Code-Refactoring und ein Szenario:

* Erstens CityFalcon, ein Finanznachrichten-Aggregator, der einen umfassenden, relevanten, personalisierten und Echtzeit-Nachrichten-Feed für fundamentale Investoren bietet, der durch Crowd-Curation, soziale Medien und maschinelles Lernen angetrieben wird.

Dieses Projekt kam zu uns mit einem bestehenden MVP, das vom Gründer erstellt wurde, da er nach einem dreimonatigen Ruby-Kurs über einige Erfahrung in Ruby on Rails verfügt. Wie ich bereits erwähnt habe, hätten es einige Entwickler vorgezogen, ganz von vorne anzufangen, aber wir nutzten den Vorteil dessen, was bereits geschrieben wurde, um mehr Einblick in die App zu bekommen.

Es handelte sich um ein innovatives Produkt, das viele Herausforderungen birgt, Flexibilität und äußerst effiziente Lösungen erfordert. Wir mussten innerhalb kürzester Zeit alle Feinheiten des FinTech-Bereichs beherrschen, um die Natur des Projekts besser zu verstehen und unnötige Änderungen in der Zukunft zu vermeiden. Für uns war es entscheidend, uns an die Geschäftsprozesse des Kunden anzupassen und CityFalcon in vollem Umfang zu unterstützen, indem wir uns nicht nur auf die laufende Aufgabe, sondern auf das gesamte Produkt konzentrierten.

Wir nutzen die Praktiken der agilen Methodik, um eine rechtzeitige und effiziente Umsetzung der Projektfunktionen zu gewährleisten. Bevor wir mit dem Projekt begannen, wussten wir, dass wir mit Skalierungsproblemen konfrontiert sein würden, da es sich um ein bereits entwickeltes MVP handelte. Sobald der erste Benutzer auftauchte, stieg die Anzahl der Datensätze in der DB um das Hundertfache, und viele Unzulänglichkeiten des alten Frontends wurden in Kombination mit dem Backend offensichtlich.

Wir versuchten, die Skalierungsprobleme zu beseitigen, indem wir mehrere Server zur DB hinzufügten, um die Belastung des Hauptservers zu verringern. Wir verringerten auch die Zeit für die Bearbeitung von Anfragen und die Anzahl der Anfragen, indem wir die am häufigsten verwendeten Daten zwischenspeicherten und einen Load Balancer für die Webserver einsetzten. Wir haben Maßnahmen ergriffen, um Spam-Bots zu filtern und nutzlose Crawler zu blockieren. Eine weitere Lösung, die uns half, Skalierungsprobleme zu vermeiden, war die Aufteilung der Anwendung in separate Komponenten.

* Das zweite Szenario war Aquinium, eine Online-Umgebung mit Intelligenzspielen, in denen Menschen ihre kognitiven Fähigkeiten trainieren und schärfen können, sowie ein leistungsfähiges Tool, das dabei hilft, wissenschaftliche Daten in einer kontrollierten Umgebung zu sammeln, um die Forschung über die Schätzung individueller Größenordnungen, die Weisheit der Massen und Entscheidungsprozesse in Bezug auf den Handel mit Überzeugungen zu erleichtern.

Wir begannen das Projekt mit einem halbfertigen MVP, das vom Kunden erstellt wurde, und mussten den Code erheblich überarbeiten. Unsere erste Herausforderung bestand darin, das System flexibler und stabiler zu machen, indem wir zuverlässige Scoring-Algorithmen schrieben und auf eine angemessene Analyse der Eingangs- und Ausgangsdaten achteten. Wir mussten die Daten zwischen den Benutzern manipulieren und Statistiken entsprechend den von den Benutzern ausgewählten Daten speichern. Wir erreichten dies, indem wir die WebSockets-Technologie implementierten und sie in jedem Spielraum einsetzten, indem wir einen Kanal für jedes Benutzerpaar erstellten und Aktionen entsprechend der von ihnen gesendeten Daten auslösten. Dieser Ansatz hat sich als viel effektiver erwiesen als die Alternativen, wie z.B. Long-Polling.

Eine weitere große Herausforderung bestand darin, die Anwendung so skalierbar wie möglich zu gestalten, um mindestens 500 Spielräume zu verwalten, in denen 1000 Spieler gleichzeitig und störungsfrei online spielen können. Während wir die Anwendung untersuchten, stellten wir fest, dass sie eine angemessene und komplexe DB-Struktur benötigt, um die Beziehungen zwischen Benutzern und Computerbenutzern, die Spielstatistiken zu speichern und um die Analyse und den Export der Ergebnisse so einfach wie möglich zu gestalten. Daher haben wir eine hoch organisierte DB mit komplexen Beziehungen und Abhängigkeiten erstellt.

Es gibt Fälle, in denen man mit der Option konfrontiert wird, den Code zu refaktorisieren, anstatt ihn neu zu schreiben. Dies könnte eine Folge von technischen Schulden oder von Legacy-Code sein.

Technische Schuld ist der zusätzliche Entwicklungsprozess, der entsteht, wenn Code, der für einen kurzen Zeitraum implementiert wurde, verwendet wird, anstatt die beste und genaueste Lösung zu verwenden. In einer Situation, in der Sie einen Entwurf haben, dessen Umsetzung aber mehr Zeit in Anspruch nehmen wird, ist die schnelle Freigabe eines solchen Codes gleichbedeutend mit dem Eingehen von Schulden, so dass Ihnen nur die Wahl bleibt, den Code zu überarbeiten, anstatt ihn neu zu schreiben. Dies zeigt, dass das Refactoring von Code die technischen Schulden senkt und die Leistung steigern kann.

Legacy-Code wird oft als alter Code bezeichnet, der mit besseren Programmiertechniken oder Sprachen neu geschrieben werden kann. Er ist in der Regel nicht einfach umzuschreiben, da Abhängigkeiten von diesem Code bestehen. Das Refactoring von Legacy-Code sollte schrittweise über einen längeren Zeitraum erfolgen.

Wir bei Sloboda Studio sehen Refactoring als eine praktikable Option, obwohl wir in einigen Fällen den Code neu schreiben könnten. Bevor wir eine Entscheidung treffen, welchen Weg wir einschlagen (Neuschreiben oder Refactoring), wägen wir unsere Optionen ab und entscheiden uns für das Beste. Wir sind Experten, die in der Lage sind, herauszufinden, was zu einem bestimmten Zeitpunkt das Beste ist.