Während der Arbeit in einem Startup kann man mit dem Wunsch konfrontiert werden, den Code komplett neu zu schreiben. Eine solche Situation kann bei Projekten auftreten, die bereits ein MVP veröffentlicht und Investitionen erhalten haben. Sie sind bereits seit einiger Zeit erfolgreich auf dem Markt tätig und haben Kunden oder aktive Nutzer. Nachdem die größten Herausforderungen überwunden sind, wird das Team wahrscheinlich in Betracht ziehen, die Anwendung von Grund auf neu zu schreiben.
Wir haben auch die Erfahrung, unser Startup-Projekt komplett umzugestalten. In diesem Artikel erzählen wir Ihnen, wie wir es gemacht haben, welche Ergebnisse wir erzielt haben, vor welchen Herausforderungen wir standen und welche Schlussfolgerungen wir gezogen haben. Außerdem erfahren Sie etwas über die Besonderheiten des Startup-Workflows und wie Sie vermeiden können, Ihren Code neu schreiben zu müssen.
Neugestaltung eines Startups
Warum will das Team den Code des Projekts neu schreiben? Um dies zu verstehen, sollten wir darüber nachdenken, was ein Startup von jeder anderen Art von Unternehmen unterscheidet.
Die wichtigsten Eigenheiten eines Start-ups
- Erschließung eines neuen Marktes
Die Erschließung eines neuen Marktes ist ein ehrgeiziges Projekt. In der Regel wollen sie einen bestimmten Bereich des Unternehmens verbessern oder automatisieren, um eine Herausforderung zu lösen, die bisher noch niemand in Angriff genommen hat.
- Schnelle Entwicklung von Grund auf
Das Produkt wird von Grund auf neu entwickelt. Obwohl es keinen Legacy-Code gibt, zwingen die knappen Fristen das Team dazu, chaotisch zu arbeiten und neue Funktionen hinzuzufügen, ohne auf die Strukturierung und Dokumentation des Codes zu achten.
- Begrenztes Budget
Neben den begrenzten zeitlichen Ressourcen verfügen Start-ups auch über ein begrenztes Budget. In der Regel stammt das Geld aus den Investitionen, die sie erhalten haben, oder aus den Mitteln der Gründer und Mitgründer.
Die Herausforderungen eines Start-up-Unternehmens
- Strategische
Das Start-up bewegt sich in einem neuen Markt mit sich schnell ändernden Anforderungen, und um sich gegen die Konkurrenz durchzusetzen, muss das Produkt diesen Anforderungen entsprechen. Kunden und Investoren fordern neue Funktionen, Konkurrenten bringen sie auf den Markt, und um wettbewerbsfähig zu bleiben, muss das Start-up Fortschritte nachweisen. Da es unmöglich ist, die Trends von morgen vorherzusehen, ist es schwierig, eine gute Strategie zu entwickeln und zu verfolgen. Mangelnde Planung und häufig wechselnde Anforderungen verwischen das Endziel und können dazu führen, dass ein völlig anderes Produkt entsteht.
- Finanzen
Abgesehen von der begrenzten Zeit haben Startups in der Regel nicht genug Geld, um technische Funktionen optimal zu implementieren, die beste Hardware zu kaufen oder die besten Entwickler einzustellen. Das Team muss möglicherweise schnelle und unbeholfene Lösungen entwerfen, die wahrscheinlich weitere Schwierigkeiten bei der Wartung und Skalierung der Anwendung verursachen werden. Doch diese schnellen Lösungen funktionieren, und manchmal sind sie die einzige Möglichkeit für Start-ups, mit dem Markt Schritt zu halten.
- Technisch
Wie bereits erwähnt, erkunden Start-ups einen neuen Markt und haben mit neuen Problemen zu kämpfen. Sie werden wahrscheinlich auf technische Probleme stoßen, mit denen noch niemand zuvor konfrontiert war, und müssen diese zeitnah lösen. Da die Herausforderung noch unerforscht ist, kann es unklar sein, ob das Problem zum jetzigen Zeitpunkt gelöst werden kann.
- Organisatorisches
Alle vorgenannten Punkte führen zu Herausforderungen bei der Organisation des Arbeitsablaufs. Enge Fristen in Kombination mit unstrukturierten Anforderungen bringen Chaos in den Arbeitsprozess und führen schnell zu einer ungenauen Entwicklung neuer Funktionen. Diese Faktoren führen zu Schwierigkeiten bei der Weiterentwicklung und Wartung der Anwendung.
Die häufigsten Probleme mit der Codebasis eines Start-ups
- Mangel an Dokumentation
Die Arbeit an einem Startup-Projekt wird unter engen Fristen erledigt. Manchmal bleibt bei dieser Art der Organisation des Arbeitsablaufs keine Zeit für eine angemessene Code-Dokumentation. Dies kann zu Schwierigkeiten bei der weiteren Wartung der Anwendung führen: Die Entwickler müssen mehr Zeit aufwenden, um die Ideen der Autoren zu verstehen.
- Technische Schulden
Da die Mittel und die Zeit begrenzt sind, muss das Team möglicherweise einige seiner Ausgaben reduzieren: billigere Server kaufen, Funktionen schneller und weniger optimal implementieren usw. Diese Faktoren und eine mangelhafte Dokumentation verursachen technische Schulden – die Menge an notwendiger Arbeit, die aufgeschoben wurde. Wenn diese Schulden nicht in naher Zukunft zurückgezahlt werden, wird die Wartung und Weiterentwicklung des Produkts schwieriger und zeitaufwändiger.
- Mangel an Logik
Das Startup-Team muss sich mit einem sich schnell verändernden Markt auseinandersetzen und der Anwendung ständig neue Funktionen hinzufügen. Nicht alle davon passen in die ursprüngliche Architektur, was dazu führt, dass alternative Lösungen gesucht werden, die möglicherweise nicht optimal sind. Klebebandlösungen und schlechte Dokumentation lassen den Code in den Augen der neuen Entwickler, die an dem Projekt arbeiten, unlogisch erscheinen.
Warum eine Neugründung umschreiben?
Nachdem wir die wichtigsten Merkmale und Herausforderungen eines Startups betrachtet haben, können wir zusammenfassen, warum Entwickler ein Startup neu schreiben wollen. Die häufigsten Gründe hierfür sind die folgenden:
- die Qualität und Lesbarkeit des Codes zu verbessern
- um die weitere Pflege der Anwendung zu vereinfachen
- die Architektur zu verbessern
- die Lösungen mit Klebeband durch elegante Lösungen zu ersetzen
Unsere Erfahrung mit der vollständigen Neuprogrammierung unserer Software
Bei der Arbeit an einem unserer Startup-Projekte sahen wir uns mit der Notwendigkeit konfrontiert, erhebliche Änderungen an der Codebasis vorzunehmen. Nachdem wir die Situation mit unserem Kunden besprochen hatten, stimmten wir zu, den Code von Grund auf neu zu schreiben und begannen den Prozess.
Die Gründe für die Neufassung
- Änderung der Geschäftslogik
Aufgrund der positiven Reaktionen der Nutzer beschloss unser Kunde, das Produkt als universellere Plattform weiterzuentwickeln. Die Architektur war jedoch nicht für diese Art von Funktion ausgelegt und konnte diese Art von Aufgaben nicht bewältigen.
- Veraltete Architektur
Um das Interesse der Nutzer aufrechtzuerhalten, musste das Team das Produkt ständig weiterentwickeln und neue Funktionen hinzufügen. Nicht alle davon konnten in der derzeitigen Architektur implementiert werden. Darüber hinaus würde die derzeitige Architektur wahrscheinlich Schwierigkeiten bei der weiteren Wartung und Skalierung der Anwendung verursachen.
- Technische Schulden
Aufgrund der begrenzten Zeit und des begrenzten Budgets waren einige der Lösungen nicht zuverlässig genug, um weitere Aufgaben zu bewältigen. Außerdem hinderten die technischen Schulden das Team daran, das bestehende Produkt effizient zu pflegen und neue Funktionen zu entwickeln. Um es kurz zu machen: Die Schulden mussten in naher Zukunft zurückgezahlt werden.
- Bessere Lösungen
Da es sich um ein Produkt für einen neuen Markt handelte, sah sich das Team mit neuen technischen Herausforderungen konfrontiert. Die Lösungen, die wir fanden, waren praktikabel, aber nicht perfekt. Im Laufe der Arbeit haben wir unser Wissen erweitert und elegantere und effizientere Wege gefunden, um diese Herausforderungen zu lösen und die technischen Schulden zu begleichen.
Definieren des Aufgabenstapels
Bevor wir mit der eigentlichen Arbeit begannen, legten wir den Umfang der von uns auszuführenden Arbeiten fest. Dies half uns, den Arbeitsprozess effizienter zu gestalten, was sich positiv auf die Qualität des Endprodukts auswirkte. Unsere Hauptaufgaben waren:
- Integration der neuen Geschäftslogik der Anwendung in ihre Architektur
- die Struktur des Projekts zu vereinheitlichen, um ein allgemeines System zu schaffen und nicht Zeit damit zu verbringen, einen Weg zu finden, jede kleine Änderung einzuführen
- Aufteilung der monolithischen Anwendung in einen Back-End- und einen Front-End-Teil, damit die Entwickler unabhängig voneinander arbeiten können
- Entfernung von Edelsteinen und Bibliotheken, die nicht in die neue Architektur passen, um den Code zu säubern und die Leistung des Produkts zu verbessern
Unsere Implementierungen
Nachdem wir die genauen Aufgaben definiert hatten, begannen wir mit der Arbeit. Wir haben den Front-End-Teil der Anwendung komplett auf Vue.js anstelle von jQueryumgeschrieben.
Wir änderten auch unsere Herangehensweise an die Backend-Struktur und begannen, aufrufbare Objektezu verwenden . Darüber hinaus haben wir beschlossen, die Namespaces in Rails vollständig zu nutzen. Dies half uns, die Controller und Dienste zu strukturieren und die Anwendung zu einem integrierten System zu vereinen.
Einige der von uns verwendeten Bibliotheken und Edelsteine passten nicht vollständig in die Architektur der App, was sich auf ihre Leistung auswirkte. Wir beschlossen, diese Elemente nicht mehr zu verwenden und stattdessen unsere eigenen Lösungen zu schreiben. Dies erwies sich als einfacher und effizienter als der Versuch, die bereits erstellten Pakete in die Architektur einzupassen.
Wir haben jedoch zwei neue Bibliotheken hinzugefügt: Dry Validation und Sorcery für die Validierung und Authentifizierung. Außerdem haben wir ElasticSearch für die Bearbeitung komplexer Suchanfrageneingeführt .
Nachdem wir mit dem Refactoring begonnen hatten, beschlossen wir, unsere Repositories von Github nach Gitlab zu verlagern. Letzteres bietet einen bequemeren Prozess der Pipeline-Einstellungen und die Möglichkeit der automatischen Projekterstellung, Prüfung und Bereitstellung auf dem Server. Außerdem verwenden wir Gitlab Task Tracking für die Verwaltung des Projekts.
Was waren die Ergebnisse?
Unsere Arbeit führte zu einer Verbesserung der Architektur und der Qualität des Codes. Er wurde lesbarer, logischer und strukturierter.
Die Arbeit der App wurde schneller, sie konnte die von unserem Kunden geforderten Funktionen unterstützen und mehr Last bewältigen. Die verbesserte Codebasis hat die Wartung der Anwendung und die Implementierung neuer Funktionen vereinfacht.
Die Herausforderungen, denen wir gegenüberstanden
Obwohl sich die Neufassung positiv auf die Leistung der Anwendung auswirkte, sahen wir uns bei der Arbeit daran mit mehreren Herausforderungen konfrontiert. Insbesondere hatten wir Schwierigkeiten, die neuen Technologien einzuführen und sie mit der Architektur zu kompilieren.
Bei der Entwicklung des komplizierten Systems sahen wir uns mit der Situation konfrontiert, dass einige der Teilsysteme zunächst nicht dokumentiert waren. Als es dann an die Umsetzung ging, hatten die Entwickler unterschiedliche Vorstellungen von den Funktionen und ihrer Realisierung.
Darüber hinaus gab es Herausforderungen bei der Integration von Funktionen, die für bestimmte Kunden entwickelt wurden, in die neue Architektur. Dabei sollte man der Planung des Arbeitsablaufs und der Dokumentation des Codes große Aufmerksamkeit widmen. Andernfalls führen der sich verändernde Markt und die neuen Anforderungen zu einer chaotischen Entwicklung, und das Team wird mit denselben alten Problemen konfrontiert.
Die Schlussfolgerungen, die wir gezogen haben
Nicht alle Start-ups überstehen eine Phase, in der sie ihren bestehenden Code neu schreiben. Der Markt verändert sich schnell, Wettbewerber entwickeln neue Produkte und fügen neue Funktionen hinzu, um Nutzer anzulocken. Wir haben es geschafft, und die neue Version unseres Projekts hilft uns, es schneller und effizienter zu entwickeln. Wir hatten die Möglichkeit, dieselben Aufgaben ein zweites Mal zu erledigen, und es ist uns gelungen, bessere Lösungen zu schaffen. Derzeit arbeiten wir mit einem eleganteren Code.
Es wäre jedoch klüger, das Umschreiben zu vermeiden, indem man auf die Organisation des Arbeitsablaufs achtet. Als Mitglied eines Start-ups kann man nichts vorhersehen. Deshalb ist das Risikomanagement ein zentraler Punkt eines erfolgreichen Startups. Die Strategie, die Pläne und die Fristen sollten flexibel sein, sie sollten mögliche Herausforderungen und Verzögerungen berücksichtigen.
Was sollte man wissen, bevor man ein Startup umschreibt?
Eine Neufassung der Software ist eine riskante Entscheidung. Bevor sie getroffen wird, sollte das Startup-Team die möglichen Vor- und Nachteile abwägen und über alternative Lösungen nachdenken.
Einer der wichtigsten Faktoren für die Entscheidung, ob es sich lohnt, ein Startup umzuschreiben, ist das Stadium seiner Entwicklung.
Der Lebenszyklus eines Startups
- Prototyp
Eine kurze Skizzierung des Konzepts, um die Realisierbarkeit einer Idee zu definieren. Der Prototyp sollte lediglich die Idee umfassend darstellen – die Genauigkeit und Eleganz des Codes sind in diesem Stadium nicht wirklich wichtig.
- MVP
Schaffung eines brauchbaren Produkts, um die ersten Nutzer und Investitionen anzuziehen. In dieser Phase ist die Entwicklung von Grund auf ein Muss. Während der Prototyp die Idee nur umreißt, sollte der MVP sie bestmöglich umsetzen – andernfalls wird das Projekt für potenzielle Nutzer nicht interessant sein.
- Produkt
Entwicklung und Pflege des voll funktionsfähigen Produkts mit dem Ziel, Nutzer anzuziehen und eine Investitionsrendite zu erzielen. Es ist immer noch möglich, die Entwicklung von Grund auf neu zu beginnen – im Falle der jüngsten Veröffentlichung des MVP.
Wenn ein voll funktionsfähiges Produkt schon lange auf dem Markt ist und eine große Anzahl von Nutzern hat, ist eine komplette Neuprogrammierung wahrscheinlich keine gute Idee. Erstens wird das Team sicherlich technische Schwierigkeiten mit dem Übergang der Nutzerdaten auf eine andere Plattform haben. Zweitens ist es unwahrscheinlich, dass die Nutzerschaft einem Produkt treu bleibt, das keine sichtbaren Fortschritte macht. Daher empfehlen wir, andere Wege der Codeumgestaltung in Betracht zu ziehen.
Umschreiben oder Refaktorieren des Codes – was ist zu wählen?
Wir alle wissen, dass Entwickler nicht gerne mit veraltetem Code arbeiten, und genau das ist es, was Refactoring ausmacht. Sie schreiben lieber ihren eigenen Code und implementieren neue Funktionen von Grund auf. Doch in den meisten Fällen ist Refactoring die bessere Idee.
Refactoring ist das, was Ihr Projekt braucht
Wenn Ihr Projekt große technische Schulden angehäuft hat, sein Code unordentlich aussieht und es viele Klebebandlösungen gibt, ist ein Rewrite kein Allheilmittel.
Alle oben genannten Probleme deuten auf organisatorische Fragen hin. Es gibt Probleme mit der Strategie, die nicht dadurch gelöst werden können, dass alles von Grund auf neu geschrieben wird. Wenn das Team einfach anfängt, den neuen sauberen Code zu schreiben, wird es in Zukunft wahrscheinlich auf die gleichen Schwierigkeiten stoßen: Unlogische Entwicklung und knappe Fristen werden es dazu bringen, Klebebandlösungen anzuwenden, die Dokumentation zu vernachlässigen usw.
In diesem Fall besteht der beste Ausweg darin, die wichtigsten Teile der Anwendung zu refaktorisieren und mehr Mühe auf die Optimierung des Arbeitsprozesses zu verwenden.
Es ist an der Zeit, alles neu zu schreiben
Im Allgemeinen ist das Rewrite eine optimale Lösung für ein altes Projekt mit veraltetem Legacy-Code. Sie gibt dem Team die Möglichkeit, den technologischen Stack vollständig zu ändern und die besten Entwicklungspraktiken anzuwenden.
Eine Neuschreibung von Grund auf ist die beste Option, wenn sich die Geschäftslogik der Anwendung erheblich geändert hat und die alte Architektur nicht mehr in der Lage ist, ihre Arbeit zu bewältigen. Genau das war unsere Situation – deshalb haben wir eine Neuschreibung dem Refactoring vorgezogen.
Wie vermeidet man die Umschreibung einer problematischen Neugründung?
Wie bereits erwähnt, besteht das Hauptproblem von Startup-Projekten im Fehlen eines strategischen Ansatzes, und dies kann nicht durch eine neue Codebasis gelöst werden. Die Änderungen sollten die tiefgreifenden Aspekte der Entwicklung betreffen, anstatt die unmittelbaren Probleme zu lösen. Die folgenden Dinge werden die Qualität Ihrer Arbeit verbessern.
- Aufrechterhaltung der guten Qualität des Codes
Die Einführung einiger Routineverfahren wird das weitere rasche Anwachsen der technischen Schulden verhindern, die Zahl der Klebebandlösungen verringern und den Arbeitsprozess bequemer gestalten.
- Dokumentieren des Codes
Die Beachtung der Dokumentation verbessert das Verständnis für die Funktionsweise des Produkts und erleichtert die weitere Wartung.
- Abschreibungskosten
Sowohl die Hardware als auch die Software werden eines Tages veraltet sein. Sie sollten darauf vorbereitet sein, dass Sie die Hardware austauschen oder einige Teile Ihres Codes ändern müssen.
Was können wir jetzt tun?
Der beste Zeitpunkt, um der Qualität des Codes mehr Aufmerksamkeit zu schenken, ist jetzt. Die folgenden Dinge werden Ihre ersten Schritte zur Optimierung sein:
- Überprüfen Sie Ihren Code mit RubyCritic
Es handelt sich um einen Edelstein zur Kontrolle der Qualität Ihres Codes. Es definiert die Schwachstellen der Codebasis, damit Sie sie sofort überarbeiten oder eine To-Do-Notiz für die Zukunft machen können.
- Durchführung einer Überprüfungssitzung
Um die Arbeit der Entwickler zu vereinfachen, können Sie eine Sitzung abhalten, um den Arbeitsablauf zu besprechen und zu definieren, was genau mit Ihren derzeitigen Prozessen nicht stimmt, warum die technischen Schulden immer weiter wachsen und wie Sie sie beheben können.
- Testabdeckung
Durch die Abdeckung des Codes mit Autotests werden Fehler in einem frühen Stadium entdeckt. Wenn Sie mehr über Softwaretests erfahren möchten, lesen Sie bitte unseren jüngsten Artikel.
Schlussfolgerungen
Die Neufassung einer Anwendung ist keine Garantie für künftigen Erfolg und eine wachsende Zahl von Benutzern. Wenn Sie außerdem der Optimierung des Entwicklungsprozesses nicht genügend Aufmerksamkeit schenken, wird das Projekt wahrscheinlich wieder mit denselben Schwierigkeiten konfrontiert: technische Schulden, Klebebandlösungen und chaotische Entwicklung.
Bevor Sie die Entscheidung treffen, das Startup von Grund auf neu zu schreiben, sollten Sie bedenken, dass ein erfolgreiches Projekt nicht aus einzelnen Lösungen für komplizierte Aufgaben besteht. Der Erfolg des Projekts wird an der Leistung des Teams bei der täglichen Routinearbeit gemessen.
