Thema: tooling
-
Ein Werkzeug oder eine Skill mit einem Entscheidungsmodell auswählen: Choice zum Rangieren, Noul zum Enthalten
Warum eine Choice über Kandidatenwerkzeuge eine relative Frage beantwortet (welcher Kandidat passt am besten), während ein Noul pro Kandidat eine absolute Frage beantwortet (braucht dieser Zug überhaupt ein Werkzeug), und wie das Skill-Vorschlags-Kochbuch von TypeSafe beides über einen Katalog von 182 Skills kombiniert: eine Anfrage rangiert alle, eine zweite liest die obersten drei und kann alle drei ablehnen.
-
Seed-Daten und Fixtures für lokale Datenbanken: klein, idempotent und mit dem Schema versioniert
Referenzdaten (überall benötigt), Beispieldaten (Entwicklung und Demos) und Testdaten (von Tests erzeugt) trennen; den Seed als idempotenten Code mit Upserts auf natürlichen Schlüsseln schreiben, den Beispieldatensatz klein und benannt halten, ihn sowohl im Setup-Skript als auch in der CI nach den Migrationen ausführen, und Entwicklermaschinen nie mit rohen Produktionsdaten seeden.
-
Eine Continuous-Integration-Pipeline gestalten
Eine CI-Pipeline sollte schnell, selbsttestend und für jede Änderung identisch sein: aus einem sauberen Checkout bauen, Linter und Tests in Stufen ausführen, laut fehlschlagen und die Gesamtzeit so kurz halten, dass Personen darauf warten.
-
CI und lokale Prüfungen identisch halten: ein Einstiegspunkt, festgepinnte Werkzeuge, derselbe Container
Eine Prüfung, die lokal besteht, sollte auch in der CI bestehen und umgekehrt: jede Prüfung einmal als benannte Aufgabe definieren, die Toolchain in einem committeten Manifest festpinnen, aus dem sowohl der Bootstrap als auch die Pipeline installieren, die CI im selben Container-Image wie die Entwicklungsumgebung ausführen, Locale und Zeitzone fixieren und jeden nur in der CI auftretenden Fehlschlag als zu beseitigenden Paritätsfehler behandeln, bevor das Symptom behoben wird.
-
Automatisierte Formatierung und Linting als Team-Vereinbarung
Layout an einen Formatter und mechanische Prüfungen an einen Linter zu delegieren, nimmt Stildiskussionen aus dem Review; EditorConfig, PEP 8 und Werkzeuge wie Ruff zeigen, wie sich die Vereinbarung im Repository festhalten lässt.
-
Konfigurationsformate wählen: JSON, YAML oder TOML
JSON (RFC 8259) ist streng und überall lesbar, kennt aber keine Kommentare; YAML ist gut lesbar, doch unzitierte Werte werden nach Muster typisiert; TOML ist für Konfiguration entworfen, mit Kommentaren, expliziten Typen und Tabellen. Wer die Datei bearbeitet und was sie liest, entscheidet – und jedes Format braucht nach dem Parsen eine Prüfung gegen ein Schema.
-
Ein selbstprüfendes Ersttags-Setup-Skript: Bootstrap, Doctor, Smoke-Test
Ein Befehl nach dem Klonen erzeugt entweder eine funktionierende Umgebung oder eine präzise Liste dessen, was fehlt und wie es behoben wird: Ein nur lesendes Doctor-Skript prüft jede Voraussetzung, ein idempotentes Bootstrap installiert nur das, was die Prüfungen als fehlend melden, und ein Smoke-Test entscheidet über den Exit-Status; die CI führt es auf einer sauberen Maschine aus, damit es zwischen Neueinsteigenden nicht veraltet.
-
Schrittweise Typisierung in Python mit Type Hints
Type Hints (PEP 484) sind optionale Annotationen, die von externen Werkzeugen wie mypy geprüft werden; sie schrittweise in eine Codebasis einzuführen deckt Schnittstellenfehler auf und dokumentiert die Absicht, ohne das Laufzeitverhalten zu verändern.
-
Ein Konfigurationsformat wählen: JSON, YAML oder TOML
JSON ist streng und universell, kennt aber keine Kommentare; YAML ist gut lesbar, hat aber eine überraschende implizite Typisierung; TOML ist explizit und kommentarfreundlich für flache bis mässig verschachtelte Strukturen. Die Wahl richtet sich danach, wer die Datei bearbeitet und was sie einliest.
-
EditorConfig and committed editor settings: the small conventions that stop whitespace diffs
A .editorconfig file fixes indentation, line endings, charset and final newlines per file type across editors, before any formatter runs; editor workspace settings committed next to it should encode project decisions such as format-on-save, not personal preferences.
-
Virtual environments: one interpreter state per project
A virtual environment is a private site-packages tied to an interpreter; creating one per project prevents version conflicts and makes the dependency set reproducible and disposable.
-
Dev containers: devcontainer.json as a reproducible development environment
A devcontainer.json describes the container an editor, cloud workspace or CI runner should build for a repository: image or Dockerfile, features, forwarded ports, lifecycle commands and editor customisations. The open specification at containers.dev makes the same file usable locally, in hosted workspaces and in pipelines, so the toolchain is pinned with the code instead of living on each host.
-
Which pre-commit hooks survive a year in a team repository, and which get removed or routinely bypassed?
Open question: Git's pre-commit hook can be bypassed with --no-verify, so a local hook only helps while contributors keep it; which hook types (formatters, linters, secret scanners, test subsets) have stayed in use for a year or more in team repositories, which were removed or moved to CI, and how often were they bypassed?
-
Git hooks for fast local checks
Client-side hooks such as pre-commit run formatters and quick linters before a commit exists; they save review time but must stay fast, must not be the only gate, and are not versioned by Git itself.
-
Task runners beyond make: just, npm scripts and Invoke for project commands
A task runner gives a project one place for its commands so that people, agents and CI invoke the same names; just stores recipes in a justfile with make-like syntax and no timestamp logic, npm scripts live in package.json with pre and post hooks, and Invoke turns @task functions in a tasks.py into a command line. Pick the one that needs no extra toolchain, keep recipes short, and let CI call them.
Maschinenlesbar: JSON