Hvordan "Du kommer ikke til å trenge det!" kan forenkle utviklingsprosessen

Hvordan "Du kommer ikke til å trenge det!" kan forenkle utviklingsprosessen Jason McCreary forklarer prinsippet om "Du kommer ikke til å trenge det!" finnes i Ekstrem programmering, og hvordan det kan være verdifullt for å holde programmeringsarbeidsflytene enkle.

Programmeringspraksis som DevOps er utvilsomt i forkant av programmeringstrender. Uten å redusere de reelle fordelene som å ta i bruk DevOps kan ha for prosjektet ditt, er disse fordelene tydeligere på prosjektstyringsenden av spekteret, mens prinsipper som Extreme Programming (XP) forholder seg nærmere til den faktiske koden som er skrevet.

Hvordan bygge en vellykket karriere som IT-konsulent (gratis PDF) (TechRepublic)

Forenkling av utviklingsprosessen ved å begrense mengden arbeid som er gjort for å imøtekomme fremtidige krav til et gitt program, kan betale utbytte i tidsstyring. Jason McCreary snakket om "Du kommer ikke til å trenge det!" (YAGNI) -aspektet av ekstrem programmering i august på Code PaLOUsa i Louisville, KY.

Hva er YAGNI ment å løse?

Åpne en IDE og bare stupe i vil sannsynligvis resultere i dårlig fokusert spaghettikode. Prosessen er ikke ulik å starte en bil uten en destinasjon i tankene på forhånd. Det er mulig å ankomme et sted, selv om banen til dette punktet langt fra er effektiv. I hovedsak er prinsippet til YAGNI at utviklere ikke skal legge til funksjonalitet før det er nødvendig for produktet eller tiltenkt bruk.

McCreary peker på to ganske forskjellige kilder for å forstå dette. Ron Jeffries, en av de tre medstifterne av Extreme Programing, beskriver det som "å implementere ting når du faktisk trenger dem, ikke bare når du ser for deg at du trenger dem." Tilsvarende bemerket den franske forfatteren Antoine de Saint-Exupéry at "perfeksjon oppnås, ikke når det ikke er noe mer å legge til, men når det ikke er noe igjen å ta bort."

En av de vanligste fallgruvene med programmering i moderne rammer - node.js er beryktet for dette - er rutinemessig import av pakker for å gi minimale funksjoner, og dermed legge til kompleksitet og skape en avhengighet. Når du "tar et bibliotek, eller kjøper et stykke programvare eller tar i bruk et rammeverk", for å utføre en oppgave, bør du vurdere hvorfor dette gjøres. Ved å skrive din egen kode for dine egne behov, "er det fordeler utover bare å redusere kompleksiteten. Fordelene er at koden er mer tilgjengelig, lesbar, brukbar og vedlikeholdbar over tid."

Når skal man påkalle YAGNI i utviklingsprosessen?

McCreary bemerker at det er to oppfatninger av tiden. "Tid er den mest dyrebare ting for meg, det er noe jeg aldri vil ha mer av. Det er et tostrøydt sverd. På den ene siden stresser det meg, jeg har en frist, vi er her, la oss gjøre det, hvorfor sløser vi med tid? Det er en annen side til tid: La oss bare slappe av, vi gjør det senere, og komme til det. Vi må komme mer på den komfortable siden av tiden. "

På samme måte ber McCreary utviklere om å utfordre deres måte å tenke på når de begynner på utvikling.

  • Trenger du virkelig å bygge det akkurat nå?

  • Har du alt du trenger for å starte?

  • Forstår du problemet fullt ut?

Men det er en mørk side ved YAGNI, når det manifesterer seg som "Bare si nei", der McCreary advarer mot å kalle YAGNI for ting som testing, da det ikke er et nivå av "bare testet nok." På samme måte gjelder ikke YAGNI sikkerhet, og det er ikke tilrådelig å forsøke å ringe YAGNI. Som et eksempel: "Hvis de sier at du må bruke en SQL-server, selv når du vet at du kan gjøre det i en flatfil-database, kan du ikke ringe YAGNI på det, selv om det kan være en enklere tilnærming." McCreary advarer også utviklere om å ikke sabotere deg selv - ikke ring YAGNI på et nåværende designvedtak basert på et fremtidig behov.

Dagens nyeste nyhetsbrev

Hvis du bare kan lese en teknisk historie om dagen, er dette det. Leveres hverdager

Registrer deg i dag

© Copyright 2020 | mobilegn.com