Hvordan til at bygge et stort program projekt alene, fra bunden

hvordan ville du begynde?

Hvis du var udvikler i et agilt team, er dit eneste mål at opfylde sprintmålene. I så fald vil du i 80% af tilfældene gøre det godt ved at begynde at udvikle brugergrænsefladen. Fordi det giver hele holdet en vis validering og følelse af fremskridt.

dog behøver dit solo-sideprojekt ikke at stole på Agile. Du må ikke svare på nogen undtagen dig selv. Du bør prøve at gøre det sværeste først. Jeg taler om virkelig at omfavne udyret.

for at lave et kick-ass produkt, ville du altid have brug for 1024 ting udover at løse kerneproblemet. Du skal være meget opmærksom på afhængighedsstyring.

iv

Du skal gøre brugerstyring, fordi det er indgangspunktet for data. Brugerdata er og vil være din mest værdifulde vare indtil den dag, du beslutter dig for at sælge din venture Til Facebook eller Google.

med det kommer netværk. Husk håndtering af nyttelast? Du bliver nødt til at gemme offline data og levere dem via en mobilapp/Dropboks-integration, hvis din mest værdifulde forbruger bliver overført til Grønland eller Congo.

og med det, hvordan kunne du glemme de omkostninger, der følger med dataoverførsler? Du skal definere den protokol, der omkostningseffektivt bærer din nyttelast mellem parterne: HTTP, Netbockets, TCP (Protobuffers) eller noget andet?

datasikkerhed er slutafhængigheden i kæden, når du har defineret alle andre afhængigheder (medmindre dit kernetilbud er at løse et sikkerhedsproblem).

hvordan krypterer du dine data end-to-end? SHA? MD5? Hvordan vil du implementere offentlig-privat nøgle håndtryk?

Hvis du kender disse relevante udtryk, er det let at søge på GitHub eller bede om meninger på fora. Et godt udgangspunkt er at søge efter nogen af disse vilkår på og arbejde dig op derfra.

Lær om dem, lær om deres alternativer, og inden for kort tid vil du være ekspertdommer i enhver teknologi, du vælger til dit projekt.

næste: implementere dem alle. Uden at skrive en enkelt linje af forretningslogik, det er.

sørg for at læse det rigtigt.

i en nøddeskal: hold det så afkoblet som muligt fra din forretningslogik. Skriv med grænseflader, Skriv med abstrakte klasser / strukturer. Lav konkrete teststubber for at teste dem ud.

Ja, for at teste alt dette med primate UI, skal du skrive nogle testsager. Populære råd i programmel handler om at begynde med test cases, før du skriver en linje kode.

TDD giver indsigt i din kodebase, som en ekspertanmelder ikke kan. Du vil indse dens enorme værdi, når du implementerer det næste trin.

husk altid: du kan gå galt her på tusind måder. Men dette trin er meget mere end en lektion.

arbejde udført her går aldrig tabt. Det kan genbruges, fordi det er forretningslogik agnostiker. Når du papirkurver dette projekt, skal du huske, at du altid kan genbruge dette udyr til at fremskynde alle dine fremtidige projekter. Din tid til at udvikle vil gå ned eksponentielt.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *