Quando l'unico developer React Native se ne va
Una grossa azienda aveva un solo sviluppatore React Native interno. Quando se n'è andato, l'app si è fermata. Nessuno in azienda sapeva toccare il codice. Ci hanno chiamati, abbiamo preso in mano il progetto e lo abbiamo portato fino alla sottomissione negli store. Niente di eroico. È quello che facciamo.
Prima ricostruire il contesto
La prima cosa che abbiamo fatto non è stata guardare cosa mancava: è stata capire cosa c'era già e perché era stato scritto così. Con un solo sviluppatore che se n'è andato senza documentazione, quella fase ti dice tutto. Il problema non era il codice: era che tutto il contesto del progetto esisteva nella testa di una persona sola. Quando quella persona sparisce, non perdi uno sviluppatore: perdi la memoria del prodotto.
Usiamo React Native come default su progetti mobile enterprise. Non per comodità, ma perché in otto casi su dieci è la scelta giusta per chi deve mantenere un'app con un team piccolo e requisiti che cambiano. Ma funziona solo se c'è qualcuno che la sa mantenere. Non crediamo che nativo e cross-platform siano opposti. Crediamo che un team che sa fare solo una delle due cose prima o poi ti venderà quella, indipendentemente da quello di cui hai bisogno. Noi eravamo lì perché sapevamo farle entrambe.
Il costo della documentazione che manca
Il codice non era documentato. La sola analisi ha richiesto il doppio del previsto, prima ancora di correggere un bug o preparare una release. Lo abbiamo chiarito al cliente prima di firmare.
Lasciare un progetto che altri possano mantenere
Un passaggio di consegne utile deve documentare build, release, dipendenze e decisioni architetturali. Git conserva la storia del codice; non conserva il motivo per cui una scelta è stata fatta. React Native riduce il lavoro duplicato tra iOS e Android, ma la codebase condivisa deve restare leggibile per chi arriva dopo.
Servizi correlati
Per prodotti mobile che devono arrivare sugli store e restare manutenibili nel tempo, approfondisci il nostro approccio allo sviluppo app a Torino. Quando l'app è parte di un sistema più ampio, serve anche una software house a Torino capace di ragionare su architettura, backend e governance.