hoe zou u beginnen?
Als u een ontwikkelaar was in een Agile team, is uw enige doel om de sprintdoelen te halen. Zo ja, in 80% van de gevallen, zult u goed doen door te beginnen met de ontwikkeling van de UI. Omdat het het hele team enige bevestiging en gevoel van vooruitgang geeft.
echter, uw solo side-project hoeft niet te vertrouwen op Agile. Je moet je alleen aan jezelf verantwoorden. Probeer eerst het moeilijkste deel te doen. Ik heb het over het echt omarmen van het beest.
om een kick-ass product te maken, zou je steevast 1024 dingen nodig hebben naast het oplossen van het kernprobleem. Je moet je zeer bewust zijn van afhankelijkheidsbeheer.
u moet gebruikersbeheer uitvoeren omdat dat het invoerpunt is voor gegevens. Gebruikersgegevens zijn en zullen uw meest waardevolle grondstof tot de dag dat u besluit om uw onderneming te verkopen aan Facebook of Google.
Hierbij hoort networking. Weet je nog dat je payloads behandelde? Je moet offline gegevens opslaan en leveren via een mobiele app / Dropbox-integratie, voor het geval je meest waardevolle consument wordt overgebracht naar Groenland of Congo.
en daarmee, Hoe kon je de kosten vergeten die gepaard gaan met gegevensoverdracht? U moet het protocol dat kosteneffectief draagt uw lading tussen partijen definiëren: HTTP, Websockets, TCP (Protobuffers), of iets anders?
gegevensbeveiliging is de eindafhankelijkheid in de keten zodra u alle andere afhankelijkheden hebt gedefinieerd (tenzij uw belangrijkste aanbod is om een beveiligingsprobleem op te lossen).
hoe versleutelt u uw gegevens end-to-end? SHA? MD5? Hoe implementeert u de handdruk van de publieke-private sleutel?
als u deze relevante termen kent, is het gemakkelijk om te zoeken op GitHub of om meningen te vragen op forums. Een goed uitgangspunt is om te zoeken naar een van deze termen op Wikipedia en werk je een weg omhoog vanaf daar.
leer over hen, leer over hun alternatieven, en binnen korte tijd zult u een deskundige rechter zijn in elke technologie die u kiest voor uw project.
volgende: implementeer ze allemaal. Zonder het schrijven van een enkele lijn van business logica, dat wil zeggen.
zorg ervoor dat u dat goed leest.
In een notendop: houd het zo ontkoppeld mogelijk van uw business logica. Schrijf met interfaces, schrijf met abstracte klassen / structs. Maak concrete teststubs om ze uit te testen.
Ja, om dit allemaal te testen met primaat UI, moet je een aantal testcases schrijven. Populair advies in software is over het beginnen met testcases, voordat het schrijven van een regel code.
TDD geeft inzicht in uw codebase die een deskundige recensent niet kan. U zult de enorme waarde ervan beseffen zodra u de volgende stap implementeert.
onthoud altijd: je kunt hier op duizend manieren fout gaan. Maar deze stap is veel meer dan een les.
werk dat hier gedaan wordt, gaat nooit verloren. Het is herbruikbaar, omdat het business logic agnostisch is. Als je dit project in de prullenbak gooit, onthoud dan dat je dit beest altijd opnieuw kunt gebruiken om al je toekomstige projecten te versnellen. Je tijd om je te ontwikkelen zal exponentieel dalen.