원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Wer ohne Mentor alleine Frontend-Entwicklung betreibt, wird oft von technischen Zweifeln gehetzt. Man hat das Buch zu Clean Code neben sich liegen, grübelt über die perfekte Abstraktion und wiederholt am Ende das Muster, kurz vor Sprint-Ende in den Burnout zu geraten. Was es braucht, ist keine fehlerfreie Architektur, sondern realistische Kriterien, um funktionierende Produkte rechtzeitig auszuliefern.
Sandy Metz, Expertin für Software-Design, weist darauf hin, dass die Kosten für das Beseitigen einer falschen Abstraktion weitaus höher sind als die Kosten für die Pflege von dupliziertem Code. Tatsächlich hat auch Dan Abramov davor gewarnt, dass übertriebene Code-Wiederverwendung die Flexibilität von Komponenten zerstört.
Probleme durch einfaches Kopieren von Code lassen sich in der Regel innerhalb von rund 50 Minuten in der jeweiligen Datei beheben. Voreilig erstellte gemeinsame Hooks oder Vererbungsstrukturen hingegen erzeugen schon bei minimalen Änderungen an den Anforderungen unzählige if-else-Verzweigungen. Am Ende dauert allein die Suche nach Bugs über zwei Wochen.
Die Entscheidung, ob refaktorisiert wird, stützt sich auf Martin Fowlers Quadranten der technischen Schulden und Adams Donahues Hotspot-Analyse.
| Bereich | Kriterium (Komplexität und Änderungshäufigkeit) | Vorgehensweise |
|---|---|---|
| Sofortige Korrektur | Hoher geschäftlicher Einfluss × Hohe Änderungshäufigkeit | Tests schreiben und Schnittstellen bereinigen unmittelbar nach Funktionsimplementierung, dann veröffentlichen |
| Optionale Korrektur | Hoher geschäftlicher Einfluss × Geringe Änderungshäufigkeit | Als Schulden-Ticket im Backlog registrieren |
| Direkt veröffentlichen | Geringer geschäftlicher Einfluss × Hohe Änderungshäufigkeit | Nur minimales Verhalten verifizieren und veröffentlichen, keine Abstraktion |
| Arbeit zurückstellen | Geringer geschäftlicher Einfluss × Geringe Änderungshäufigkeit | Korrekturen selbst bei unsauberem Code weglassen |
Durch Anwendung dieser Kriterien lässt sich die Zeit für unnötige Verallgemeinerungsarbeiten reduzieren und die gesamte Entwicklungsgeschwindigkeit steigern.
Stilistische Hinweise wie Variablenamen, Zeilenumbrüche oder Regelverstöße gegen den Linter sollten durch Tools herausgefiltert werden.
Laut einer Studie von SmartBear, die 2.500 Code-Reviews von Cisco Systems analysierte, werden 70 bis 90 Prozent der Fehler entdeckt, wenn der auf einmal überprüfte Code-Umfang unter 200 Zeilen liegt. Wenn der Autor als Kommentar im PR direkt den Grund für die Änderung hinterlässt, sinkt die Fehlerdichte im Durchschnitt um 30 Prozent.
`javascript
// eslint.config.js
import js from "@eslint/js";
import globals from "globals";
import tseslint from "typescript-eslint";
import pluginReact from "eslint-plugin-react";
import pluginReactHooks from "eslint-plugin-react-hooks";
import eslintConfigPrettier from "eslint-config-prettier/flat";
export default tseslint.config(
{ ignores: ["dist/", "node_modules/", "build/"] },
js.configs.recommended,
...tseslint.configs.recommended,
pluginReact.configs.flat.recommended,
eslintConfigPrettier,
{
files: ["**/*.{js,jsx,ts,tsx}"],
languageOptions: {
ecmaVersion: "latest",
sourceType: "module",
globals: globals.browser,
},
plugins: {
"react-hooks": pluginReactHooks,
},
rules: {
"react/react-in-jsx-scope": "off",
"react/prop-types": "off",
"react-hooks/rules-of-hooks": "error",
"react-hooks/exhaustive-deps": "warn",
"@typescript-eslint/no-unused-vars": ["error", { argsIgnorePattern: "^_" }],
"@typescript-eslint/no-explicit-any": "warn",
},
settings: {
react: { version: "detect" },
},
}
);
`
Wird diese Konfiguration im Repository angewendet, lassen sich stilbezogene Review-Rückmeldungen reduzieren und der Fokus auf die eigentliche Logikprüfung legen.
Wenn man während der Funktionsentwicklung gleichzeitig die Struktur umbaut, geht der Arbeitskontext verloren. Einer Engineering-Studie von Google zufolge verkürzt sich die Wartezeit auf Code-Reviews von 48 auf 4 Stunden, wenn PRs klein aufgeteilt und die Arbeitsabsichten explizit angegeben werden.
Die tägliche Arbeitszeit wird in steuerbare Sitzungen unterteilt:
`markdown
`
Dies lenkt die Aufmerksamkeit der Reviewer weg von nebensächlichen Stilen hin zur Kernlogik und verkürzt die Freigabezeit.
Das Umschreiben von Alcode in einem einzigen großen Schritt erhöht das Risiko von Ausfällen in der Produktionsumgebung. Michael Feathers rät, bei der Modifikation von Legacy-Code zunächst Charakterisierungstests zu schreiben, die das aktuelle Ein- und Ausgabeverhalten fixieren, anstatt die gesamte Struktur umzubauen.
Um zu verhindern, dass bei einem Laufzeitfehler der gesamte Bildschirm weiß bleibt und einfriert, werden Error Boundaries eingerichtet.
`typescript
// components/ErrorBoundary.tsx
import React, { Component, ErrorInfo, ReactNode } from "react";
import * as Sentry from "@sentry/react";
interface Props {
children: ReactNode;
fallbackUI?: ReactNode;
}
interface State {
hasError: boolean;
}
export class GlobalErrorBoundary extends Component<Props, State> {
public state: State = { hasError: false };
public static getDerivedStateFromError(_: Error): State {
return { hasError: true };
}
public componentDidCatch(error: Error, errorInfo: ErrorInfo) {
Sentry.captureException(error, { extra: { componentStack: errorInfo.componentStack } });
}
public render() {
if (this.state.hasError) {
return (
this.props.fallbackUI || (
Bitte aktualisieren Sie die Seite oder versuchen Sie es später noch einmal.
`
`bash
git revert HEAD --no-edit
git push origin main
`
Arbeitseinheiten klein halten und eine Umgebung schaffen, in der man im Fehlerfall zurückkehren kann – das macht die Angst vor Code-Änderungen kontrollierbar. Ein funktionierendes System rechtzeitig zu liefern ist wichtiger als eine perfekte Struktur; das ist das Fundament praktischer Ingenieurskunst.
