Come inizieresti?
Se tu fossi uno sviluppatore in un team Agile, il tuo unico obiettivo è quello di raggiungere gli obiettivi sprint. Se è così, nell ‘ 80% dei casi, farai bene iniziando a sviluppare l’interfaccia utente. Perché dà all’intero team una certa convalida e senso di progresso.
Tuttavia, il tuo side-project solista non deve fare affidamento su Agile. Non devi rispondere a nessuno tranne te stesso. Dovresti prima provare a fare la parte più difficile. Sto parlando di abbracciare veramente la bestia.
Per creare un prodotto kick-ass, avresti invariabilmente bisogno di 1024 cose oltre a risolvere il problema principale. È necessario essere estremamente consapevoli della gestione delle dipendenze.
Si deve fare l’utente di gestione, perché quello è il punto di ingresso per i dati. I dati utente sono e saranno il tuo bene più prezioso fino al giorno in cui deciderai di vendere la tua impresa a Facebook o Google.
Con questo viene il networking. Ricordate la gestione dei carichi utili? Dovrai memorizzare i dati offline e fornirli tramite un’integrazione mobile app/Dropbox, nel caso in cui il tuo consumatore più prezioso venga trasferito in Groenlandia o in Congo.
E con questo, come puoi dimenticare il costo che viene fornito con i trasferimenti di dati? È necessario definire il protocollo che trasporta in modo economico il payload tra le parti: HTTP, Websockets, TCP (Protobuffers) o qualcos’altro?
La sicurezza dei dati è la dipendenza finale nella catena dopo aver definito tutte le altre dipendenze (a meno che la tua offerta principale non risolva un problema di sicurezza).
Come si crittografano i dati end-to-end? SHA? MD5? Come implementerai l’handshake della chiave pubblico-privato?
Se conosci questi termini rilevanti, è facile cercare su GitHub o chiedere opinioni sui forum. Un buon punto di partenza è quello di cercare uno di questi termini su Wikipedia e il tuo lavoro fino da lì.
Scopri di loro, scopri le loro alternative e in poco tempo sarai un giudice esperto in ogni tecnologia che scegli per il tuo progetto.
Avanti: implementali tutti. Senza scrivere una singola linea di logica di business, cioè.
Assicurati di leggere bene.
In poche parole: tienilo il più disaccoppiato possibile dalla tua logica aziendale. Scrivi con interfacce, scrivi con classi/strutture astratte. Fare mozziconi di prova concreti per testare fuori.
Sì, per testare tutto questo con primate UI, è necessario scrivere alcuni casi di test. Il consiglio popolare nel software riguarda l’inizio dei casi di test, prima di scrivere una riga di codice.
TDD fornisce informazioni sulla base di codice che un revisore esperto non può. Vi renderete conto il suo enorme valore una volta che si implementa il passo successivo.
Ricorda sempre: potresti sbagliare qui in mille modi. Ma questo passo è molto più di una lezione.
Il lavoro svolto qui non è mai perso. È riutilizzabile, perché è agnostico della logica aziendale. Quando rifiuti questo progetto, ricorda che puoi sempre riutilizzare questa bestia per accelerare tutti i tuoi progetti futuri. Il tuo tempo per sviluppare diminuirà esponenzialmente.