Websites ändern sich. Gesunde Codebasen werden ständig aktualisiert. Legacy-Code stirbt, wenn er schließlich mit dem Schiff untergeht. Die Erkenntnis, dass mein Code vergänglich ist, ermöglicht es mir, pragmatischer mit meinem Code umzugehen und was meine Entscheidungen bei seiner Erstellung leitet.
Ihr Code ist vergänglich.
Ich neige dazu, dass Codeänderungen aus einem von zwei Gründen entstehen: Codeverfall oder Website-Relevanz.
Codeverfall
Der Code, den wir schreiben, folgt Spezifikationen von Autoritäten wie Webbrowsern oder Frameworks. Er kann auch auf Anforderungen eines Unternehmens oder einer Organisation basieren, für die die Website bestimmt ist. All diese Regeln ändern sich, während sich unsere Websites und ihre Kontexte weiterentwickeln. Ich betrachte dies als Codeverfall. Vielleicht wird eine HTML-Spezifikation von Browsern übernommen, die es uns ermöglicht, semantischere Auszeichnungen zu verwenden, oder vielleicht verwenden wir ein Framework und möchten auf die neueste Hauptversion aktualisieren. Vielleicht muss ein Unternehmen Zahlungsanbieter wechseln oder es gibt eine neue Sicherheitsanforderung, die wir übernehmen müssen. Unser Code muss häufig gewartet werden, um Schritt zu halten und manchmal auch, um funktionsfähig zu bleiben. Gelegentlich können wir lange Zeit ohne Änderungen auskommen, aber es gibt immer einen Punkt, an dem alter Code entweder geändert oder entsorgt werden muss.
Website-Relevanz
Seien wir ehrlich, unsere Website ist nicht mehr so cool wie früher. Vielleicht liegt es daran, dass das Design veraltet ist oder daran, dass das, was sie tut, für die Leute weniger wichtig ist als früher. Vielleicht gibt es eine neue Anforderung und Funktion, die hinzugefügt werden muss, oder vielleicht haben wir einfach genug davon, darauf zu starren. Redesign! Rebranding! Iterieren! Es ist unangemessen zu erwarten, dass die meisten Websites relevant bleiben, ohne ihren Inhalt oder Code im Laufe der Zeit erheblich zu ändern. Wir sollten erwarten, dass sich unser Code ebenso im Laufe der Zeit ändert – insbesondere im Frontend.
Akzeptanz von Veränderungen
Die Realität des Wandels scheint eine ziemlich offensichtliche Sache zu sein, die man anerkennen muss. Dennoch finde ich es als jemand, der dazu neigt, Code zu schreiben, als ob ich die Große Pyramide von Gizeh baue, eine hilfreiche Erinnerung. Programmieren ähnelt oft eher dem Aufstellen eines Lagers, ohne zu wissen, ob wir ein paar Tage oder ein Jahr bleiben werden. Ich versuche, mit der Annahme zu beginnen, dass es kurz sein wird, und mich im Laufe der Zeit einzurichten. Überlegen Sie, ob Sie überteuertes Wasser im Geschäft kaufen, bevor wir einen ganzen Brunnen graben. So oft finde ich mich Tage nach dem Aufschlagen meines Zeltes in einer hektischen Umsiedlung wieder. Ich muss nicht weiter als ein paar Monate zurückblicken, um Code zu finden, den ich geschrieben habe und der bereits geändert werden muss. Er muss nicht geändert werden, weil ich ihn beim ersten Mal nicht gut genug gemacht habe – es ist einfach Zeit, ihn zu ändern! Wie sollte sich das auf die Art und Weise auswirken, wie wir unseren Code schreiben oder darüber denken? Hier sind ein paar Gedanken, die ich kürzlich übernommen habe.
1) Schreiben Sie vergänglichen Code.
Zu wissen, dass sich mein Code in naher Zukunft ändern kann, ermöglicht es mir, mich auf seinen aktuellen Zweck zu konzentrieren und sicherzustellen, dass sein Fußabdruck isoliert ist. Es hat mich befreit, mich auf den Code vor mir zu konzentrieren und nicht durch mögliche zukünftige Zeitpläne des Codes, den ich schreibe, abgelenkt zu werden. Dies ist besonders relevant für große Teile kleiner Projekte. Bei großen Projekten können Sie dieses Prinzip auf Teile Ihrer Codebasis anwenden. Wenn Sie eine Komponente in einer Bibliothek ein ganzes Jahr lang verwendet haben, haben sich ihre Anforderungen im Laufe der Zeit oft geändert. Das Entfernen des unnötigen Ballasts der Vergangenheit kann ihr helfen, für die unmittelbare Zukunft einen Zweck zu erfüllen. Ich stelle oft fest, dass das Schreiben einer Ersatzkomponente schneller geht als die Aktualisierung einer alten, und das Ergebnis ist einfacher zu verwenden und zu verstehen. Wo immer es angebracht ist, versuche ich zu ersetzen statt zu sanieren. Wenn ich etwas Neues schaffe, priorisiere ich die Gegenwart und vertraue darauf, dass ich mir später Zeit gebe, zukünftige Probleme zu lösen. Zukünftige Probleme lassen sich oft am besten in der Zukunft lösen, da man tendenziell mehr Fakten und weniger Annahmen hat, je näher man dem Problem kommt.
2) Vermeiden Sie nach Möglichkeit Abhängigkeiten.
Immer mehr fühle ich mich zur integrierten Browserfunktionalität hingezogen und habe hohe Hürden, wenn ich die Verwendung von Frameworks rechtfertige. Bei bestimmten Skalierungen sind Abhängigkeiten unvermeidlich und in kollaborativen Umgebungen oft effizienter. Wenn ich sie verwende, versuche ich, ihre Funktionalität zu isolieren oder zu umschließen, damit sie später leichter zu entwirren ist, falls ich sie benötige. Wenn Sie den Aufwand gerechtfertigen können, Ihren eigenen Code zu schreiben, werden Sie mit Web-Spezifikationen vertrauter und lernen, wie robust sie allein sind. Sie erhalten auch etwas, das langfristig einfacher zu warten ist, da es dem Kernentwicklungspfad des Webs am nächsten liegt. Es gibt kein Abhängigkeits-Upgrade zwischen Ihrem Code und der sich ständig weiterentwickelnden Browserfunktionalität.
3) Lassen Sie den Code sterben.
Während dies nur für Situationen akzeptabel ist, die aus wichtigen Gründen, wie z. B. Benutzerfreundlichkeit, keine Änderung erfordern, ist dies meine Lieblingsmethode, wenn es sinnvoll ist. Lassen Sie die Dinge alt werden. Planen Sie nicht, sie zu aktualisieren. Kreativprojekte und Demos sind dafür bestens geeignet. Indem wir alte Projekte sterben lassen, erkennen wir an, dass ihr Wert stark an den Moment ihrer Existenz gebunden war. Nicht alles muss für immer bestehen (Spoiler: Nichts, was wir erschaffen, wird für immer bestehen). Wenn etwas wichtig ist und Sie es erhalten möchten, erfassen Sie seine Bedeutsamkeit durch Bildschirmaufnahmen und Dokumentation und machen Sie dann weiter. Dies hat es mir ermöglicht, freier zum nächsten Ding überzugehen.
Fortschritt
Für mich ist das meditativste und belebendste, was ich als jemand, der Code schreibt, tun kann, die Tatsache zu bedenken, dass der Code, den ich schreibe, vergänglich ist. Dieser Raum kann oft sehr streitsüchtig sein, wenn wir über Werkzeuge, Best Practices und das neue heiße Ding sprechen. Ein Gefühl der Dringlichkeit, den "besten" Ansatz zu übernehmen, übt immensen Druck aus, wenn wir Projekte planen. Wir sprechen in Absoluten mit einem Hauch von Permanenz und übersehen oft, wie veraltet unsere Meinungen schon in naher Zukunft klingen werden. Die Einsätze sind letztendlich nie so hoch, wie sie sich anfühlen, wenn Sie Entscheidungen über Werkzeuge treffen.
Ich ziehe es vor, an einem Ort zu sein, an dem ich ständig erkenne, dass der Code, den ich schreibe, vorübergehend ist, dass die Technologie schneller wächst, als ich individuell mithalten kann, und dass ich niemals Fachkenntnisse in allem haben muss. Hier finde ich Trost in dem Wissen, dass der beste Code, den ich schreibe, vor mir liegt und dass die beste Website, die ich jetzt machen kann, die nächste ist.
Das war eine so bodenständige und erfrischende Lektüre.
Danke, dass du es so gut formuliert hast!