Angst davor, dass Web-App nicht "zukunftssicher" ist

Ich bin ein Webentwickler einer kleinen, lokalen SaaS-Webanwendung. Es hat derzeit etwa ein halbes Dutzend Kunden.

Während ich die Anwendung weiter entwerfe, wird es für mich immer schwieriger, mich von dem Projekt zu überzeugen, das in der Anfangsphase stattgefunden hat. Nachdem ich mich an das Projekt und den Code gewöhnt habe, den ich bereits geschrieben habe, fürchte ich, dass alle zusätzlichen Arbeiten, die ich zugesagt habe, in naher Zukunft rückgängig gemacht werden, wenn sich herausstellt, dass die App nicht gut skaliert, wenn das Geschäft wächst.

Als Universitätsstudent, der sich für ein Praktikum bewirbt, hatte ich die Frage der Arbeitgeber, ob ich während der Befragung keine Web-Frameworks verwenden sollte. Dies hat mich nur dazu veranlasst, meine bisherige Arbeit weiter anzuzweifeln. Ich kenne einfach keine Web-Frameworks und weiß nicht, welches ich verwenden soll.

Ich habe im Januar ein Praktikum als Full-Stack-Entwickler absolviert, in dem ich anfangen werde, Front-End-Frameworks zu lernen, aber der Druck, die App fertig zu stellen, steigt und ich überlege, die App komplett zu verschrotten und von vorne zu beginnen. Das habe ich schon mal gemacht. Die App ist derzeit in PHP und jQuery (für AJAX-Aufrufe) erstellt und verwendet MySQL für ihre Datenbank. Überlegen Sie, wie ich diese mentale Blockade überwinden und sicherstellen kann, dass meine App skalierbar ist? Danke im Voraus.

Perfekt ist der Feind des Guten.

Oder anders ausgedrückt: Mach dir heute keine Sorgen. Wenn Ihre App das tut, was sie tun muss, ist das in Ordnung. Es ist keine schlechte Sache, Teile der Software später neu zu schreiben. zu diesem Zeitpunkt wissen Sie 1) genauer, was Sie bauen möchten, und 2) welche Bits tatsächlich den Engpass darstellen. Sie könnten enorm viel Zeit damit verbringen, eine App zu schreiben, die sich auf eine Million Benutzer skalieren lässt, aber für Ihre derzeitigen sechs Kunden wäre dies nicht besser als das, was Sie heute haben .

Überlegen Sie, wie ich diese mentale Blockade überwinden und sicherstellen kann, dass meine App skalierbar ist?

Der springende Punkt ist nicht die Skalierbarkeit. Der springende Punkt ist , dass Sie es gleich beim ersten Mal richtig machen .

Sie sollten sich darauf konzentrieren, sauberen Code zu schreiben. Weil sauberer Code den Komfort maximiert, wenn Sie (unvermeidlich) in Zukunft etwas ändern müssen. Und das ist das eigentliche Ziel, das Sie haben sollten.

Was Sie jetzt versuchen, ist, sich den perfekten Code zum Schreiben auszudenken. Aber selbst wenn Sie das schaffen, wer sagt, dass sich die Anforderungen nicht ändern werden, oder Sie haben Ihre Entscheidungen möglicherweise aufgrund falscher Informationen oder falscher Kommunikation getroffen?

Sie können Fehler nicht vermeiden, auch wenn sie nicht Ihre Schuld sind. Konzentrieren Sie sich auf das Schreiben von Code, mit dem Sie später leicht Änderungen vornehmen können, anstatt zu hoffen, dass Sie Code schreiben, den Sie in Zukunft nicht mehr ändern müssen.

Dem Projekt und dem Code, den ich bereits geschrieben habe, verbunden,

Ich sympathisiere absolut mit diesem Gefühl. Es ist jedoch ein Problem, an den von Ihnen geschriebenen Code anzuhängen.

Das einzige, was eine Konstante sein sollte, ist Ihr Wunsch, ein bestimmtes Problem zu lösen . Wie Sie dieses Problem lösen, ist nur zweitrangig.

Wenn morgen ein neues Tool veröffentlicht wird, das Ihre Codebasis um 80% reduziert, werden Sie sich darüber ärgern, dass Ihr Code nicht mehr verwendet wird. oder wirst du froh sein, dass deine codebase kleiner und übersichtlicher geworden ist?

In ersterem Fall haben Sie ein Problem: Sie sehen keine Lösung für den Code . Mit anderen Worten, Sie konzentrieren sich auf den Code und sehen nicht das Gesamtbild (die Lösung, die er bieten soll).

Ich habe Angst, dass alle zusätzlichen Arbeiten, die ich zugesagt habe, in naher Zukunft aufgehoben werden, wenn sich herausstellt, dass die App nicht gut skaliert, wenn das Geschäft wächst.

Das ist ein anderes Problem für einen anderen Tag.

Zuerst bauen Sie etwas, das funktioniert. Zweitens verbessern Sie den Code, um eventuell noch vorhandene Fehler zu beheben. Was Sie gerade tun, ist, sich auf die erste Aufgabe zurückzuhalten, aus Angst, dann die zweite Aufgabe zu erledigen.

Aber welche andere Option gibt es? Sie können die Zukunft nicht sagen . Wenn Sie Ihre Zeit damit verbringen, über zukünftige Möglichkeiten nachzudenken, werden Sie ohnehin raten . Eine Vermutung neigt immer dazu, sich zu irren.

Erstellen Sie stattdessen die Anwendung und beweisen Sie, dass tatsächlich ein Problem vorliegt. Und sobald das Problem klar ist, können Sie es angehen.

Anders ausgedrückt: Henry Ford hat nie ein Auto gebaut, das den Standards / Erwartungen von 2018 entspricht. Aber wenn er nicht das Modell T gebaut hätte, ein nach modernen Maßstäben fehlerhaftes Auto, hätte niemand damit begonnen, Autos zu benutzen, es gäbe keine Autoindustrie, und niemand hätte ein Auto gehabt, das man verbessern könnte.

Ich hatte die Frage der Arbeitgeber, ob ich während der Befragungen keine Web-Frameworks verwenden wollte, was mich nur dazu veranlasste, meine bisherige Arbeit weiter anzuzweifeln.

Der wichtige Teil hier ist nicht, welches Framework Sie verwenden (jeder Arbeitgeber, der Sie danach beurteilt, macht seine Arbeit nicht richtig). Der wichtige Teil hier ist zu wissen, was Sie tun und warum Sie es tun .

Sie können beispielsweise vorhandene Frameworks gezielt vermeiden, weil Sie lernen möchten, warum ein Framework hilfreich ist, indem Sie es zuerst auf die harte Tour ausführen. Oder Sie könnten versuchen, Ihr eigenes Framework zu erstellen.

Die einzig schlechte Antwort ist "Ich weiß nicht", da es einen Mangel an fundierten Entscheidungen gibt. Das ist eine rote Fahne für einen Arbeitgeber.

Ich kenne einfach keine Web-Frameworks und weiß nicht, welches ich verwenden soll.

Das gleiche Problem entsteht hier. Die Lösung ist nicht mehr zu denken, sondern zu handeln:

• Hör auf, über die perfekte Antwort nachzudenken .
• Wählen Sie einen Rahmen. Wenn Sie keine Präferenz haben, wählen Sie eine zufällige. Benutze eine Dartscheibe, wirf einen Würfel, wirf eine Münze und nimm eine Karte.
• Benutze es.
• Hast du es gerne benutzt? Gab es etwas, das Sie nervig fanden?
• Schauen Sie nach, wie Sie diese schlechten Elemente verhindern können. Haben Sie das Framework missbraucht oder soll es so funktionieren?
• Sobald Sie das Gefühl haben, das Framework im Griff zu haben (unabhängig davon, ob Sie es mögen oder nicht), wählen Sie ein neues Framework aus und wiederholen Sie den Zyklus.

Lesen Sie dazu The doing mindset> the thinking mindset . Der Autor erklärt es besser als ich.

Aber der Druck, die App zu beenden, steigt und ich denke darüber nach, die App komplett zu verschrotten und von vorne zu beginnen

Es sei denn, die aktuelle Codebasis ist ein absolut nicht zu wartendes Chaos. Sie treffen die gegenteilige Entscheidung.
Entwickler denken oft, dass es die bessere Wahl wäre, Dinge wegzuwerfen. Es ist ein sehr verbreitetes Gefühl. Aber es ist selten die richtige Wahl.

Code wegzuwerfen und von vorne anzufangen ist, als ob Sie auf dem Weg zur Arbeit im Stau stecken bleiben und befürchten, dass Sie zu spät zur Arbeit kommen (Frist verpassen). Fahren Sie stattdessen nach Hause und fahren Sie dieselbe Straße erneut entlang. Das ergibt keinen Sinn. Sie sind zwar im Stau, aber immer noch näher an der Arbeit als zu Hause.

Trotz des enormen Geldbetrags, den Facebook und Google in das Marketing gesteckt haben, um Sie davon zu überzeugen, gibt es Front-End-Frameworks aus zwei Hauptgründen:

• Zunächst werden Hardware- / Netzwerkanforderungen an clientseitige Vorgänge ausgelagert, indem Status und Logik in den Client eingefügt werden
• Zweitens stellen sie, entsprechend der zusätzlichen Clientlogik, die zur Unterstützung des ersten Punkts erforderlich ist, isolierte Ausführungskontexte bereit, sodass Sie den Code anderer Personen in eine Seite einbetten können, ohne dass etwas beschädigt wird.

Sie müssen wahrscheinlich nur dann nach einem Framework suchen, um diese Probleme zu lösen, wenn Ihre Anwendung inhärent statusbehaftet ist, wenn der Umfang des Anwendungsstatus, den Sie clientseitig speichern, recht komplex ist und wenn Sie sehr viele Clients mit einer schlechten Netzwerklatenz erwarten (mobil, oder vom Server entfernt) oder wenn ein starkes geschäftliches Bedürfnis besteht, besonders fortgeschrittenes CSS oder die Erstellung dynamischer Elemente zu unterstützen.

Im Rahmen des Framework-Marketings möchten wir Sie darauf hinweisen, dass die spezielle Architektur die Entwicklungsgeschwindigkeit erhöht und die Wartung erleichtert. Dies ist offensichtlich falsch für kleine Teams, die an einfachen Projekten arbeiten. Das Isolieren von Code und das Organisieren von Importen kann einem großen Team dabei helfen, ein Produkt schneller auf den Markt zu bringen. Es bietet viel weniger Möglichkeiten für ein einzelnes Entwicklungsteam, das an einem bereits funktionsfähigen Projekt arbeitet.

Sie werden mehr Zeit damit verbringen, zu lernen, wie vorhandener funktionaler Code in das Framework eingepasst wird, als dass Sie Features tatsächlich implementieren. Die Chancen stehen gut, dass jemand irgendwo etwas aktualisiert und in diesem Framework geschriebener Code innerhalb von 18 Monaten nicht mehr funktioniert, es sei denn jemand ist da, um es ständig zu pflegen.

Vanilla JS und in einem geringeren, aber immer noch signifikanten Ausmaß JQuery leiden nicht unter diesen Problemen. Mit einigen bemerkenswerten Ausnahmen funktionieren JQuery + AJAX-Anwendungen, die sich nicht auf browserspezifische Verhaltensweisen stützen und auf externe Abhängigkeiten verzichten, 10-15 Jahre nachdem sie ursprünglich mit sehr geringfügigen Änderungen geschrieben wurden.

Frameworks eignen sich hervorragend für typische Startups, die fortlaufende, komplexe und öffentlich zugängliche Webanwendungen unterstützen. Sie ermöglichen es großen Teams, sich gut aufeinander abzustimmen, sich nahtlos in die Frameworks von Anbietern zu integrieren und neue Widgets und Design-Paradigmen zu unterstützen, um Ihre Wettbewerbsfähigkeit zu sichern.

Nichts davon ist für ein kleines Software-Tool mit einer festen Zielgruppe von Bedeutung, auf die Sie gleich verzichten werden. Die Übernahme eines Frameworks verlangsamt Ihre Entwicklungsgeschwindigkeit bei der Anpassung an ein neues Paradigma und führt zu unnötigen Kompatibilitätsrisiken. Wenn Sie den clientseitigen Code einfach halten (und im Idealfall selbst hosten), verringert sich das Kompatibilitätsrisiko erheblich. Browser werden sich ändern, CDN-URLs werden nicht mehr funktionieren, Abhängigkeiten werden veraltet sein - aber dieser Server wird von niemandem berührt, und er wird weiterhin einwandfrei funktionieren.

Nehmen Sie kein Framework an, es sei denn, es löst ein bestimmtes architektonisches Problem, das Sie heute haben oder das Sie in Kürze absehen können, und erwägen Sie nachdrücklich, dieses Problem auf andere Weise anzugehen, wenn dies überhaupt vertretbar ist.

Das Beste, was Sie tun können, um Ihre App "zukunftssicher" zu machen, ist, Best Practices beim Entwurf Ihres Systems zu befolgen, um die lose Kopplung und Trennung von Bedenken zu maximieren. Es gibt keinen Teil Ihrer App, der vor Veralterung sicher ist, aber Sie können viel tun, um Code, der aus dem Grund X veraltet ist, von Code zu isolieren, der nicht unbedingt von X betroffen sein muss.

Ich würde jedoch behaupten, dass Ihre Sorge weniger um das Wachstum / die Skalierbarkeit Ihrer App als um die Wachstumsrate Ihrer eigenen Erfahrungen und Fähigkeiten bestehen sollte. Die mentale Blockade, die Sie beschreiben, hört sich für mich so an, als lerne ich entweder Stagnation oder das Bewusstsein vieler bekannter Unbekannter, ohne die Strategie oder die Werkzeuge, um sie anzugehen.

Frameworks sind nicht besonders gut geeignet, um die Herausforderung der "Zukunftssicherheit" zu lösen, obwohl sie den Unerfahrenen in der Regel über übergeordnete Entwurfsmuster wie MVC eine relevante erste Anleitung bieten können . Sie eignen sich eher als Mittel zur Beschleunigung der Entwicklung, indem sie für eine starke Kohäsion sorgen, und gehen häufig zu Lasten einer engeren Kopplung. Angenommen, Sie verwenden ein von einem Framework bereitgestelltes objektrelationales Mapping-System in der gesamten App, um mit Ihrer Datenbank zu interagieren, einschließlich der Integration des Caching-Systems. Vielleicht müssen Sie später zu einem nicht relationalen Datenspeicher wechseln, und jetzt ist alles , was diesen verwendet, betroffen.

Das Chaos, das Sie jetzt haben, stammt nicht von dem, was Sie verwendet haben, sondern von dem , wo Sie es verwendet haben (wahrscheinlich fast überall im Back-End). Wie viel besser ist es für Sie, wenn der Code, der eine Seite rendert, niemals die Daten abruft, die sie rendert.

Angenommen, Sie möchten einer Seite ein kleines Widget hinzufügen, für dessen ordnungsgemäße Funktion zusätzliche Skripts und Ressourcen erforderlich sind. Wenn Sie ein Framework verwenden, können Sie fragen: "Wie soll ich die Abhängigkeiten zu einer Seite für diese Sache hinzufügen?" Wenn Sie nicht sind, dann ist die Frage offener: "Welche technischen Bedenken berühre ich, die irgendwie getrennt werden sollten?" Die Beantwortung dieser Frage erfordert mehr Erfahrung, aber hier einige Hinweise:

• Was würde passieren, wenn Sie morgen alle Ihre statischen Ressourcen (Skripte, Bilder usw.) auf einen separaten Server, ein separates Netzwerk für die Bereitstellung von Inhalten usw. verlagern oder versuchen würden, sie alle zusammen zu packen, um die Leistung zu verbessern?
• Was würde passieren, wenn Sie dieses Widget auf verschiedenen Seiten oder in mehreren Instanzen auf derselben Seite platzieren würden?
• Wie können Sie anfangen, AB-Tests für verschiedene Versionen des Widgets durchzuführen?

Wenn dies überwältigend klingt, dann würde ich vorschlagen, dass Sie vorerst ein Framework verwenden, nicht so sehr für Ihre App, sondern für Ihr persönliches Wachstum. Fangen Sie aber nicht unbedingt von vorne an. Verwenden Sie stattdessen Frameworks als Lehrplan, um die Entwicklung Ihrer App zu steuern.

Es gibt nur zwei Möglichkeiten zu lernen. Einer ist durch Versuch und Irrtum, und der andere ist durch Lernen aus der Erfahrung anderer. Versuch und Irrtum können nicht beseitigt werden. Softwareentwicklung ist von Natur aus ein kontinuierliches Lernfeld, und jeder Code, der nichts Neues oder Anderes tut, ist per Definition unnötig. (Verwenden Sie stattdessen den bereits geschriebenen Code.)

Der Trick besteht darin, es zu minimieren, indem Sie während jedes Schritts des Entwicklungsprozesses proaktiv nach bereits vorhandenem Wissen (Strategien, Best Practices und Code / Bibliotheken / Frameworks) suchen, damit Sie das Rad nicht ständig neu erfinden.

Was die App betrifft, die Sie gerade schreiben, sollten Sie sich zunächst nur darum kümmern, sie mit einem Minimum an weltlichem Aufwand zu erledigen . Angesichts der Natur des menschlichen Lernens besteht der schnellste Weg, um eine hohe Qualität zu erreichen, darin, mit etwas zu beginnen . Es ist viel einfacher, das Ziel zu verstehen, wenn Sie es durch Kritik an etwas, das Sie bereits haben, gestalten können.

Wenn Sie akzeptieren können, dass ein Großteil des Codes, den Sie schreiben, ein Wegwerf-Lernprozess ist und der notwendig ist, um gute Designs zu finden , wird dies Sie motivieren, daran festzuhalten. Schließlich ist es die Herausforderung der Problemlösung, die die Softwareentwicklung zu einer Herausforderung macht, und diese Herausforderung ist allgegenwärtig, wenn sich das, was Sie tun, lohnt (siehe obige Erklärung zum kontinuierlichen Lernen).

Vor allem, „die Sache Verschrottung und neu anzufangen“ ist nie eine Option ... schließlich, sagen Sie nicht , dass Sie „ein halbes Dutzend Kunden?“ Haben Sie noch eine Pause gemacht, um zu überlegen, was sie von Ihrer Äußerung halten könnten, da sie gerade (vermutlich) "vollkommen zufrieden mit Ihrer Arbeit sind ?!"

Hier ist eine Analogie, die ich gerne verwende:

• "Meine Aufgabe ist es, Häuser zu bauen, in denen Menschen leben können, in denen sie Geschäfte machen können und so weiter." Meine Aufgabe ist es, "diese unglaublich kleinen, überglorifizierten Sandstücke" zu machen, um nützliche Arbeit zu leisten. (So ​​wie Hausbauer Häuser aus Gipskartonplatten, Keramikfliesen, Betonblöcken und 2x4 fertigen.)

• Während sich die "Nägel", die Hausbauer verwenden, in zweihundert Jahren nicht wirklich verändert haben (außer, um von "quadratisch" zu "rund" zu wechseln und dann mit pneumatischen Nagelmaschinen nützlich zu werden), ist die Technologie Das, was wir verwenden, ändert sich ständig und unterliegt manchmal tiefgreifenden Veränderungen. ("So geht es.")

• „Dennoch jedes Haus, einmal gebaut, wird für immer nach werden lebt in.“ Sie können sie nicht räumen. Sobald Sie es gebaut und die Schlüssel übergeben haben, ist es nicht mehr 'Ihr' Haus. Es ist das, was es jetzt ist, und es wird sehr lange Bestand haben.

Ein großer Teil meines heutigen Geschäfts ist es, Kunden dabei zu helfen, mit Software umzugehen, die vor zehn, zwanzig, dreißig oder mehr Jahren unter Verwendung der damals existierenden "State-of-the-Art" -Technologien entwickelt wurde. Ich erinnere mich) - und die sind heute noch in Betrieb (!).

Es ist fast unmöglich, Zukunftssicherheit zu gewährleisten. Es ist jedoch nicht allzu schwierig zu überprüfen, ob die App skalierbar ist. Sie müssen nur einen Leistungstest für die App schreiben und sehen, wie viele Clients damit umgehen können. Das Schreiben von Tests macht Ihre App auf jeden Fall zukunftssicherer, da Sie das Verhalten der App beurteilen können, nachdem Sie weitere Änderungen daran vorgenommen haben.

In Bezug auf die Leistung und Skalierbarkeit würde ich mir keine Sorgen machen. Dies können Sie leicht überprüfen und höchstwahrscheinlich beheben. Das größere Problem ist die Sicherheit. Web-Frameworks helfen Ihnen normalerweise dabei, den richtigen Authentifizierungscode, Cookies, CSRF-Schutz usw. zu schreiben. Insbesondere aufgrund Ihrer mangelnden Erfahrung sollten Sie sich besser auf diesen Bereich konzentrieren.

Ich habe angefangen, einen Kommentar über Lern-Frameworks zu schreiben, aber irgendwann wurde daraus etwas, das eher wie eine Antwort aussah, also hier ist es.

Es scheint ein Problem zu sein, keine Frameworks zu kennen. Grundsätzlich müssen Sie in jedem WebDev-Job mit einem Framework arbeiten. Ein anderes Framework zu erlernen, nachdem Sie wissen, dass eines nicht so wichtig ist, aber das Erlernen des ersten kann eine Weile dauern - weshalb sich Arbeitgeber möglicherweise darum kümmern. Das Vermeiden von Frameworks kann auf ein hier nicht erfundenes Syndrom hinweisen , was ein weitestgehend unpraktischer Ansatz ist.

Der wichtigste Punkt, um Ihre ersten Frameworks zu kennen, ist das Erlernen einer gemeinsamen Sprache. Versuchen Sie vielleicht einfach, etwas zu lernen, das bei Ihren Kollegen beliebt ist. Sie können versuchen, ein einfaches Projekt zu ändern, das in einem Framework geschrieben ist. Ein Projekt in einem Framework, das Sie nicht kennen, von Grund auf neu zu starten, ist eine sehr ineffektive Lernmethode.

Ihre eigentliche Frage betraf nun ein bestimmtes Projekt und die Portierung in ein Framework. Dafür scheint die Antwort zu sein: Es kommt darauf an, und wir können es Ihnen nicht wirklich sagen. Es ist jedoch mit ziemlicher Sicherheit eine schlechte Idee, Dinge auf ein Framework zu portieren, das Sie nicht kennen, da Sie nicht einmal wissen können, ob es sinnvoll ist . Es scheint also, dass Sie es so lassen sollten, wie es ist, und diese Entscheidung irgendwann noch einmal überdenken sollten, sobald Sie einen Rahmen kennen und mögen. Andere Antworten enthalten gute Punkte darüber, worauf Sie bei einer solchen Entscheidung achten sollten.

Dieser Artikel stieß vor 2,5 Jahren auf großes Interesse bei Hacker News: Schreiben Sie Code, der leicht zu löschen und nicht leicht zu erweitern ist. Diese Perspektive kann Ihnen beim Umgang mit Ihrer aktuellen Codebasis helfen oder auch nicht. In Zukunft kann sie jedoch helfen, Frustrationen durch Perfektionismus / Überentwicklung zu vermeiden.

Wenn wir "Codezeilen" als "ausgegebene Zeilen" sehen, senken wir beim Löschen von Codezeilen die Wartungskosten. Anstatt wiederverwendbare Software zu erstellen, sollten wir versuchen, Einweg-Software zu erstellen.

Ich muss Ihnen nicht sagen, dass das Löschen von Code mehr Spaß macht als das Schreiben.

(Hervorhebung von mir)

Der Artikel in den Hacker News könnte ebenfalls eine Lektüre wert sein.

Was die Zukunftssicherheit und die Anwendung von Skalierungs- und Rahmenprinzipien angeht, ist es eine große Aufgabe, sich selbst darum zu kümmern. Ich würde mir wahrscheinlich keine Sorgen machen, aber wenn Sie Folgendes tun müssen:

Halten Sie Ihren Code sauber und befolgen Sie die SOLID, DRY-Prinzipien> google.

Wenden Sie so schnell wie möglich einen Lastenausgleich an.

Stellen Sie mindestens zwei Webserver bereit, und behandeln Sie Lastausgleichsszenarien im Code.

Und last but not least gibt es bessere Stacks für den Umgang mit einer Million Benutzern als LAMP, aber ich bin mir sicher, dass es absolut machbar ist.

Fall und Punkt, siehe: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade Der Punkt ist gültig, aber 10 GB ist trivial als Testperson.