Dit is het derde deel van een trilogie artikelen die ingaan op de mismatch tussen de pitchdeck en het bruikbare product waar alle startups mee te maken krijgen.
Als je ze gemist hebt, hier zijn deel één en deel twee.
Welkom terug. Het lijkt erop dat je dit serieus neemt. Dit artikel is voor bouwers zoals jij. Welke onderdelen van de tweede aflevering van dit artikel heb je geïmplementeerd?
De vorige keer bespraken we hoe je het “Divide & Conquer”-patroon kunt gebruiken om schijnbaar ondoorgrondelijke problemen op te lossen door ze op te delen in veerkrachtige, herbruikbare, zelfvoorzienende blokken van verschillende grootte.
Vandaag bespreken we situaties waarin het juist zinnig is om te snijden in homogene stukken van ongeveer gelijke grootte, omdat er geen duidelijk punt is waar de snede het meest geschikt is.
Iconografie van het design system
Het opzetten en versterken van design systems zou in de meeste vroege startups mijn verantwoordelijkheid zijn. Hoewel veel activiteiten binnen het werk aan design systems voldoen aan het CDD (Component-Driven Development) paradigma, zoals besproken in het tweede deel, vereist een hele klasse van subtaken het uitvoeren van repetitieve handelingen die niet volledig geautomatiseerd kunnen worden. In zulke gevallen is het logisch om het werk op te delen in stukken van gelijke of vergelijkbare grootte en de hele lijst stukje bij beetje af te werken.
Voorbeeld van iconografie. Bron: storybook.js.orgEen opvallend voorbeeld van zo’n subtaak is iconografie. Wanneer de ontwerper de mismatch tussen sets iconen moet aanpassen die “bijna goed” zijn maar net niet helemaal, moet hij de iconen één voor één langs zijn maler halen en de formaten, tinten, lijndiktes, formaten, enzovoort aanpassen. Dit is het moment waarop het essentieel is om een goede afspeellijst te vinden die de tijd snel doet voorbijgaan.
Bestaande infrastructuur omzetten naar IaC
Het beschrijven van je cloudinfrastructuur als code is iets waarvan ik aanraad om er zo snel mogelijk mee te beginnen zodra je begint met het opzetten ervan. Uit persoonlijke ervaring blijkt echter dat je in de meeste gevallen zult starten met een bestaande omgeving.
// Bestaande resources integreren en deze geleidelijk vervangen
// door nieuwe.
this.vpc = Vpc.fromLookup(this, 'ExistingVPC', { vpcId: 'legacy-vpc-id' });
Je kunt de services die je moet importeren opdelen in pakketten van n. Vervolgens kun je ze één voor één afhandelen. Dit zal je vertragen, maar het is noodzakelijk om geleidelijk legacy-constructies te vervangen door constructies die via IaC (Infrastructure as Code) zijn gemaakt. Dergelijke migraties zullen vrijwel direct zijn voor stateloze zaken zoals netwerkconfiguraties of lambda-functies. Voor stateful componenten, zoals databases of gebruikerspools, zal dit echter aanzienlijk zijn. Neem gerust contact op als je een klankbord nodig hebt.
Storybook-bestanden
Nu je Storybook is opgezet, heeft elke webcomponent een apart bestand met stories. Als je vanaf nul begint, volg dan de Definition of Done (DoD) en maak een bestand met ten minste één basisstory. Als je een bestaande codebase hebt overgenomen, kun je tijd besteden aan het itereren en verrijken van de bestaande componenten met dergelijke bestanden.
Een basisbestand voor een Storybook-component
Het resulterende interactieve verhaalNaarmate je vordert, raad ik aan om de hiërarchie van al je componenten en pagina’s in de bibliotheek op te bouwen als een boomstructuur die de mappenstructuur van de code weerspiegelt. Je wilt dat je componenten zo hoog mogelijk in de boomstructuur staan, maar niet hoger dan nodig is. Het documenteren van componenten met Storybook kan een visuele hulp bieden om te bepalen of je iets verder naar beneden moet verplaatsen of juist hoger in de hiërarchie moet plaatsen.
Testbestanden
Aangezien het testframework is opgezet en geconfigureerd als onderdeel van het uitrusten met de benodigde contextonafhankelijke ontwikkeltools, kun je nu laaghangend fruit aanpakken in stukken van x.
Het eerste deel van het artikel noemt smoke- en snapshot-tests.
...
// Smoke test
it('renders without crashing', () => {
const container = document.createElement('div');
const root = createRoot(container);
root.render(<Hint text={'Hint'} />);
});
// Snapshot test
it('renders correctly', () => {
const view = render(<Hint text={'Hint'} />);
expect(view).toMatchSnapshot();
});
Deze tests zijn repetitief om te schrijven en vereisen geen diepgaande gedachtegang. Alles wat je hoeft te doen is elk component, of het nu een pakket, een React-knop of een Amazon Web Services (AWS) CDK-constructie is, aan te vullen met een extra bestand zoals beschreven in je DoD (Definition of Done)-document. Je hebt evenveel van zulke bestanden als je testbare zelfstandige componenten hebt. Loop ze allemaal iteratief langs en voeg die paar regels code toe.
Tracking van analyseevenementen
Meta staat erom bekend ongeveer 50.000 datapunten over je bij te houden. Je startup hoeft waarschijnlijk niet zoveel te tracken, maar je wilt wel de analytics verzamelen van de gebeurtenissen die ertoe doen. Je wilt niet vanaf dag één 50.000 willekeurige events implementeren. Deze mate van verfijning komt met volwassenheid.
// Een stereotype gebruikerswinkelwagenanalyse.
await analyticsAddToCart({
currency,
items: products.map(({ id }) => id),
webappUserId: user.username,
value: numberOfItems,
})
Wat ik vaak zie is dat ontwikkelaars die verantwoordelijk zijn voor het implementeren van analytics-tracking verwachten dat marketeers precies weten welke events ze willen volgen. “Geef ons een lijst van wat je wilt, en wij prioriteren het,” hoor ik vaak. Tenzij het door ervaren specialisten wordt gedaan die dit soort product al eerder hebben aangepakt, is dit meestal niet het geval.
Als zo’n lijst echter gemaakt is, kun je die opdelen in beheersbare stukken en elke dag of sprint een deel opleveren.
Bij het toevoegen van eventtracking aan je codebase raad ik aan om niet te veel na te denken en van grof naar fijn te gaan. Beperk jezelf tot eenvoudige events, zoals pageviews en scrolls voorbij de vouw. Voeg daarna zoektermen en sessieduur toe. Later kun je meer gedetailleerd worden en winkelwagenitems verzamelen en hoe die gerelateerd zijn aan de aanbevelingen die je systeem gaf op basis van hun zoekintenties.
Modelleren van bedrijfsentiteiten
Hopelijk heeft het tweede deel van het artikel je overtuigd om energie te steken in het modelleren van je bedrijf via UML (Unified Modeling Language) of een gelijkwaardig alternatief. Als je deze verstandige keuze hebt gemaakt, moet je nu je model vullen met bedrijfsentiteiten die routinematig binnen het bedrijf worden gebruikt. Er is een lijst met veelgebruikte entiteiten, zoals gebruikers, zoekopdrachten, chatberichten, enzovoort. Maar er zijn ongetwijfeld ook bedrijfsspecifieke entiteiten.
Een basis UML use-case diagramMijn aanbeveling is om te beginnen met het opstellen van een ERD, ofwel Entity Relationship Diagram. Elke relevante bedrijfsentiteit moet worden weergegeven met de attributen die je wilt opslaan. Verbind ze met behulp van de chicken leg-notatie.
Een product kan deel uitmaken van nul of meerdere winkelwagens. Een winkelwagen kan nul of meerdere producten bevatten.Neem een hoger, conceptueel perspectief aan in plaats van een laag-niveau, tabelachtige denkwijze zoals bij databases. Hoewel attributen als onderdeel van een specifieke entiteit worden weergegeven, hoeven ze niet per se in dezelfde datastore te worden geïmplementeerd. Dit geldt vooral voor gedistribueerde systemen, die de meerderheid van moderne platforms vormen. Je kunt ook RDF- of OWL-ontologieconventies gebruiken, maar dat is een onderwerp voor een andere keer.
Er is weinig OS-onafhankelijke modelleringssoftware die je aandacht en geld echt waard is. Ik raad altijd StarUML aan omdat het het dichtst bij een top-of-mind analysetool komt zonder de bank te breken.
Conclusie
Dit stuk is oorspronkelijk geschreven om herhaling te voorkomen.
Inderdaad, alle bedrijven waar ik heb gewerkt, zonder uitzondering, verspreidden hun middelen te dun door alles tegelijk te proberen of zich meer te richten op secundaire zaken dan op de kern, waardoor efficiëntie werd opgeofferd en geld op suboptimale manieren werd verbrand.
Ik wijs niet met de vinger — we missen allemaal wel eens het bos door de bomen. Ik ben daar zelf ook schuldig aan. De truc is het vroeg genoeg te herkennen of jezelf in een omgeving te plaatsen waar de kans hierop klein is. Daarom gebruiken we frameworks. Ze kaderen ons werk en schakelen de menselijke factor uit. “Divide & Conquer” is er een van.
Als wat je hebt gelezen als gezond verstand voelt, is dat ook zo. De meeste werkende dingen zijn belachelijk eenvoudig. Ik heb niets uitgevonden. Niemand doet dat. Dit is een beproefd patroon, geleend uit andere disciplines waar ze als standaardpraktijk gelden om dingen gedaan te krijgen. Ik weet zeker dat het ook voor jou zal werken.
Speciale dank
Deze reeks artikelen zou niet mogelijk zijn zonder de onschatbare bijdragen van Lilian T. , Farouq Aldori, Teppo Hudsson, Jarek Owczarek, Nickolay Tsybulyanko, en Jason Collins.