Istället för att prata om en specifik teknik eller ett specifikt projekt, kommer jag i det här inlägget att prata om mjukvaruarkitektur och misstag som kan undvikas.
Det skulle vara mycket lättare att prata om och berömma framgångarna, men jag tycker ändå att misstag är ett intressant ämne, främst för att de är mycket användbara för att förbättra inlärningsprocessen.
Jag börjar med att ge lite sammanhang och sedan dela med mig av mina åsikter om mjukvaruarkitektur, som jag tror är den viktigaste delen av mjukvaruutveckling och hur man undviker att falla i de vanligaste fällorna.
När någon programmerare ställs frågan:”Vad föredrar du: starta ett projekt från grunden eller behålla ett befintligt?”
De svarar:”Starta något från grunden!”
Detta kan tyckas uppenbart eftersom känslan av prestation vanligtvis är större om vi kan säga:”Detta är mitt arbete (åtminstone en stor del av det). Det fanns inte tidigare, och nu gör det det!”
Men det finns mer i det. Den mänskliga hjärnan gillar ordning, den gillar att härleda mönster från kaoset och uppenbar slumpmässig information. När det gäller mjukvaruutveckling är detta också sant.
Men vad händer i ett befintligt projekt? Det är troligt att projektet redan har en viss nivå av upplevt kaos i sig och det har verkligen mer än ett icke-existerande.
Därför är det omedelbara svaret att föredra att starta ett projekt från grunden, där du kan kontrollera det kaoset helt enligt din erfarenhet.
Självklart, i mjukvaruutopia skulle vi aldrig göra något som skulle skapa kaos genom vår egen vårdslöshet. Tyvärr lever vi inte i den världen, men vi har verktyg och principer för att vägleda oss.
Det bästa verktyget vi har tillgängligt för att hantera de irriterande uppgifterna regression, fixa buggar och liknande, är framtidsplanering. En bra arkitektur är vår vän.
En väl utformad lösning är värd tusentals timmar eftersom det verkligen kommer att spara oss mycket tid i framtiden.
De flesta av oss har läst böckerna, vi vet saker att göra. Vi bör också göra tester och tillämpa designmönstren religiöst. ”Låt oss verkligen fokusera på att behålla denna MVC; låt oss tillämpa BDD för detta; låt oss utforma funktionstesterna innan vi skriver produktionskod.”
Ibland glömmer vi vikten av vad det första steget ska vara, redan innan allt detta.
Arkitektur.
Visst, innan du skriver produktionskod, ja, gå vidare och skriv dina första tester.
Men redan innan du skriver dina första tester har designteamet förmodligen redan samlat alla krav, förhandlingar har gjorts med kunden och de andra intressenterna, de kan till och med ha tagit fram några versioner av designen av produkten du ska bygga och de var förgodkända, så du kanske tror att du borde börja koda snart.
Förutom att du inte borde.
Hela teamet borde sitta och prata om produkten de ska bygga. De bör ta ett papper eller gå till en whiteboard och börja räkna upp alla funktioner som produkten kommer att ha.
Identifiera tydligt alla tekniska krav och genomförbarhet för den föreslagna lösningen. Utmana varje steg i det och föreställ dig verkligen en lösning med ett annat tillvägagångssätt, kanske olika ramar, till och med ett annat språk.
Slutsatsen är att det inte finns något sådant som att spendera för mycket tid på arkitektur.
För mig är ett av de bästa sätten att lära sig genom att göra misstag.
Eftersom att göra misstag kan vara pinsamt eller frustrerande, när vi gör dem, tenderar vi att uppmärksamma vad som hände och sträva efter att hitta lösningen och räkna ut det bästa sättet att inte göra samma misstag igen.
Det är lika med erfarenhet.
”Erfarenhet är helt enkelt namnet vi ger våra misstag.”
— Oscar Wilde
Nyligen har jag arbetat med ett ganska komplext iOS-projekt. Redan i början av projektet var det några saker som var avstängda. Kraven var inte 100% definierade, förutsättningarna uppfylldes inte 100%, API: er var ännu inte redo...
Men förmodligen var det viktigaste: vi hade inte definierat projektets arkitektur så bra som vi borde ha gjort.
Jag blev medveten om detta först när skadan skedde, naturligtvis. Det var massor av regression, omskrivning av funktioner och flera gånger sa jag till mig själv:”Varför har jag inte gjort det på rätt sätt?”
En sådan fallgrop var att inget testramverk användes. Överhuvudtaget. Tester och validering gjordes med användartester och glesa peer code reviews. Sedan, när ett testramverk verkligen togs med i projektet, var det för sent.
En av de mest kända och accepterade ramarna för iOS-utveckling spelade helt enkelt inte bra med alla krångligheter, flera språk och dåliga beslut som fattades vid utformningen av produktarkitekturen (ur ett tekniskt perspektiv).
Tillbaka till ritbordet. Du får ett nytt projekt, och du kan till och med ha varit involverad i kravsamlingsfasen. Oavsett om du redan har en uppfattning om den övergripande tekniska lösningen för detta projekt, skulle jag rekommendera:
1. Skriv ner allt. Gör scheman, komponentdiagram, klassdiagram, flödesscheman, vad du än känner nödvändigt för att hjälpa dig - och teamet - att förstå hela bilden av problemet med en snabb blick.
Hänvisa till det så ofta som behövs. Detta kommer troligen att revideras flera gånger innan den första kodraden skrivs.
2. När alla komponenter/moduler är identifierade, försök hitta solida befintliga lösningar för dem. Open source-ramverk är vägen att gå eftersom de redan används av flera personer och därför är testade och mycket mer felfria än din egen anpassade lösning kan bli.
3. När du väljer externa eller tredje parts ramverk, se till att de ”spela trevligt” med resten av ramarna. Försök hitta tillräckligt med bevis som bekräftar kompatibilitet mellan alla ramar du ska använda.
Att behöva ändra ramverk under utvecklingen eftersom du fick reda på att något inte fungerar som avsett när det finns ett annat ramverk, tvingar dig att spendera tid på att leta efter en annan lösning ändå, och kommer att få dig att slösa ännu mer tid på att göra dessa oönskade regressioner.
4. Välj ett bra testramverk. På samma sätt som föregående steg, se till att testramverket fungerar utan ansträngning med alla andra ramverk du ska använda.
Ett testramverk är bara så bra som den täckning det kan ge dig på ett visst projekt. Om den inte är väl lämpad, eller helt enkelt inte stöder en specifik teknik eller modul du planerar att använda, lita inte på det.
Att testa 8 av 10 funktioner är inte tillräckligt bra.
För nästa projekt jag kommer att vara involverad kommer jag att göra mitt bästa för att följa dessa principer och uppdatera dem efter behov. Kanske kommer ett eller flera av dessa antaganden att utmanas och förfinas.
Om din egen erfarenhet har lärt dig annorlunda, dela gärna dina åsikter och rekommendationer om vad de första stegen att ta när du startar ett nytt projekt ska vara.
Datorsystemanalytiker, datorprogrammerare och applikationsutvecklare. Särskilt intresserad av att utveckla applikationer för mobila plattformar.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
