hur skulle du börja?
Om du var utvecklare i ett agilt team är ditt enda mål att uppfylla sprintmålen. I så fall kommer du i 80% av fallen att göra det bra genom att börja utveckla användargränssnittet. Eftersom det ger hela laget en viss validering och känsla av framsteg.
men ditt solo-sidoprojekt behöver inte förlita sig på Agile. Du får inte svara på någon utom dig själv. Du bör försöka göra den svåraste delen först. Jag talar om att verkligen omfamna odjuret.
För att göra en kick-ass-produkt behöver du alltid 1024 saker förutom att lösa kärnproblemet. Du måste vara mycket medveten om beroendehantering.
Du måste göra användarhantering eftersom det är ingångspunkten för data. Användardata är och kommer att vara din mest värdefulla vara fram till den dag du bestämmer dig för att sälja ditt företag till Facebook eller Google.
med det kommer nätverk. Kom ihåg att hantera nyttolast? Du måste lagra offlinedata och leverera den via en mobilapp/Dropbox-integration, om din mest värdefulla konsument överförs till Grönland eller Kongo.
och med det, hur kan du glömma kostnaden som kommer med dataöverföringar? Du måste definiera protokollet som kostnadseffektivt bär din nyttolast mellan parter: HTTP, Websockets, TCP (Protobuffers) eller något annat?
datasäkerhet är slutberoendet i kedjan när du har definierat alla andra beroenden (såvida inte ditt kärnerbjudande är att lösa ett säkerhetsproblem).
hur krypterar du dina data från början till slut? SHA? MD5? Hur kommer du att genomföra offentlig-privat nyckel handskakning?
Om du känner till dessa relevanta termer är det enkelt att söka på GitHub eller be om åsikter på forum. En bra utgångspunkt är att söka efter någon av dessa termer på Wikipedia och arbeta dig upp därifrån.
lär dig om dem, lär dig om deras alternativ, och inom kort tid kommer du att vara expertdomare i varje teknik du väljer för ditt projekt.
nästa: implementera dem alla. Utan att skriva en enda rad affärslogik, det vill säga.
se till att du läser det rätt.
i ett nötskal: håll det så frikopplat som möjligt från din affärslogik. Skriv med gränssnitt, skriv med abstrakta klasser / strukturer. Gör konkreta teststubbar för att testa dem.
Ja, för att testa allt detta med primate UI måste du skriva några testfall. Populära råd i programvara handlar om att börja med testfall innan du skriver en kodrad.
TDD ger insikter i din kodbas som en expertgranskare inte kan. Du kommer att inse dess enorma värde när du genomför nästa steg.
kom alltid ihåg: Du kan gå fel här på tusen sätt. Men detta steg är mycket mer än en lektion.
arbete som görs här går aldrig förlorat. Det är återanvändbart, eftersom det är affärslogik agnostiker. När du skräp detta projekt, kom ihåg att du alltid kan återanvända detta djur för att påskynda alla dina framtida projekt. Din tid att utvecklas kommer att gå ner exponentiellt.