I stedet for at tale om en bestemt teknologi eller et specifikt projekt, vil jeg i dette indlæg tale om softwarearkitektur og undgåelige fejl.
Det ville være langt lettere at tale om og rose succeserne, men jeg finder fejl ikke desto mindre et interessant emne, hovedsageligt fordi de er meget nyttige til at forbedre læringsprocessen.
Jeg starter med at give lidt kontekst og derefter dele mine synspunkter på softwarearkitektur, som jeg mener er den vigtigste del af softwareudvikling, og hvordan man undgår at falde i de mest almindelige fælder.
Når en programmør bliver stillet spørgsmålet:“Hvad foretrækker du: at starte et projekt fra bunden eller vedligeholde et eksisterende?„
De svarer:“Start noget fra bunden!„
Dette kan virke indlysende, fordi følelsen af præstation normalt er større, hvis vi kan sige:“Dette er min opgave (i hvert fald en betydelig del af det). Det eksisterede ikke før, og nu gør det!„
Men der er mere ved det. Den menneskelige hjerne kan lide orden, den kan lide at udlede mønstre fra kaoset og tilsyneladende tilfældig information. Hvad angår softwareudvikling, er dette også sandt.
Hvad sker der i et eksisterende projekt? Det er sandsynligt, at projektet allerede har et vist niveau af opfattet kaos i sig, og det har bestemt mere end et ikke-eksisterende.
Derfor er det øjeblikkelige svar at foretrække at starte et projekt fra bunden, hvor du kan kontrollere det kaos fuldstændigt i henhold til din oplevelse.
Selvfølgelig, I software Utopia ville vi aldrig gøre noget, der ville skabe kaos ved vores egen uagtsomhed. Ak, vi lever ikke i den verden, men vi har værktøjer og principper til at guide os.
Det bedste værktøj, vi har til rådighed til at håndtere de irriterende opgaver som regression, rettelse af fejl og lignende, er fremadrettet planlægning. En god arkitektur er vores ven.
En veldesignet løsning er værd tusinder af timer, da det virkelig sparer os meget tid i fremtiden.
De fleste af os har læst bøgerne, vi kender ting at gøre. Vi bør også lave tests og anvende designmønstrene religiøst. “Lad os virkelig fokusere på at beholde denne MVC; lad os anvende BDD til dette; lad os designe funktionstestene, før vi skriver produktionskode.“
Nogle gange glemmer vi vigtigheden af, hvad det første skridt skal være, selv før alt det.
Arkitektur.
Jo da, før du skriver produktionskode, ja, gå videre og skriv dine første tests.
Men allerede inden du skriver dine første tests, har designteamet sandsynligvis allerede samlet alle kravene, forhandlinger er blevet ført med klienten og de andre interessenter, de har måske endda produceret et par versioner af designet af det produkt, du skal bygge, og de er forhåndsgodkendt, så du måske tænker, at du snart skal begynde at kode.
Bortset fra at du ikke burde.
Hele holdet skal sidde og tale om det produkt, de er ved at bygge. De skal tage et stykke papir eller gå til en whiteboard og begynde at opregne alle de funktioner, produktet vil have.
Identificer klart alle de tekniske krav og gennemførligheden af den foreslåede løsning. Udfordre hvert trin i det og forestil dig virkelig en løsning ved hjælp af en anden tilgang, måske forskellige rammer, endda et andet sprog.
Bundlinjen er, at der ikke er sådan noget som at bruge for meget tid på arkitektur.
For mig er en af de bedste måder at lære ved at begå fejl.
Da det kan være pinligt eller frustrerende at lave fejl, når vi laver dem, har vi en tendens til at være opmærksomme på, hvad der skete, og stræbe efter at finde løsningen og finde ud af den bedste måde at ikke begå den samme fejl igen.
Det svarer til erfaring.
„Erfaring er simpelthen det navn, vi giver vores fejl.“
— Oscar Wilde
For nylig har jeg arbejdet på et ret komplekst iOS-projekt. Lige i starten af projektet var der et par ting, der var væk. Kravene var ikke 100% defineret, forudsætningerne var ikke 100% opfyldt, API'er var endnu ikke klar...
Men nok var det vigtigste: Vi havde ikke defineret projektets arkitektur så godt, som vi burde have.
Jeg blev først opmærksom på dette, da skaden var sket, selvfølgelig. Der var masser af regression, omskrivning af funktioner, og flere gange sagde jeg til mig selv:“Hvorfor har jeg ikke gjort det på den rigtige måde?“
En sådan faldgrube var, at der ikke blev brugt nogen testrammer. I det hele taget. Test og validering blev foretaget med brugertests og sparsomme peer-kodeanmeldelser. Derefter, da en testramme faktisk blev bragt til projektet, var det for sent.
En af de mest kendte og accepterede rammer for iOS-udvikling spillede simpelthen ikke godt med alle de forviklinger, flere sprog og dårlige beslutninger, der blev truffet, når man designede produktarkitekturen (fra et teknisk perspektiv).
Tilbage til tegnebrættet. Du modtager et nyt projekt, og du har måske endda været involveret i kravindsamlingsfasen. Uanset om du allerede har en idé om den overordnede tekniske løsning til dette projekt, vil jeg anbefale:
1. Skriv alt ned. Lav skemaer, komponentdiagrammer, klassediagrammer, flowdiagrammer, hvad du føler nødvendigt for at hjælpe dig - og teamet - med et hurtigt blik på det fulde billede af problemet.
Henvis til det så ofte som nødvendigt. Dette vil sandsynligvis blive revideret flere gange, før den første kodelinje skrives.
2. Når alle komponenterne/moduler er identificeret, skal du prøve at finde solide eksisterende løsninger til dem. Open source-rammer er vejen at gå, da de allerede bruges af flere mennesker og derfor er testet og meget mere fejlfri, end din egen brugerdefinerede løsning måske bliver.
3. Når du vælger eksterne eller tredjepartsrammer, skal du sørge for, at de“spille pænt“ med resten af rammerne. Prøv at finde nok beviser, der bekræfter kompatibilitet mellem alle de rammer, du skal bruge.
At skulle ændre rammer under udviklingen, fordi du fandt ud af, at noget ikke fungerer som tilsigtet, når du er i nærværelse af en anden ramme, tvinger dig til at bruge tid på at søge efter en anden løsning alligevel, og vil få dig til at spilde endnu mere tid på at lave disse uønskede regressioner.
4. Vælg en god testramme. På samme måde som det foregående trin skal du sørge for, at testrammen fungerer uden anstrengelse med alle de andre rammer, du vil bruge.
En testramme er kun så god som den dækning, den kan give dig på et bestemt projekt. Hvis det ikke er velegnet, eller direkte ikke understøtter en bestemt teknologi eller modul, du planlægger at bruge, skal du ikke stole på det.
At teste 8 ud af 10 funktioner er ikke godt nok.
Til det næste projekt, jeg vil være involveret, vil jeg gøre mit bedste for at følge disse principper og opdatere dem efter behov. Måske vil en eller flere af disse antagelser blive udfordret og raffineret.
Hvis din egen erfaring har lært dig anderledes, er du velkommen til at dele dine synspunkter og anbefalinger om, hvad de første skridt, du skal tage, når du starter et nyt projekt, skal være.
Computersystemanalytiker, computerprogrammør og applikationsudvikler. Særligt interesseret i at udvikle applikationer til mobile platforme.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
