Diventa Partner
gennaio 29, 2019

I controlli da fare per avere

il software perfetto!

 

Ecco le 6 domande che devi assolutamente fare ai tuoi fornitori (sviluppatore, freelance o web agency) per farti sviluppare progetti che possano durare nel tempo evitandoti la più brutta delle decisioni: “buttare tutto il software e rifare daccapo!”

 

Tra poco scoprirai delle informazioni che probabilmente nessuno ti ha mai svelato.
Costituiscono un’arma fondamentale per difenderti da interlocutori impreparati che si limitano solo a sbrodolare codice e alle prime difficoltà, sono fatti tuoi!

Sono domande mirate, con l’obiettivo di eliminare i problemi sin dalla nascita, prima ancora di scrivere una sola riga di codice.

 

Premessa

Il tuo interlocutore è tenuto a sviluppare soltanto quello che gli chiedi di fare. Non è tenuto ad informarti su quali sono i problemi a cui andrai incontro se il tuo software non viene costruito su determinate basi.

Sta alla sua coscienza INTERVISTARTI prima di mettere mano su progetti software esistenti o progetti da creare ex novo.

Perché dovrebbe farti queste domande?

Per conoscere la tua situazione di partenza e ……… soprattutto dovrebbe farlo prima di avanzare qualsiasi proposta e ripeto, prima di scrivere una sola riga di codice.

 

ATTENZIONE: Queste sono domande per scoprire le basi tecniche con cui lavorano i tuoi partner!

Se non sei un tecnico o un addetto ai lavori sei comunque costretto a valutare i tuoi partner tecnici, ma senza criteri come fai a selezionare una o più risorse che possono aiutarti nello sviluppo del software?

Se non hai alcun punto di riferimento ti farai rifilare il solito software “ben documentato” e con codice di “Qualità” ma con tutta una serie di problemi che si nascondono dietro l’angolo e che tra poco finalmente scoprirai.

Ok, fatta questa breve premessa, ecco le domande che dovrai fare quando si parla di progetti software.

 

1. L’applicazione usa l’autoloading?

A.A.A. Senza l’autoloading ogni file, classe o funzione deve essere incluso a mano all’interno del codice.

Quando senti la frase “a mano” devi immediatamente metterti in allarme!

L’autoloading, come dice la parola stessa è un meccanismo automatico del PHP grazie al quale il codice che lo sviluppatore aggiunge man mano che lavora viene agganciato automaticamente!

Automaticamente, tradotto, significa che non c’è possibilità di sbagliare, a mano invece significa che è sicuro al 100% che ti ritroverai al telefono ad urlare perché non funziona più niente.

 

2. Il software di cui parli è sviluppato usando Composer?

Il sogno più antico degli sviluppatori è nascosto sotto al motto “Non reinventare la ruota”, cioè se qualcuno ha già sviluppato il codice per risolvere un problema utilizzo direttamente quel codice e continuo a concentrarmi sullo sviluppo della mia applicazione.

In termini pratici è sicuro al 100% che i software che sviluppiamo tutti i giorni dipendono dall’utilizzo di librerie esterne.

E molto spesso queste librerie dipendono a loro volta da altre librerie per funzionare, creando una vera e propria cascata di dipendenze spesso moooolto lunga.

Fin qui sembra tutto normale tranne il fatto che tutta la catena di relazioni fra le librerie e il tuo software deve essere mantenuta coerente ed aggiornata! E non solo.

Se hai scaricato le librerie con tutte le dipendenze già incluse ti ritroverai con un codice sorgente molto pesante, nell’ordine dei GByte e tanto di quel codice duplicato da rendere la manutenzione del tuo software praticamente impossibile.

Ti faccio una domanda.

Se scarichi le librerie e le dipendenze separatamente, cosa succede se aggiorni una dipendenza e questa non è più compatibile con un’altra libreria?

Inevitabilmente vedrai il software andare in errore, e in questo caso: coma farai a scoprire che si tratta proprio di un bug di compatibilità tra due o più librerie?

Qui entra in gioco Composer, uno strumento automatico per la gestione delle dipendenze grazie al quale gli sviluppatori possono totalmente dimenticarsi di questi problemi, costruendo il tuo software come se fosse un vero e proprio Lego. Gran bella roba!

 

3. Il codice è organizzato usando i namespace?

Più il codice del tuo software cresce, più diventa complicato organizzarlo.

Un software di media dimensione ha centinaia di file al suo interno e migliaia di righe di codice.

I namespace come dice la parola stessa (spazio dei nomi) permettono al programmatore di organizzare il codice in compartimenti stagni evitando di sovrapporre parti del software con altre, riducendo i bug che si creano man mano che la complessità aumenta.

Il problema viene amplificato ed esasperato quando il tuo software fa un importante uso di librerie esterne, e cioè nel 99,99% dei casi.

La soluzione “vecchia maniera” è stata utilizzare lunghissimi nomi per file o funzioni. Ad esempio WordPress usa il prefisso “WP_”, oppure il framework Zend utilizza alcune convenzioni il cui risultato sono cose orribili del tipo:

Zend_Search_Lucene_Analysis_Analyzer_Common_Text_CaseInsensitive

Quanto pensi che uno sviluppatore possa lavorare senza bug in queste condizioni?

I namespace sono indispensabili.

 

4. Si sta usando uno strumento di versioning del codice sorgente (GIT/SVN)?

Partiamo dal presupposto che siamo consapevoli del fatto che il codice sorgente è l’asset intorno al quale girano le nostre relazioni di lavoro con i clienti ed è anche l’oggetto sul quale sta girando, almeno una parte, del business del cliente stesso.

Il versioning non ha nulla a che vedere con le “versioni” del software, tipo 0.1, 0.2, etc… Ha invece molto a che vedere con la protezione di tutto il tuo lavoro da imprevisti, sbagli umani o azioni volute di collaboratori malintenzionati.

Per evitare di incombere in questi fatali inconvenienti, ecco GIT.

GIT è un repository di file ad accesso controllato. Che cosa significa?

Che ogni cambiamento apportato a qualunque file del repository viene tracciato, in termini di chi ha apportato la modifica, quando, e per quale ragione.

Questo tracciamento inoltre permette allo sviluppatore di riportare tutto il repository allo stato in cui si trovava in un determinato giorno nel passato. Se ad esempio le ultime modifiche hanno incasinato qualcosa basta riportare tutto allo stato in cui si trovava ieri e si riparte con il lavoro.

Immaginala come una macchina del tempo.

Riesci a percepire il beneficio in termini di sicurezza e tranquillità che questo può dare all’oggetto del tuo business. Facciamo un esempio.

Se un collaboratore “in mala fede” stamattina si sveglia e cancella una intera parte del software, distrugge il server su cui l’applicazione è installata e poi sparisce nel nulla con il suo PC, se stai usando GIT non c’è nessun problema!

 

Perché?

Grazie alla tua macchina del tempo puoi riprendere il tuo codice sorgente nello stato in cui si trovava ieri e continuare a lavorare come se nulla fosse successo. Bastano pochi click per riportare tutto alla normalità.

Per farti capire le potenzialità di questo strumento ti faccio un altro esempio o meglio un’altra casistica. Precisamente quando abbiamo a che fare con la collaborazione di più sviluppatori allo stesso progetto. Proprio in questo caso avere un repository centrale è indispensabile, non c’è alternativa!

L’altra opzione è che ogni sviluppatore lavori sul proprio PC con una versione completamente diversa da quella degli altri sviluppatori.

Immagina che macello!

Ne convieni che ogni volta che deve essere rilasciata una nuova versione, il codice finale deve essere fatto dall’unione del lavoro di tutti gli sviluppatori coinvolti sul progetto.

Come farai a fare questa fusione?

E se più sviluppatori hanno modificato lo stesso file? Meglio affidarsi a strumenti di lavoro professionali altrimenti ti trovi in un macello che non hai idea, che richiede duri mesi di lavoro per ricreare una minima situazione di partenza pulita.

 

5. Il software ha al suo interno un Container per la Dependency Injection?

Innanzitutto è utile fare una distinzione fra questi due termini di cui spesso non si conosce o si confonde il significato:

  • La Dependency Injection è un metodo per sviluppare codice
    migliore
  • Un Container è un tool per aiutare lo sviluppatore a lavorare con la
    Dependency Injection

Questa tecnica di sviluppo ha un chiaro obiettivo: “Disaccoppiare il codice dell’applicazione”.

Che significa?

Immagina di usare una libreria per l’invio delle email, ad esempio SwiftMailer. Ad un certo punto dello sviluppo il tuo software ha bisogno di una determinata funzionalità che questa libreria non ha, quindi devo cambiare libreria, ad esempio PHPMailer.

Questo semplice cambio sottoporrà gli sviluppatori ad una riscrittura completa di tutte le funzionalità che riguardano l’invio delle email nella tua applicazione.

Cambieranno le classi da usare, i nomi dei metodi, le variabili e mille altri subdoli bug che verranno fuori solo quando tu chiamerai infuriato e nervoso perché dalla sera alla mattina non funziona più niente!

Un software progettato usando la Dependency Injection sarà molto più difficile da rompere perché non è così tanto legato alle specifiche librerie.

In questo caso fare un cambio di package come questo si sarebbe tradotto nel disinstallare la vecchia libreria, installare la nuova e poco più, dando al software una stabilità in fase di manutenzione inarrivabile e anche una aspettativa di vita molto, ma molto, più lunga.

 

6. Il software è stato sviluppato partendo da un framework?

Da sempre i framework sono un argomento molto dibattuto. Tante chiacchiere da metterti solo dubbi in testa e nessuno ti dice veramente qual’è il vero guadagno che otterrai se decidi di accettare questo vincolo.

Per ogni progetto in fase di crescita questa scelta non è mai stata facile ed il motivo principale è la grande paura nel ritrovarsi condizionati negativamente da questo legame.

In questi casi il consiglio che do a tutti i miei collaboratori è proprio questo:

Non cercare strumenti o librerie solo per scrivere meno codice. Ma cerca cosa può aiutarti a risolvere quello specifico problema nel tempo.

Un framework è la risorsa più importante che hai perché spinge gli sviluppatori a lavorare costruendo asset ed automatizzando tutti i tuoi processi di lavoro.

Se ci pensi la parola stessa framework ti dice di cosa stiamo parlando: “Frame” (schema), “work” (lavoro).

Dire di no ad un buon framework significa in un certo senso rifiutare un consiglio su come impostare il nostro lavoro datoci da sviluppatori di esperienza internazionale, che hanno realizzato applicazioni alla base di business di grande successo.

Forse prima di dire: “No io preferisco fare le cose da me perché non voglio vincoli” dovresti pensarci bene, perché il vincolo che non ti fa svoltare potresti essere proprio tu.

 

Un esempio pratico (LARAVEL framework)

Durante la mia esperienza lavorativa ho utilizzato tutti i principali ambienti di sviluppo (PHP, Java, .NET) ma soltanto con PHP e Laravel ho visto una crescita esponenziale della mia produttività.

Laravel è un ambiente di sviluppo perfettamente disegnato per realizzare applicazioni web secondo la più moderna ed efficiente metodologia di sviluppo basata sui “Servizi”.

Non è una marchetta, di certo non mi entra in tasca niente nello spendere buone parole su questo strumento di lavoro, ma voglio innanzitutto dimostrarti il perché io per primo ho fatto questa scelta.

Con Laravel puoi definire ed automatizzare tutti i processi di funzionamento del tuo sistema, delegando alcune funzionalità a servizi esterni e concentrandoti al 100% sullo sviluppo del tuo business e del tuo prodotto.

Dalla mia esperienza diretta, dalla pratica, fatta di errori, test e numerosi tentativi, da quando sviluppo le mie applicazioni usando Laravel ho visto i miei progetti andare avanti senza intoppi, anzi riuscendo ad immaginare sempre cose nuove grazie ad un ambiente di lavoro organizzato.

 

Ricapitoliamo

Il tuo interlocutore dovrebbe farti queste domande perché senza le risposte a queste domande, e senza usare questi strumenti è praticamente impossibile sviluppare un progetto che possa durare nel tempo senza che ti ritrovi prima o poi ad un bivio con il cliente per decidere:

Vado avanti?

O butto tutto e rifaccio daccapo?

Questo è il classico momento che decreta una crisi di rapporto con il cliente, il cui primo pensiero è ovviamente:

“Sono fatti tuoi! Vedi tu che vuoi fare”.

E non solo. Meglio essere diretti.

Molte applicazioni hanno appena un accenno di organizzazione orientato in questa direzione, ma come già detto voglio essere chiaro, il classico ragionamento delle pezze su questioni così basilari non ti salverà, molto presto malfunzionamenti, bug e lentezza diventeranno la regola, ed il confronto diretto con il cliente arriverà a livelli insopportabili e frustranti.

MEGLIO PREPARARSI PRIMA!

Dopo aver letto con attenzione questa guida adesso DAI UN VOTO da 1 a 10 su come sono organizzati i tuoi progetti software esistenti:

  1. Usano l’autoloading?
  2. Il software è stato sviluppato usando Composer?
  3. Il codice è organizzato usando namespace (PSR-4)?
  4. Utilizzano strumenti di versioning del codice sorgente (GIT/SVN)?
  5. Hanno al loro interno un Container per la Dependency Injection?
  6. Sono stati sviluppati partendo da un framework?

Se invece vuoi sviluppare progetti ex novo, come ti stai organizzando per fare in modo che questi progetti abbiano già questi requisiti e caratteristiche fin dalla prima riga di codice?

La risposta a questa domanda ti salverà dal dover affrontare un mare di problemi.

Spero che anche questa breve guida sia stata per te un’esperienza ricca di riflessioni!

 

Se ti è piaciuto condividi l’articolo sui tuoi social:

Facebook
Twitter
LinkedIn

GRATIS - La guida che ha aiutato aziende a NON buttare dai 20 ai 100.000€ nello sviluppo di software aziendali