Hva gjør et godt nedslagsplandokument for et programvareutviklingsprosjekt? Hva er forskjellen på en god plan og en god en? Jeg maser stadig om hvordan jeg bruker 85 %+ av tiden og energien min på planleggingsfasene. Hva innebærer det egentlig? Det er vanskelig å forklare abstrakt; Du trenger et håndfast eksempel for virkelig å illustrere nyansene. Så jeg tenkte jeg skulle dele et godt eksempel fra i dag. Dette tar også opp et nylig spørsmål jeg har fått om tilnærmingen min. Folk ser ut til å tro at man må gjøre alt i prosjektet på én gang. Og i min tilnærming er det sant, men bare for versjon 1! Hvis du bestemmer deg for å legge til nye funksjoner eller endre hvordan ting fungerer, kan du selvfølgelig gjøre det når du har en fungerende versjon 1. Og måten du gjør det på er på samme måte som du lager v1, ved å lage en superdetaljert markdown-plan først og så gjøre den om til perler. Så jeg skal gi deg et eksempel fra Cass, mitt Coding Agent Session Search-program, som er et ganske avansert Rust-program som automatisk oppdager, analyserer, lagrer og indekserer alle tidligere sesjonslogger fra nesten alle kodeagenter der ute. Den tilbyr under 50 ms umiddelbar «søk mens du skriver» på alle disse loggene og har mange andre fine funksjoner. Jeg bestemte meg for at jeg ønsket å legge til en funksjon i Cass som ligner på en funksjon jeg allerede har i MCP Agent Mail og i beads_viewer (bv): muligheten til å eksportere oppsettet ditt som et statisk nettsted som kan leveres via GitHub Pages. Du kan se et eksempel for BV for akkurat dette prosjektet, som er det endelige resultatet av planleggingsprosessen jeg vil beskrive i dette innlegget: Denne funksjonaliteten gjør det veldig raskt og enkelt å generere og distribuere det eksporterte nettstedet ved hjelp av gh-verktøyet. Selve nettstedet består vanligvis av en sqlite-fil og en haug med typescript og wasm som kjører helt i nettleseren, men med veldig god ytelse og fine funksjoner og stil, noe du kan se i eksempelet som nettopp er gitt. Å dele MCP Agent Mail-meldinger eller en haug med perler er én ting, men å dele en haug med kodeagent-sesjonslogger er noe helt annet; disse tingene er ofte fulle av sensitiv informasjon, API-nøkler, forbannelser/skjellsord (i hvert fall mine!), og annet materiale du absolutt ikke vil eksponere for verden. Men GitHub Pages, så bra som det er, fungerer bare for offentlige repoer (forresten, verktøyene mine støtter også Cloudflare Pages, men GH Pages er bedre og enklere for dette brukstilfellet). Så hvordan skal man håndtere disse problemene? Svaret er kryptering: brukeren velger først hvilke kodeagenter som skal inkluderes, hvilke prosjektmapper, tidsperiode osv., og en pakke genereres (merk at denne pakken er i det kanoniske formatet som Cass internt konverterer alle kodeagentmeldinger til fra deres opprinnelige native formater), og deretter oppgir brukeren et passord for kryptering av denne pakken. Så ideen er at selv om repoet og nettsiden er offentlige, vil alle unntatt deg og andre du forteller passordet til bare se et passordfelt og ikke kunne lese noen av meldingene. Når passordet er tastet inn, vil det låse opp et vakkert, responsivt brukergrensesnitt som lar deg enkelt søke gjennom meldingene nesten like raskt og effektivt som Cass gjør. Og hvis du virkelig ikke har noe å skjule, kan du utelate passordet og gjøre alt faktisk offentlig. ...