Sviluppare una soluzione in FileMaker: costruire un metodo di sviluppo

A partire da questo articolo inizieremo a vedere come si sviluppa una soluzione in FileMaker. Prima di addentrarci nella parte più operativa del lavoro, dobbiamo procurarci degli strumenti fondamentali: metodo e ordine.

Sappiamo tutti che lo sviluppo di un software, a seconda della sua complessità, richiede giorni, settimane o mesi di lavoro.

Ma ci siamo mai chiesti quanto di questo tempo è stato effettivamente dedicato allo sviluppo e quanto alla manutenzione o alle implementazioni successive?

La domanda fondamentale

Vale la pena perdere un po' di tempo nella fase iniziale per facilitarci il compito in quelle successive?
La risposta è: ovviamente sì!

Consegnare un software al cliente e non doverci più mettere le mani è pura utopia. In molti casi, soprattutto quando si parla di un software gestionale personalizzato, il tempo impiegato fino all'installazione dal cliente è di gran lunga inferiore a quello che gli si dovrà dedicare in futuro. Questo non tanto per il debug, che è giusto considerare come parte della fase iniziale, quanto per le successive personalizzazioni. Anche quando il lavoro sembra essere finito, poiché in grado di soddisfare in pieno i requisiti richiesti dagli utilizzatori, ci sono sempre fattori esterni pronti a rompere il fragile equilibrio tra il software e l'azienda che lo utilizza. Alcuni di questi possono essere: cambiamenti delle normative, fusioni, divisioni, nuove attività, implementazioni di ogni tipo che, come prima cosa, richiedono modifiche al software per far fronte alle nuove esigenze.

A volte ritornano

Senza dover parlare di casi estremi, capita spesso che un cliente si rifaccia vivo dopo anni e che si debba rimettere mano su qualcosa che ci ricordiamo a malapena di avere fatto.

Potrebbe trattarsi di qualcosa di semplice, oppure di dover modificare una procedura per la quale abbiamo impiegato giorni (o notti) solo per trovare il bandolo della matassa. Ma se abbiamo fatto tanta fatica la prima volta, cosa ci fa credere che dopo qualche tempo rientreremo con facilità dentro al problema?

Non è solo questione di rischiare una brutta figura: è importante considerare l'aspetto economico. Non sarà facile, e nemmeno troppo corretto, chiedere al cliente di riconoscerci il tempo che dovremmo dedicare a capire una cosa fatta da noi.

Inoltre, se possibile, sarebbe meglio non dover chiedere al cliente di rispiegarci per filo e per segno il funzionamento di una certa attività, come si era fatto in fase di analisi, perché metteremmo a rischio la nostra credibilità: non dimentichiamoci che il cliente non fa il nostro lavoro e che ci paga perché siamo noi a dovere risolvere i suoi problemi, non viceversa.

Detto così potrebbe sembrare un inutile allarmismo ma, dopo anni di lavoro, le applicazioni di uno sviluppatore potrebbero diventare parecchie, di cui alcune complesse.  Anche all'interno di un'applicazione sulla quale si lavora spesso possono esserci sezioni sulle quali da anni non si apportano modifiche.

Serve metodo

Quindi se siete degli sviluppatori, e la vostra intenzione nel medio termine non è quella di trovare un imbarco su un peschereccio ma di continuare a fare ciò che state facendo, vi conviene pensare bene a come evitare molti mal di testa futuri e qualche probabile figuraccia. Perché non importa quanto siete bravi o quanto siete intelligenti, se avete la memoria di un elefante o, come il sottoscritto, non vi ricordate cosa avete fatto il giorno prima: se non avete un metodo e non vi date delle regole, prima o poi potreste trovarvi in guai seri.

Tutto sommato quelle da seguire sono regole molto semplici, che riassunte si potrebbero esprimere con una frase: siate ordinati in modo maniacale.

Essere ordinati significa stabilire un metodo e seguirlo. Non solo oggi o nei giorni successivi dopo la lettura di questo articolo (che forse vi avrà insinuato qualche lieve senso di colpa), ma anche negli anni a venire. Per questo il suggerimento è di ragionare molto su queste cose per capire quali consigli seguire e quali regole invece non si adattano al vostro modo di lavorare. L'importante è definire delle regole che si riescano ad applicare.

Inizialmente avrete l'impressione di perdere del tempo, perché essere ordinati costa qualche minuto in più ogni volta che si mette mano alla definizione dei campi, degli script o al grafico delle relazioni. Ma dovrete avere fiducia nel fatto che questo tempo vi verrà ripagato ogni volta che dovrete rimettere mano al vostro lavoro.

Sappiate anche che non è una strada facile. Sopratutto quando vi capiterà di lavorare sotto stress, potrebbe passarvi la voglia di complicarvi l'esistenza pensando a come nominare quel campo o quel layout. Ma una volta presa l'abitudine non riuscirete a fare a meno di vedere le cose nel giusto ordine.

6 regole per creare un metodo di sviluppo personalizzato

Ecco quindi le 6 regole principali per costruirsi un proprio metodo di sviluppo (che approfondiremo nelle prossime puntate di Point Break):

  1. Descrivere gli script attraverso i commenti.
  2. Inserire i commenti nei campi ed evitare calcoli che possono risultare illeggibili.
  3. Uniformare le procedure standard (login, script di navigazione, ecc.).
  4. Definire degli standard per nominare campi, script, formati, relazioni.
  5. Tenere nel giusto ordine il grafico delle relazioni.
  6. Archiviare le versioni e conservare tutta la documentazione.

Descrivere gli script attraverso i commenti

Una delle cose più utili per aiutare lo sviluppatore a capire cosa è passato nella sua mente perversa il giorno in cui ha compilato un determinato script (o una serie di script) è quello di scrivere dei commenti. I commenti negli script possono essere fondamentali, non solo per riprendere in mano una procedura dopo molto tempo, ma anche per aiutarci nel debug e capire meglio l'aspetto logico del problema.

Inoltre, se i commenti sono utilizzati nel modo giusto, potrebbero inaspettatamente farci risparmiare molto tempo anche in fase di sviluppo.

Ma questo sarà l'argomento della prossima puntata della Rubrica Point Break. Non perdetela!




Nessuna domanda trovata.

Sandro Bramati

Cerca
Prendi la corsia preferenziale e risolvi i tuoi problemi di sviluppo FileMaker!

Risorse gratuite

Guru Corner

Altri articoli di Sandro Bramati

Ultimi articoli