Themen über Bereiche hinweg

Dieselbe Frage kehrt in verschiedenen Bereichen wieder. Diese Tags verlaufen quer zu den acht Feldern.

Planung & Entscheidung

Ein Problem definieren, priorisieren und wählen, was man nicht tut

16 Artikel

Erscheint auch in: Produktgrundlagen · Mobile Apps · Sicherheit · KI in der Praxis · Handwerk, Qualität & Teams

001Von der Idee zu einem lösbaren ProblemBevor Sie Technologie auswählen, schreiben Sie auf, wer unter dem Problem leidet, was diese Person heute stattdessen tut und woran Sie erkennen, dass es gelöst ist.002Der kleinste Prototyp, der etwas beweistEin Prototyp beantwortet eine gefährliche Frage und führt kein Produkt vor — deshalb darf er hässlich, manuell und unvollständig sein.003Eine Spezifikation schreiben, die Entwickler wirklich lesenEine gute Spezifikation beschreibt Verhalten und Abnahmekriterien, keine Designentwürfe — und ihr Umfang misst sich in Seiten, nicht in Dutzenden.004Entscheiden, was man nicht bautDie Fähigkeit, Nein zu sagen, trennt ein ausgeliefertes Produkt von einem, das ewig weiterentwickelt wird.005Wie lange dauert es: Schätzungen ohne IllusionenEine gute Schätzung ist eine Spanne mit sichtbaren Annahmen, die mit dem Wissen wächst — keine einzelne, einmal genannte Zahl.006Bauen, kaufen oder anbindenBauen Sie nur, was Sie unverwechselbar macht; alles andere — kaufen, anbinden oder weglassen.007Nutzerforschung in drei TagenFünf halbstündige Gespräche mit Menschen, die die Arbeit tun, verraten mehr als eine Umfrage mit tausend Antworten.009Technische Schuld: wann aufnehmen, wann tilgenTechnische Schuld ist ein legitimes Finanzierungsmittel — solange sie bewusst aufgenommen, festgehalten wird und einen Termin hat, an dem die Tilgung besprochen wird.010Erste Version: was drin sein mussDie erste Version muss eine Sache durchgängig erledigen, und zwar so, dass man sich darauf verlassen kann.011Wie man priorisiert, wenn alle schreienPriorisierung ist keine geordnete Liste, sondern eine Entscheidungsregel, die alle im Voraus kennen — sonst bestimmt sie, wer am lautesten spricht.012Von der Spezifikation zu Aufgaben, mit denen man anfangen kannEine gute Aufgabe endet in einem Ergebnis, das man ausführen und prüfen kann, und dauert einen bis zwei Tage — nicht eine Woche und nicht eine Stunde.021Nativ, plattformübergreifend oder eine mobile WebsiteDie Wahl bestimmt sich danach, wie viel Sie vom Gerät selbst brauchen, und nach der Teamgröße — nicht danach, welche Technologie dieses Jahr im Trend liegt.061Ein Bedrohungsmodell in einer StundeSkizzieren Sie, was Sie haben, wer es wollen könnte und wo es eine Grenze überschreitet — und Sie erhalten eine echte Prioritätenliste statt eines Bauchgefühls.075Wie man ein Modell wählt — und warum das nicht die erste Entscheidung istBeginnen Sie mit dem stärksten Modell, um zu prüfen, ob die Aufgabe lösbar ist, und steigen erst dann zu einem günstigeren ab, bis die Qualität bricht.097Technologie wählen, ohne sie in zwei Jahren zu bereuenWählen Sie nach dem Team, der Reife und der Gemeinschaft — und was langweilig und vertraut ist, schlägt fast immer, was neu und aufregend ist.100Was wirklich entscheidet, ob ein Projekt gelingtNicht die Technologie und nicht die Teamgröße — sondern die Klarheit des Ziels, kurze Rückkopplungszyklen und eine Person, die für das Entscheiden verantwortlich ist.

Messung

Wissen, ob sich tatsächlich etwas verbessert hat

12 Artikel

Erscheint auch in: Produktgrundlagen · Mobile Apps · Infrastruktur, Cloud & DevOps · KI in der Praxis · Handwerk, Qualität & Teams

001Von der Idee zu einem lösbaren ProblemBevor Sie Technologie auswählen, schreiben Sie auf, wer unter dem Problem leidet, was diese Person heute stattdessen tut und woran Sie erkennen, dass es gelöst ist.002Der kleinste Prototyp, der etwas beweistEin Prototyp beantwortet eine gefährliche Frage und führt kein Produkt vor — deshalb darf er hässlich, manuell und unvollständig sein.008Erfolgskennzahlen, die nicht lügenWählen Sie eine Kennzahl, die an den Wert für den Nutzer gebunden ist, und daneben eine, die Sie davor bewahrt, etwas anderes zu zerbrechen.025Mobile Leistung: Speicher, Akku und das Gefühl von GeschwindigkeitBei Apps entsteht das Gefühl bei der Startzeit und der Scroll-Glätte — und beide zerbrechen an Bildern und Arbeit, die auf dem Hauptthread läuft.029Absturz- und Fehlerüberwachung in einer AppOhne automatische Absturzmeldung erfahren Sie von Problemen aus Store-Bewertungen — also zu spät.052Überwachung und Beobachtbarkeit: wissen, dass etwas brach, vor dem KundenDrei Arten von Signal — Kennzahlen, Protokolle und Spuren — und eine Frage, die sie beantworten müssen: was gerade geschieht und warum.054Cloud-Kosten: wo das Geld verschwindetDer Großteil der Rechnung kommt aus drei Orten: laufenden Ressourcen, die niemand braucht, Speicher, der ohne Richtlinie wächst, und regionsübergreifendem Verkehr.079Evaluation: wie man weiß, dass sich das System verbesserteOhne festen Evaluationssatz ist jede Änderung ein Glaube — und eine Verbesserung in einem Bereich verbirgt eine Regression in einem anderen.081Klassifizierung und Extraktion: die Aufgaben mit dem höchsten ErtragBevor Sie einen Chat bauen, prüfen Sie, ob das Problem eigentlich das Klassifizieren einer Anfrage oder das Extrahieren von Feldern aus einem Dokument ist — zwei einfache Aufgaben mit sofortigem Ertrag.082Halluzinationen: warum sie geschehen und was wirklich hilftEin Modell, das eine Frage ohne Antwort gefragt wird, erzeugt eine plausible Antwort — die Behebung ist nicht, es zu bitten, nicht zu irren, sondern ihm eine Quelle und einen Weg zum Nein zu geben.088Experimente: wie man weiß, dass die Änderung etwas verbesserteVergleichen Sie zwei Versionen auf demselben Verkehr zur selben Zeit — jeder „vorher und nachher“-Vergleich misst auch die Welt, nicht nur Sie.100Was wirklich entscheidet, ob ein Projekt gelingtNicht die Technologie und nicht die Teamgröße — sondern die Klarheit des Ziels, kurze Rückkopplungszyklen und eine Person, die für das Entscheiden verantwortlich ist.

Nutzer

Was auf der Seite des Menschen passiert, der das System benutzt

11 Artikel

Erscheint auch in: Produktgrundlagen · Web & Frontend · Mobile Apps · Sicherheit · KI in der Praxis

007Nutzerforschung in drei TagenFünf halbstündige Gespräche mit Menschen, die die Arbeit tun, verraten mehr als eine Umfrage mit tausend Antworten.014Browser-Leistung: was eine Seite wirklich verlangsamtBei den meisten langsamen Seiten ist nicht der Code der Schuldige, sondern das Gewicht — große Bilder, Schriften und Drittanbieter-Skripte.015Barrierefreiheit: das Minimum, das man nicht auslassen darfDer Großteil der Barrierefreiheit kommt vom korrekten Schreiben von HTML, und die meisten Fehler kommen davon, Standardelemente durch etwas zu ersetzen, das wie sie aussieht.016Responsives Design ohne SchmerzBeginnen Sie beim kleinen Bildschirm, lassen Sie den Inhalt entscheiden, wo er bricht, und gestalten Sie nicht für eine Geräteliste.017Technisches SEO für moderne SeitenVor Schlüsselwörtern stellen Sie sicher, dass die Suchmaschine die Seite erreicht, sie liest und versteht, was sie ist.019Formulare: die Stelle, an der Nutzer am meisten scheiternEin gutes Formular fragt wenig, prüft im richtigen Moment, erklärt einen Fehler dort, wo er auftrat, und löscht nicht das Getippte.020Hebräisch und Rechts-nach-links: was bricht und wie man es behebtDie meisten Rechts-nach-links-Fehler kommen davon, links und rechts statt Anfang und Ende zu verwenden — und von gemischtem Text, der in einer Zeile kollidiert.023Push-Benachrichtigungen, ohne Nutzer zu verlierenEine gerechtfertigte Benachrichtigung ist eine, deren Verpassen der Nutzer bedauern würde — alles andere führt dazu, die Berechtigung abzuschalten, was fast unumkehrbar ist.028Mobile Nutzererfahrung: was anders ist als am großen BildschirmAm Handy steht der Nutzer, hat es eilig, hält mit einer Hand und manchmal in der Sonne — und das ändert jede Entscheidung.063Passwörter, Zwei-Faktor-Authentifizierung und SitzungenSpeichern Sie Passwörter mit einem dedizierten langsamen Algorithmus, ermöglichen Sie Zwei-Faktor-Authentifizierung und machen Sie das Abmelden von allen Geräten möglich.084Eine Oberfläche für ein System entwerfen, das nicht immer recht hatEine gute Oberfläche zeigt wechselnde Sicherheit, erlaubt leichte Korrektur und stellt eine Vermutung nicht als Tatsache dar.

Architektur

Wie Komponenten aufgeteilt sind und miteinander sprechen

16 Artikel

Erscheint auch in: Web & Frontend · Mobile Apps · Backend, APIs & Daten · Infrastruktur, Cloud & DevOps · KI in der Praxis · Handwerk, Qualität & Teams

013Zwischen statischer Seite, servergerenderter Seite und Browser-App wählenJe fester der Inhalt, desto einfacher sollte die Architektur sein — und jede Schicht Dynamik, die man hinzufügt, bezahlt man fortan jeden Tag.018Zustandsverwaltung in einer Web-AppDas meiste, was Zustand genannt wird, sind Serverdaten am falschen Ort — trennen Sie sie, und die halbe Komplexität verschwindet.021Nativ, plattformübergreifend oder eine mobile WebsiteDie Wahl bestimmt sich danach, wie viel Sie vom Gerät selbst brauchen, und nach der Teamgröße — nicht danach, welche Technologie dieses Jahr im Trend liegt.022Offline arbeiten: eine App, die im Aufzug nicht zerbrichtEntwerfen Sie die App unter der Annahme, dass es kein Netz gibt, und Sie erhalten gratis eine App, die sich auch schnell anfühlt, wenn es eines gibt.034Datenbanken: wählen und nicht bereuenIn den meisten Fällen ist eine relationale Datenbank die richtige Antwort, und jede andere Wahl braucht einen Grund, den man in einem Satz nennen kann.036Warteschlangen und HintergrundaufträgeAlles, was länger als eine Sekunde dauert und für die Antwort an den Nutzer nicht nötig ist, gehört in eine Warteschlange, nicht in die Anfrage.037Cache: beschleunigen, ohne veraltete Daten auszuliefernBevor Sie einen Cache hinzufügen, entscheiden Sie, wie lange ein veraltetes Datum noch akzeptabel ist — das ist die einzige Frage, die wirklich zählt.039Ein Dienst oder viele: wann man aufteiltBeginnen Sie mit einem gut geordneten System. Teilen Sie erst auf, wenn es echten Schmerz gibt — Teams, die sich gegenseitig blockieren, oder eine Komponente, die eine andere Skala braucht.040Ein Datenmodell entwerfen, das jahrelang hältEin gutes Modell bildet die Geschäftsrealität ab, nicht den ersten Bildschirm, den man Sie zu bauen bat.042Dateien und ObjektspeicherDateien gehören nicht in die Datenbank und nicht auf die Serverplatte — sie gehören in den Objektspeicher mit signierten Adressen.055Skalierung: horizontal, vertikal und was man wirklich brauchtBevor Sie skalieren, messen Sie, wo der Engpass ist — in den meisten Systemen ist es die Datenbank oder eine einzelne Abfrage, nicht die Zahl der Server.076Ihr Wissen an das Modell anbinden: Abruf ohne große WorteDas Modell kennt Ihre Dokumente nicht — man muss für jede Frage die relevanten Abschnitte finden und dem Prompt beifügen.077Agenten: wann man das System allein handeln lässtEin Agent entscheidet selbst, welche Aktionen er ausführt — und aller Lohn und alles Risiko sitzen in den Berechtigungen, die Sie ihm gaben.087Prozessautomatisierung: wo ein Modell etwas beiträgt und wo es überflüssig istIst der Prozess fest und klar, schreiben Sie Code; ein Modell lohnt sich genau dort, wo Urteil über unstrukturierten Text nötig ist.089Architektur eines modellbasierten SystemsDas Modell ist eine Komponente in einem gewöhnlichen System — und das System darum ist der Großteil der Arbeit und des Risikos.096Namen, Struktur und Code, zu dem man zurückkehren kannCode wird weit mehr gelesen als geschrieben — daher sind ein genauer Name und eine vorhersehbare Struktur mehr wert als jede Cleverness.

Daten

Struktur, Speicherung und Integrität von Informationen

13 Artikel

Erscheint auch in: Web & Frontend · Mobile Apps · Backend, APIs & Daten · Infrastruktur, Cloud & DevOps · Sicherheit · KI in der Praxis

018Zustandsverwaltung in einer Web-AppDas meiste, was Zustand genannt wird, sind Serverdaten am falschen Ort — trennen Sie sie, und die halbe Komplexität verschwindet.022Offline arbeiten: eine App, die im Aufzug nicht zerbrichtEntwerfen Sie die App unter der Annahme, dass es kein Netz gibt, und Sie erhalten gratis eine App, die sich auch schnell anfühlt, wenn es eines gibt.026Lokale Speicherung und sensible Daten auf dem GerätNehmen Sie an, dass das Gerät verloren geht oder kompromittiert wird: Was lokal gespeichert wird, sollte minimal, verschlüsselt und fernwiderrufbar sein.034Datenbanken: wählen und nicht bereuenIn den meisten Fällen ist eine relationale Datenbank die richtige Antwort, und jede andere Wahl braucht einen Grund, den man in einem Satz nennen kann.035Schema-Migrationen ohne AusfallzeitÄndern Sie das Schema in rückwärtskompatiblen Schritten: hinzufügen, füllen, umschalten, und erst am Ende — entfernen.040Ein Datenmodell entwerfen, das jahrelang hältEin gutes Modell bildet die Geschäftsrealität ab, nicht den ersten Bildschirm, den man Sie zu bauen bat.043Suche: wann die Datenbank nicht mehr reichtVolltextsuche mit Rangfolge, Tippfehlern und Mehrfachfilter ist eine eigene Welt — und nicht jedes System braucht sie.046Mit Geld arbeiten: Zahlungen und BelastungenSpeichern Sie nie Kartendaten, vertrauen Sie nie einem Betrag, der vom Client kam, und führen Sie stets ein unveränderliches Ereignisprotokoll.053Sicherung und Wiederherstellung: was nicht getestet ist, existiert nichtEine Sicherung ist keine Richtlinie; eine Richtlinie ist, wie viele Daten man verlieren darf und wie lange man ausfallen darf — und der Beweis, dass Sie es erfüllten.069Datenschutz durch Gestaltung: weniger erfassenDer günstigste Weg, Informationen zu schützen, ist, sie nicht zu erfassen — und jedes erfasste Feld sollte einen Zweck, einen Eigentümer und ein Löschdatum haben.076Ihr Wissen an das Modell anbinden: Abruf ohne große WorteDas Modell kennt Ihre Dokumente nicht — man muss für jede Frage die relevanten Abschnitte finden und dem Prompt beifügen.081Klassifizierung und Extraktion: die Aufgaben mit dem höchsten ErtragBevor Sie einen Chat bauen, prüfen Sie, ob das Problem eigentlich das Klassifizieren einer Anfrage oder das Extrahieren von Feldern aus einem Dokument ist — zwei einfache Aufgaben mit sofortigem Ertrag.083Daten: woher sie kommen und was zu tun ist, wenn es keine gibtIn den meisten Projekten existieren die Daten, sind aber verstreut, unetikettiert und unbereinigt — und das ist die Stufe, die die meiste Zeit frisst.

Performance

Geschwindigkeit, Last und das Gefühl für den Nutzer

11 Artikel

Erscheint auch in: Web & Frontend · Mobile Apps · Backend, APIs & Daten · Infrastruktur, Cloud & DevOps · KI in der Praxis

013Zwischen statischer Seite, servergerenderter Seite und Browser-App wählenJe fester der Inhalt, desto einfacher sollte die Architektur sein — und jede Schicht Dynamik, die man hinzufügt, bezahlt man fortan jeden Tag.014Browser-Leistung: was eine Seite wirklich verlangsamtBei den meisten langsamen Seiten ist nicht der Code der Schuldige, sondern das Gewicht — große Bilder, Schriften und Drittanbieter-Skripte.017Technisches SEO für moderne SeitenVor Schlüsselwörtern stellen Sie sicher, dass die Suchmaschine die Seite erreicht, sie liest und versteht, was sie ist.025Mobile Leistung: Speicher, Akku und das Gefühl von GeschwindigkeitBei Apps entsteht das Gefühl bei der Startzeit und der Scroll-Glätte — und beide zerbrechen an Bildern und Arbeit, die auf dem Hauptthread läuft.031Dateien, Medien und Uploads vom GerätEin Foto von der Kamera wiegt Dutzende Male mehr als nötig — behandeln Sie es auf dem Gerät, bevor es das Netz berührt.037Cache: beschleunigen, ohne veraltete Daten auszuliefernBevor Sie einen Cache hinzufügen, entscheiden Sie, wie lange ein veraltetes Datum noch akzeptabel ist — das ist die einzige Frage, die wirklich zählt.043Suche: wann die Datenbank nicht mehr reichtVolltextsuche mit Rangfolge, Tippfehlern und Mehrfachfilter ist eine eigene Welt — und nicht jedes System braucht sie.045Last: Ratenbegrenzungen und SelbstschutzEin gesundes System verweigert früh und klar, statt langsam unter einer Last zusammenzubrechen, die es nicht tragen kann.055Skalierung: horizontal, vertikal und was man wirklich brauchtBevor Sie skalieren, messen Sie, wo der Engpass ist — in den meisten Systemen ist es die Datenbank oder eine einzelne Abfrage, nicht die Zahl der Server.080Kosten und Latenz in modellbasierten SystemenDer Großteil der Kosten kommt vom eingehenden Text, und der Großteil der Latenz vom ausgehenden — daher unterscheiden sich die beiden Behebungen.086Kleine, lokale und Edge-ModelleWenn das Volumen groß ist, die Latenz kritisch oder die Daten nicht hinausdürfen — schlägt ein kleines Modell auf Ihrer Seite ein großes in der Cloud.

Zuverlässigkeit

Was passiert, wenn etwas kaputtgeht

13 Artikel

Erscheint auch in: Produktgrundlagen · Mobile Apps · Backend, APIs & Daten · Infrastruktur, Cloud & DevOps · KI in der Praxis

010Erste Version: was drin sein mussDie erste Version muss eine Sache durchgängig erledigen, und zwar so, dass man sich darauf verlassen kann.022Offline arbeiten: eine App, die im Aufzug nicht zerbrichtEntwerfen Sie die App unter der Annahme, dass es kein Netz gibt, und Sie erhalten gratis eine App, die sich auch schnell anfühlt, wenn es eines gibt.036Warteschlangen und HintergrundaufträgeAlles, was länger als eine Sekunde dauert und für die Antwort an den Nutzer nicht nötig ist, gehört in eine Warteschlange, nicht in die Anfrage.041Zuverlässigkeit bei Aufrufen an externe DiensteJeder ausgehende Aufruf wird irgendwann fehlschlagen — die einzige Frage ist, ob Sie geplant haben, was dann geschieht.044Ausgehende E-Mail, Nachrichten und WebhooksAusgehende Nachrichten sind eine öffentliche Schnittstelle: Sie brauchen eine Warteschlange, erneute Versuche und eine Erfassung, was an wen gesendet wurde.045Last: Ratenbegrenzungen und SelbstschutzEin gesundes System verweigert früh und klar, statt langsam unter einer Last zusammenzubrechen, die es nicht tragen kann.051Deployment-Strategien: Blau-Grün, Canary und stufenweiseEin gutes Deployment misst sich an der Fähigkeit, schnell zurückzurollen, nicht an der Geschwindigkeit des Hinausgehens.053Sicherung und Wiederherstellung: was nicht getestet ist, existiert nichtEine Sicherung ist keine Richtlinie; eine Richtlinie ist, wie viele Daten man verlieren darf und wie lange man ausfallen darf — und der Beweis, dass Sie es erfüllten.056Netzwerke und Zertifikate: Domäne, DNS und HTTPSDie meisten „die Seite lädt nicht“-Vorfälle sind eine Domäne, ein abgelaufenes Zertifikat oder das Routing — nicht der Code.058Vorfalluntersuchung ohne SchuldsucheNach jedem Vorfall lohnt sich eine Stunde schriftlicher Untersuchung, die sich auf das System und nicht die Person konzentriert — sonst kehrt derselbe Vorfall wieder.059Hohe Verfügbarkeit und KatastrophenwiederherstellungEntscheiden Sie, wie viel eine Stunde Ausfallzeit Sie kostet, und erst dann, wie viel Redundanz Sie kaufen.082Halluzinationen: warum sie geschehen und was wirklich hilftEin Modell, das eine Frage ohne Antwort gefragt wird, erzeugt eine plausible Antwort — die Behebung ist nicht, es zu bitten, nicht zu irren, sondern ihm eine Quelle und einen Weg zum Nein zu geben.089Architektur eines modellbasierten SystemsDas Modell ist eine Komponente in einem gewöhnlichen System — und das System darum ist der Großteil der Arbeit und des Risikos.

Sicherheit

Wie ein Angreifer denken, bevor einer es tut

19 Artikel

Erscheint auch in: Mobile Apps · Backend, APIs & Daten · Infrastruktur, Cloud & DevOps · Sicherheit · KI in der Praxis

026Lokale Speicherung und sensible Daten auf dem GerätNehmen Sie an, dass das Gerät verloren geht oder kompromittiert wird: Was lokal gespeichert wird, sollte minimal, verschlüsselt und fernwiderrufbar sein.038Authentifizierung und Autorisierung: wer du bist und was du darfstIdentität und Autorisierung sind zwei getrennte Fragen, und die meisten Verstöße kommen davon, dass die zweite in der Oberfläche und nicht im Server geprüft wird.046Mit Geld arbeiten: Zahlungen und BelastungenSpeichern Sie nie Kartendaten, vertrauen Sie nie einem Betrag, der vom Client kam, und führen Sie stets ein unveränderliches Ereignisprotokoll.056Netzwerke und Zertifikate: Domäne, DNS und HTTPSDie meisten „die Seite lädt nicht“-Vorfälle sind eine Domäne, ein abgelaufenes Zertifikat oder das Routing — nicht der Code.057Geheimnisse und Schlüssel verwaltenEin Geheimnis im Code-Repository ist ein durchgesickertes Geheimnis — auch wenn das Repo privat ist und auch wenn Sie es danach löschten.061Ein Bedrohungsmodell in einer StundeSkizzieren Sie, was Sie haben, wer es wollen könnte und wo es eine Grenze überschreitet — und Sie erhalten eine echte Prioritätenliste statt eines Bauchgefühls.062Die zehn Fehler, die in jedem Audit wiederkehrenDie meisten Befunde sind nicht raffiniert: nicht auf dem Server geprüfte Berechtigungen, Eingabe, die in eine Abfrage gelangt, und alte Bibliotheken.063Passwörter, Zwei-Faktor-Authentifizierung und SitzungenSpeichern Sie Passwörter mit einem dedizierten langsamen Algorithmus, ermöglichen Sie Zwei-Faktor-Authentifizierung und machen Sie das Abmelden von allen Geräten möglich.064Injektionen: eine Anweisung von Daten trennenJeder Ort, an dem eine Zeichenkette vom Nutzer in einen Befehl zusammengesetzt wird, ist ein Loch — und die Behebung ist Parameter, nicht Filterung.065Öffentliche Schnittstellen absichernEine ins Internet offene Schnittstelle wird von Tag eins an automatisch gescannt — nehmen Sie an, dass jede Route aufgerufen wird, in jeder Reihenfolge, mit jeder Eingabe.066Die Lieferkette des CodesIhr Code ist eine Minderheit dessen, was in der Produktion läuft — der meiste Risiko liegt in den Paketen, die Sie brachten, und den Werkzeugen, die sie bauten.067Verschlüsselung: wann, wo und wie man sich nicht irrtVerwenden Sie bekannte Bibliotheken mit modernen Standardwerten und erfinden Sie nichts — fast jeder Verschlüsselungsfehler ist ein Anwendungsfehler.068Cloud-Berechtigungen: die wichtigste Regel ist das MinimumDie meisten schweren Cloud-Vorfälle beginnen mit einer Identität, die mehr Berechtigungen hat, als sie braucht, und keinen Ablauf.070Browser-Sicherheit: Schutzmaßnahmen, die in Headern gesetzt werdenEin großer Teil der clientseitigen Angriffe wird durch einige Antwort-Header und einige korrekte Cookie-Einstellungen blockiert.071Teamsicherheit: wo die meisten Einbrüche beginnenAuch ein sicheres System wird über das Gerät eines Mitarbeiters, eine Phishing-E-Mail oder ein Konto ohne Zwei-Faktor-Authentifizierung eingebrochen.072Sicherheitstests: was bestellen und wannAutomatisches Scannen ist laufende Hygiene; ein Penetrationstest ist ein fokussiertes Ereignis — und beide brauchen ein geschriebenes Ziel.073Sicherheit in modellbasierten SystemenEin Modell fügt zwei neue Risiken hinzu: externen Inhalt, der als Anweisung ausgelegt wird, und Ausgabe, die ungeprüft an eine sensible Stelle gelangt.074Sich auf einen Vorfall vorbereiten, bevor er geschiehtWährend eines Vorfalls ist keine Zeit zu entscheiden, wer entscheidet — das an einem ruhigen Morgen geschriebene Papier ist der Unterschied zwischen einer Stunde und einer Woche.077Agenten: wann man das System allein handeln lässtEin Agent entscheidet selbst, welche Aktionen er ausführt — und aller Lohn und alles Risiko sitzen in den Berechtigungen, die Sie ihm gaben.

Datenschutz

Weniger erfassen und schützen, was erfasst wurde

5 Artikel

Erscheint auch in: Mobile Apps · Infrastruktur, Cloud & DevOps · Sicherheit · KI in der Praxis

026Lokale Speicherung und sensible Daten auf dem GerätNehmen Sie an, dass das Gerät verloren geht oder kompromittiert wird: Was lokal gespeichert wird, sollte minimal, verschlüsselt und fernwiderrufbar sein.060Protokolle: richtig speichern und schnell findenEin gutes Protokoll ist strukturiert, durch eine Anfrage-ID gekennzeichnet, für eine definierte Zeit aufbewahrt und frei von persönlichen Informationen, die keinen Grund haben, dort zu sein.067Verschlüsselung: wann, wo und wie man sich nicht irrtVerwenden Sie bekannte Bibliotheken mit modernen Standardwerten und erfinden Sie nichts — fast jeder Verschlüsselungsfehler ist ein Anwendungsfehler.069Datenschutz durch Gestaltung: weniger erfassenDer günstigste Weg, Informationen zu schützen, ist, sie nicht zu erfassen — und jedes erfasste Feld sollte einen Zweck, einen Eigentümer und ein Löschdatum haben.085Verzerrung, Fairness und Verantwortung beim Einsatz von ModellenEin Modell spiegelt, was es sah — daher erfordern Entscheidungen, die Menschen betreffen, eine Prüfung über Segmente, einen Menschen in der Schleife und Dokumentation.

Kosten

Was es kostet und warum es wächst

7 Artikel

Erscheint auch in: Produktgrundlagen · Mobile Apps · Backend, APIs & Daten · Infrastruktur, Cloud & DevOps · KI in der Praxis

006Bauen, kaufen oder anbindenBauen Sie nur, was Sie unverwechselbar macht; alles andere — kaufen, anbinden oder weglassen.031Dateien, Medien und Uploads vom GerätEin Foto von der Kamera wiegt Dutzende Male mehr als nötig — behandeln Sie es auf dem Gerät, bevor es das Netz berührt.042Dateien und ObjektspeicherDateien gehören nicht in die Datenbank und nicht auf die Serverplatte — sie gehören in den Objektspeicher mit signierten Adressen.054Cloud-Kosten: wo das Geld verschwindetDer Großteil der Rechnung kommt aus drei Orten: laufenden Ressourcen, die niemand braucht, Speicher, der ohne Richtlinie wächst, und regionsübergreifendem Verkehr.075Wie man ein Modell wählt — und warum das nicht die erste Entscheidung istBeginnen Sie mit dem stärksten Modell, um zu prüfen, ob die Aufgabe lösbar ist, und steigen erst dann zu einem günstigeren ab, bis die Qualität bricht.080Kosten und Latenz in modellbasierten SystemenDer Großteil der Kosten kommt vom eingehenden Text, und der Großteil der Latenz vom ausgehenden — daher unterscheiden sich die beiden Behebungen.086Kleine, lokale und Edge-ModelleWenn das Volumen groß ist, die Latenz kritisch oder die Daten nicht hinausdürfen — schlägt ein kleines Modell auf Ihrer Seite ein großes in der Cloud.

Tests

Fehler abfangen, bevor sie in die Produktion gelangen

6 Artikel

Erscheint auch in: Infrastruktur, Cloud & DevOps · Sicherheit · KI in der Praxis · Handwerk, Qualität & Teams

050Eine automatisierte Bau- und Deployment-PipelineJeder Merge sollte dieselbe Folge auslösen: Bau, Tests, Sicherheitsprüfungen, Deployment — ohne einen einzigen manuellen Schritt dazwischen.062Die zehn Fehler, die in jedem Audit wiederkehrenDie meisten Befunde sind nicht raffiniert: nicht auf dem Server geprüfte Berechtigungen, Eingabe, die in eine Abfrage gelangt, und alte Bibliotheken.072Sicherheitstests: was bestellen und wannAutomatisches Scannen ist laufende Hygiene; ein Penetrationstest ist ein fokussiertes Ereignis — und beide brauchen ein geschriebenes Ziel.079Evaluation: wie man weiß, dass sich das System verbesserteOhne festen Evaluationssatz ist jede Änderung ein Glaube — und eine Verbesserung in einem Bereich verbirgt eine Regression in einem anderen.091Tests: wie viele, welche und was sich nicht lohntInvestieren Sie in eine Mehrheit von Tests, die Ihre Logik ausführen, einige Integrationstests und sehr wenige End-to-End-Tests.098Qualität ohne Bürokratie: wie man nicht bricht, was funktioniertRegressionen werden durch drei Dinge verhindert: automatische Tests, kleine häufige Veröffentlichungen und die Fähigkeit, schnell zurückzurollen.

Deployment

Wie Code live geht und wie man zurückrollt

8 Artikel

Erscheint auch in: Mobile Apps · Backend, APIs & Daten · Infrastruktur, Cloud & DevOps · Handwerk, Qualität & Teams

030Stufenweise Ausrollung und FähigkeitsschalterVeröffentlichen Sie an einen kleinen Prozentsatz, beobachten Sie die Kennzahlen und erweitern Sie — und behalten Sie die Fähigkeit, ein Feature ohne Versionsveröffentlichung abzuschalten.035Schema-Migrationen ohne AusfallzeitÄndern Sie das Schema in rückwärtskompatiblen Schritten: hinzufügen, füllen, umschalten, und erst am Ende — entfernen.047Umgebungen: Entwicklung, Test und ProduktionDrei Umgebungen, aus derselben Definition gebaut, die sich nur in Konfiguration und Daten unterscheiden — jeder andere Unterschied ist ein Fehler, der darauf wartet, gefunden zu werden.048Container: was sie bringen und wann sie überflüssig sindEin Container verpackt die App mit allem, was sie zum Laufen braucht, damit sie sich überall gleich verhält.049Infrastruktur als CodeKönnen Sie die Umgebung nicht aus einer Datei in der Versionskontrolle reproduzieren, haben Sie keine Infrastruktur, sondern eine Geschichte von Klicks.050Eine automatisierte Bau- und Deployment-PipelineJeder Merge sollte dieselbe Folge auslösen: Bau, Tests, Sicherheitsprüfungen, Deployment — ohne einen einzigen manuellen Schritt dazwischen.051Deployment-Strategien: Blau-Grün, Canary und stufenweiseEin gutes Deployment misst sich an der Fähigkeit, schnell zurückzurollen, nicht an der Geschwindigkeit des Hinausgehens.098Qualität ohne Bürokratie: wie man nicht bricht, was funktioniertRegressionen werden durch drei Dinge verhindert: automatische Tests, kleine häufige Veröffentlichungen und die Fähigkeit, schnell zurückzurollen.

Überwachung

Wissen, was gerade passiert und warum

4 Artikel

Erscheint auch in: Mobile Apps · Infrastruktur, Cloud & DevOps · KI in der Praxis

029Absturz- und Fehlerüberwachung in einer AppOhne automatische Absturzmeldung erfahren Sie von Problemen aus Store-Bewertungen — also zu spät.052Überwachung und Beobachtbarkeit: wissen, dass etwas brach, vor dem KundenDrei Arten von Signal — Kennzahlen, Protokolle und Spuren — und eine Frage, die sie beantworten müssen: was gerade geschieht und warum.060Protokolle: richtig speichern und schnell findenEin gutes Protokoll ist strukturiert, durch eine Anfrage-ID gekennzeichnet, für eine definierte Zeit aufbewahrt und frei von persönlichen Informationen, die keinen Grund haben, dort zu sein.090Ein KI-System über die Zeit betreibenModelle werden ersetzt, Dokumente ändern sich und Nutzer lernen, anders zu fragen — ein sechs Monate unberührtes System ist fast immer schlechter.

Dokumentation

Was sich aus dem Code nicht ableiten lässt

6 Artikel

Erscheint auch in: Produktgrundlagen · Backend, APIs & Daten · KI in der Praxis · Handwerk, Qualität & Teams

003Eine Spezifikation schreiben, die Entwickler wirklich lesenEine gute Spezifikation beschreibt Verhalten und Abnahmekriterien, keine Designentwürfe — und ihr Umfang misst sich in Seiten, nicht in Dutzenden.032Eine Schnittstelle entwerfen, mit der man leben kannEine gute Schnittstelle ist vorhersehbar, konsistent und langweilig — jede Überraschung darin wird zu einer wiederkehrenden Frage und einem Fehler für den Nutzer.078Prompts: eine Spezifikation schreiben, keine BeschwörungEin guter Prompt definiert eine Rolle, Eingabe, Entscheidungsregeln und Ausgabestruktur — und wird wie Code behandelt, in Versionskontrolle und Tests.092Codeprüfung, die verbessert statt verzögertEine gute Prüfung ist klein, schnell und auf Korrektheit und Wartbarkeit fokussiert — nicht auf Stilvorlieben, die ein automatisches Werkzeug durchsetzen sollte.094Dokumentation, die Menschen wirklich lesenDokumentieren Sie, was sich aus dem Code nicht ableiten lässt: Entscheidungen, Grenzen und den Weg zum Anfangen — alles andere altert und führt in die Irre.095Einen neuen Entwickler in einer Woche einarbeiten, nicht in einem MonatDie Kennzahl ist, wie lange es bis zur ersten Änderung in der Produktion dauert — und der meiste Verzug sind Zugänge und lokale Einrichtung, nicht das Verstehen von Code.

Prozess & Teams

Wie Menschen zusammenarbeiten, ohne sich zu blockieren

22 Artikel

Erscheint auch in: Produktgrundlagen · Mobile Apps · Backend, APIs & Daten · Infrastruktur, Cloud & DevOps · Sicherheit · KI in der Praxis · Handwerk, Qualität & Teams