Freizeitprojekt - TFLDs Digitaler Garten

> For the English translation see [[#^leisure|Leisure Project]] down below. Bei **Freizeitprojekten** handelt es sich um Projekte, an welchen ich in meiner Freizeit arbeite. Mit diesem Umstand gehen einige Einschränkungen einher, und auch einige Grundsätze, welche sich davon ableiten. Diese werden auf dieser Seite dokumentiert. Folgende Hinweise können verwendet werden, um darauf hinzuweisen, dass es sich um ein solches Freizeitprojekt handelt: > **Freizeitprojekt** > Dies ist ein [Freizeitprojekt](https://garten.tfld.dev/Freizeitprojekt#Freizeitprojekt). Es stehen nur begrenzte Mittel für seine Entwicklung und Pflege bereit, was zu Einschränkungen führt. Der vorige Link führt Sie zu einer ausführlicheren Erklärung. > **Leisure Project** > This is a [leisure project](https://garten.tfld.dev/Freizeitprojekt#^leisure). The resources for its development and maintenance are limited, which place several restrictions on it. The aforementioned link leads you to a more detailed explanation. ## Freizeitprojekt Bei dem Projekt, dass auf diese Seite verwiesen hat, ist ein _Freizeitprojekt_. Sein Betreiber kümmert sich in seiner Freizeit um seine Umsetzung bzw. Pflege. Das Projekt ist nicht der komplette Lebensinhalt des Betreibers, und er will seine beschränkte Freizeit auch nicht ausschließlich mit dessen Betreuung verbringen. Dies bedeutet, dass die Zeit, die für das Projekt zur Verfügung steht, streng limitiert und stark segmentiert ist. Die Erstellung und Pflege von Software ist normalerweise sehr zeitaufwändig, viele der üblichen Vorgehensweisen sind also für dieses Projekt nicht geeignet. Stattdessen richtet sich dieses Projekt nach folgenden Grundsätzen: 1. **Klare Ziele:** Im Anbetracht des limitieren Zeitbudgets ist für dieses Projekt kaum etwas so gefährlich wie [Feature Creep](https://en.wikipedia.org/wiki/Feature_creep). Als Gegenmaßnahme wurden für das Projekt klare Ziele definiert. Alles, was nicht zu diesen gehört, ist ausdrücklich nicht Teil des Projekts. Auch logische Erweiterungen werden nicht umgesetzt, es sei denn sie sind _absolut trivial_. 2. **Ausführliche Dokumentation:** Durch die langen Zeiträume zwischen Arbeiten am Projekt ist es unvermeidlich, dass Wissen verloren geht. Die Wiederbeschaffung durch lesen und interpretieren des Quellcodes ist zeitaufwändig, und steht der eigentlichen Arbeit im Weg. Daher muss _von Anfang an_ alles ausführlich dokumentiert werden. 3. **Umfassende Tests:** Es ist unvermeidlich, dass sich bei der Programmierung Fehler einschleichen, insbesondere wenn man den bereits erwähnten Wissensverlust bedenkt. Die Fehlersuche, insbesondere bei Regressionen, ist meist langwierig und nervig, und steht der eigentlichen Arbeit im Weg. Daher müssen _von Anfang an_ umfassende Tests erstellt werden. 4. **Minimale Abhängigkeiten:** Oftmals sind Abhängigkeiten unvermeidbar, können Zeit sparen und die Projektkomplexität verringern. Dies alles hat jedoch den Preis, dass man sich dann auch um sie kümmern muss. Insbesondere in schnelllebigen Ökosystemen kann dies zum Problem werden, wenn zwischen zwei Projekt-Wartungsintervallen mehrere Monate vergehen. Daher werden nur stabile, verlässlichen Abhängigkeiten verwendet, und diese auch nur dann, wenn es unbedingt nötig ist. 5. **Minimale Entwicklungsumgebung:** Zeit, die mit der Konfiguration oder Wartung von Entwicklungswerkzeugen verbracht wird, ist Zeit, in der nicht am eigentlichen Projekt gearbeitet wird. Um diese zu minimieren werden die Entwicklungswerkzeuge auf ein Minimum beschränkt. Bsp.: für Rust ein Editor und `cargo`; für Nur-Client-JS-Apps ein Editor, ein Webserver und ein Browser. 6. **Baseline (nur Web):** Auf allen erdenklichen Gerät/Betriebssystem/Browser-Kombinationen zu testen ist äußerst zeitaufwändig, und für dieses Projekt nicht möglich. Stattdessen verwendet es gezielt nur Funktionen, die Teil der [Baseline](https://developer.mozilla.org/de/docs/Glossary/Baseline/Compatibility) sind, und verlässt sich auf deren Interoperabilität. Ist etwas _widely available_ wird es einfach hergenommen, ohne Verfügbarkeitsprüfung. Ist etwas nur _newly available_, wird es nur mit Verfügbarkeitsprüfung verwendet. Der enge Zeitrahmen und diese Prinzipien bringen natürlich auch einige Einschränkungen mit sich. Diese sind jedoch der Einstellung des Projekts vorzuziehen. Konkret sind diese: - Wenig bis kein direkter Support für Anwender - Lange Wartezeit für neue Funktionen und Fehlerkorrekturen - **Entgangene Optimierungen:** Insbesondere bei JavaScript könnte man mittels eines Bauvorgangs einiges an Performance herauskitzeln, z.B. durch _Tree Shaking_ oder _Minification_. Kompilierte Sprachen sind davon weniger stark betroffen. - Manche möglichen Funktionen werden nicht umgesetzt - Manche Arten von Tests sind unmöglich <section lang="en-UK"> <h2>Leisure Project</h2> The project, that linked to this page, is a leisure project. Its maintainer is developing and maintaining it in their free time. The maintainers life is not solely focused on this project, and they don't want to spend their limited free time exclusively on it either. This means the time available for it is strictly limited and highly segmented. The development and maintenance of software is usually very time consuming, and most of the common methods are therefore not suitable for this project. Instead, its development is guided by these principles: <ol> <li>Clear Goals: Given the limited time budget, almost nothing is as dangerous to this project as <a href="https://en.wikipedia.org/wiki/Feature_creep">Feature Creep</a>. As a remedy clear goals have been defined for this project. Everything that isn't part of those ist explicitly not part of this project. Even logical extensions won't be implemented, unless they are absolutely trivial.</li> <li>Extensive Documentation: The long intervals between work being done on the project mean that forgetting important information is inevitable. Restoring that knowledge, by reading and interpreting the source code, takes a long time, and doesn't advance the project. Therefore everything must be extensively documented from the beginning.</li> <li>Exhaustive Tests: It is equally inevitable that mistakes are made during programming, especially when one takes the aforementioned information loss into account. Debugging is slow and annoying, and doesn't advance the project. Therefore exhaustive tests have to be created from the beginning.</li> <li>Minimal Dependencies: Dependencies often are unavoidable, and can save time and reduce project complexity. These advantages have a price, though, which is payed in keeping those integrations up-to-date and functional. This is especially problematic in fast moving ecosystems, if there can be several months between two project maintenance intervals. For this reason only stable, reliable dependencies are used, and only when absolutely necessary.</li> <li>Minimal Development Environment: Time used to configure or maintain development tools is time not spent on advancing the project. To minimise this, only the required minimum of them are used. Example: for Rust an editor and <code>cargo</code>; for client side only JavaScript applications an editor, a web server and a browser.</li> <li>Baseline (web only): Testing for all possible device/os/browser combinations is incredibly time consuming, and not an option for this project. Instead, it will only use <a href="https://developer.mozilla.org/en-US/docs/Glossary/Baseline/Compatibility">Baseline</a> functionality, relying on that to be truly interoperable. Things that are widely available are used as is, without feature detection. Things that are just newly available are used only with feature detection.</li> </ol> The limited available time and these principles naturally come with some limitations. However, those are preferable to an abandonment of the project. They specifically are: <ul> <li>Little to no direct support for users</li> <li>Long waiting times for new features and bug fixes</li> <li>Missed optimisation opportunities: Especially in JavaScript a build step can improve runtime performance, for example through tree shaking or minification. Compiled languages are less heavily affected by this.</li> <li>Some possible features won't be implemented</li> <li>Some kinds of tests are impossible</li> </ul> </section> ^leisure