Mikä tekee hyvästä alennussuunnitelmasta ohjelmistokehitysprojektiin? Mikä on ero hyvän ja loistavan suunnitelman välillä? Puhun jatkuvasti siitä, kuinka käytän 85 %+ ajastani ja energiastani suunnitteluvaiheisiin. Mitä se tarkalleen ottaen tarkoittaa? Sitä on vaikea selittää abstraktisti; Tarvitset konkreettisen esimerkin, jotta hienovaraiset yksityiskohdat todella havainnollistuvat. Joten ajattelin jakaa hyvän esimerkin tältä päivältä. Tämä vastaa myös äskettäiseen kysymykseen, jonka olen saanut lähestymistavastani. Ihmiset tuntuvat olevan siinä käsityksessä, että projektisi pitää tehdä kaikki yhdellä kertaa. Ja omassa lähestymistavassani se pitää paikkansa, mutta vain versiossa 1! Jos päätät lisätä uusia ominaisuuksia tai muuttaa toimintatapoja, voit tietysti tehdä sen, kun sinulla on toimiva v1. Ja se tehdään samalla tavalla kuin luot v1:n, tekemällä ensin todella yksityiskohtaisen alennussuunnitelman ja sitten muuttamalla sen helmiksi. Annan esimerkin Cassista, Coding Agent Session Search -ohjelmastani, joka on melko monimutkainen Rust-ohjelma, joka automaattisesti tunnistaa, jäsentää, tallentaa ja indeksoi kaikki aiemmat istuntolokit lähes jokaiselta koodausagentilta. Se tarjoaa alle 50 ms välittömän "haun kirjoittaessasi" kaikissa lokeissa ja sisältää monia muita hyviä ominaisuuksia. Päätin lisätä Cassiin ominaisuuden, joka on samankaltainen kuin ominaisuus, joka minulla jo on MCP Agent Mailissa ja beads_viewer (bv): mahdollisuuden viedä kokoonpanosi staattisena verkkosivustona, jota voi palvella GitHub Pagesilla. Voit nähdä esimerkin bv:stä juuri tästä projektista, joka on suunnitteluprosessin lopullinen tulos, jonka kuvaan tässä kirjoituksessa: Tämä toiminnallisuus tekee viedyn sivuston luomisesta ja käyttöönotosta gh-työkalulla erittäin nopeaa ja helppoa. Sivusto itsessään koostuu yleensä sqlite-tiedostosta sekä kasasta typescriptiä ja wasmia, jotka pyörivät kokonaan selaimessa, mutta erittäin hyvällä suorituskyvyllä sekä hienoilla ominaisuuksilla ja tyylillä, kuten voit nähdä juuri annetussa esimerkissä. MCP Agent Mail -viestien tai helmien jakaminen on yksi asia, mutta koodausagentin istuntolokien jakaminen on hyvin erilaista; nämä ovat usein täynnä arkaluontoista tietoa, API-avaimia, kirosanoja/solvauksia (ainakin omani ovat!), ja muuta materiaalia, jota et todellakaan haluaisi paljastaa maailmalle. Mutta GitHub Pages, vaikka onkin hyvä, toimii vain julkisissa repoissa (muuten, työkaluni tukevat myös Cloudflare-sivuja, mutta GH Pages on parempi ja helpompi tähän käyttötarkoitukseen). Miten siis käsitellä näitä ongelmia? Vastaus on salaus: käyttäjä valitsee ensin, mitkä koodausagentit sisällyttää, mitkä projektikansiot, aikakausi jne., ja nippu luodaan (huomaa, että tämä paketti on kanonisessa muodossa, johon Cass sisäisesti muuntaa kaikki koodausagenttiviestit alkuperäisistä natiivimuodoista), ja käyttäjä antaa sitten salasanan paketin salaukseen. Ajatuksena on, että vaikka repositio ja verkkosivu ovat julkisia, kaikki paitsi sinä ja muut, joille kerrot salasanan, näkevät vain salasanakentän eivätkä pysty lukemaan viestejä. Kun salasana on syötetty, se avaa kauniin, reagoivan käyttöliittymän, jonka avulla voit helposti etsiä viestejä lähes yhtä nopeasti ja tehokkaasti kuin Cass. Ja jos sinulla ei oikeasti ole mitään salattavaa, voit jättää salasanan pois päältä ja tehdä siitä kaiken oikeasti julkiseksi. ...