Hvordan Bygge Et Stort Programvareprosjekt Alene, fra Bunnen av

Hvordan Vil Du Begynne?

hvis du var en utvikler i Et Agile-team, er ditt eneste mål å møte sprintmålene. I så fall vil du i 80% av tilfellene gjøre det bra ved å begynne å utvikle BRUKERGRENSESNITTET. Fordi det gir hele laget litt validering og følelse av fremgang.

ditt solo-sideprosjekt trenger Imidlertid Ikke å stole På Agile. Du må ikke svare andre enn deg selv. Du bør prøve å gjøre den vanskeligste delen først. Jeg snakker om å virkelig omfavne dyret.

for å lage et kick-ass-produkt, trenger du alltid 1024 ting i tillegg til å løse kjerneproblemet. Du må være ekstremt oppmerksom på avhengighetshåndtering.

Administrasjon Av Programvareavhengighet

du må gjøre brukeradministrasjon fordi det er inngangspunktet for data. Brukerdata er og vil være din mest verdifulle vare frem til dagen du bestemmer deg for å selge din venture Til Facebook eller Google.

med det kommer nettverk. Husk å håndtere nyttelast? Du må lagre offline data og levere dem via en mobilapp / Dropbox-integrasjon, i tilfelle din mest verdifulle forbruker blir overført Til Grønland eller Kongo.

og med det, hvordan kan du glemme kostnadene som følger med dataoverføringer? Du må definere protokollen som kostnadseffektivt bærer nyttelasten mellom partene: HTTP, Websockets, TCP (Protobuffers), eller noe annet?

datasikkerhet er sluttavhengigheten i kjeden når du har definert alle andre avhengigheter (med mindre kjernetilbudet ditt er å løse et sikkerhetsproblem).

hvordan krypterer du dataene dine fra ende til ende? SHA? MD5? Hvordan vil du implementere offentlig-privat nøkkel håndtrykk?

hvis du kjenner disse relevante begrepene, er det enkelt å søke På GitHub eller be om meninger på forum. Et godt utgangspunkt er å søke etter noen av disse begrepene På Wikipedia og jobbe deg oppover derfra.

Lær om dem, lær om deres alternativer, og innen kort tid vil du være ekspertdommer i hver teknologi du velger for prosjektet ditt.

Neste: Implementere dem alle. Uten å skrive en eneste forretningslogikk, det vil si.

Pass på at du leser det riktig.

I et nøtteskall: Hold det så avkoblet som mulig fra forretningslogikken din. Skriv med grensesnitt, skriv med abstrakte klasser / strukturer. Lag konkrete teststubber for å teste dem ut.

Ja, for å teste alt dette med primate UI, må du skrive noen testtilfeller. Populære råd i programvare handler om å begynne med testtilfeller, før du skriver en linje med kode.

TDD gir innsikt i kodebasen som en ekspert anmelder ikke kan. Du vil innse sin enorme verdi når du implementerer neste trinn.

husk alltid: Du kan gå galt her på tusen måter. Men dette trinnet er mye mer enn en leksjon.

Arbeid gjort her er aldri tapt. Det er gjenbrukbart, fordi det er forretningslogikk agnostiker. Når du søppel dette prosjektet, husk at du alltid kan gjenbruke dette dyret for å fremskynde alle dine fremtidige prosjekter. Din tid til å utvikle vil gå ned eksponentielt.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *