| Oratore |
Trascrizione |
| Aurora Tiffany-Davis |
Ciao, sono Aurora Tiffany-Davis. Sono una sviluppatrice software del team JMP Live. Oggi vorrei parlarvi di come sviluppiamo software nel team JMP Live. |
| |
Per prima cosa, vorrei che immaginassi come funziona la creazione di un software. Se non sei uno sviluppatore, l'immagine che hai in mente è probabilmente influenzata da programmi TV e film che hai visto. |
| |
Potresti immaginare qualcuno che lavora da solo, qualcuno che è davvero intelligente, forse persino un genio, e il cui procedimento è davvero semplice. |
| |
Pensano a un problema, scrivono del codice e poi si assicurano che funzioni. E probabilmente funziona, perché dopotutto sono dei geni. |
| |
Se fossimo tutti dei geni in JMP Live, questo semplice processo funzionerebbe per noi. Ma non lo siamo e viviamo nel mondo reale. Quindi abbiamo bisogno di qualcosa in più. |
| |
Innanzitutto non lavoriamo da soli, ma in modo molto collaborativo e il nostro processo prevede delle fasi per cercare di garantire che non realizziamo semplicemente un software, ma un software di qualità. |
| |
Vorrei sottolineare che non esiste un modo corretto per sviluppare software. Potrebbe variare da un'azienda all'altra o persino all'interno di un'azienda, ma vi guiderò attraverso il nostro processo. |
| |
raccontandoti cosa farei se dovessi sviluppare una nuova funzionalità in JMP Live. |
| |
Innanzitutto, prima di sedermi a scrivere il codice, devo avere qualche necessità di farlo. |
| |
Deve esserci qualche vero utente là fuori con un vero problema, qualcosa che hanno identificato in JMP Lives che non funziona... che non funziona come pensano che dovrebbe, |
| |
che è un modo carino per dire che hanno trovato un bug o una funzionalità da loro richiesta. |
| |
Teniamo traccia di queste richieste in un sistema interno. Quindi la prima cosa che farei sarebbe accedere a quel sistema e trovare un problema ad alta priorità che sia adatto alle mie competenze, e iniziare a lavorarci. |
| |
Poi devo capire meglio la necessità. Parlerò con le persone e cercherò di capire che tipo di utente desidera questa funzionalità. Come la useranno. |
| |
Quindi eseguirò JMP Live sul mio computer e darò un'occhiata a come questa funzionalità potrebbe inserirsi in JMP Live così come esiste oggi. |
| |
Oppure potrei aprire il codice e vedere dove il nuovo codice potrebbe inserirsi nella nostra base di codice esistente. |
| |
Una volta che ritengo di aver capito abbastanza bene cosa serve, inizio a lavorare sul design. Di nuovo, parlo con le persone. Parlerò con i membri del team e chiederò: "Avete già lavorato su una funzionalità simile a questa? Avete già lavorato su questa parte del codice?" |
| |
E parlerò con gli esperti di esperienza utente che abbiamo in JMP. |
| |
Cercherò di non reinventare la ruota. Quindi, se c'è un aspetto della funzionalità che è molto comune e non è specifico di JMP Live, ad esempio qualcosa come la registrazione di alcune informazioni in un file. |
| |
È un problema risolto, un migliaio di persone lo hanno avuto in passato. Potrebbe esserci una buona soluzione open source. |
| |
In tal caso, potrei utilizzarlo dopo averlo attentamente esaminato per accertarmi che sia sicuro da usare. |
| |
C'è ancora molto da fare, molto codice specifico per JMP Live che deve essere scritto. Quindi scriverò articoli e diagrammi e |
| |
Descriverò la mia proposta e mi assicurerò che tutti nel team siano a loro agio con la direzione che intendo prendere con il design. Poi mi siederò e scriverò il codice. |
| |
Per questo userò un ambiente di sviluppo integrato, ovvero uno strumento per scrivere codice dotato di numerose funzionalità che ti aiuteranno a essere più efficiente nel tuo lavoro. |
| |
Ora ho scritto del codice. Prima di controllarlo, voglio trovare i problemi presenti nel codice che ho appena scritto. Sono solo un essere umano, quindi le probabilità di aver scritto un codice impeccabile al 100% al primo tentativo sono piuttosto scarse. |
| |
Inizierò cercando problemi molto evidenti e per farlo utilizzo l'analisi statica. |
| |
L'analisi statica analizza il mio codice non mentre è in esecuzione, ma come se fosse appena stato scritto su una pagina. Un'analogia potrebbe essere il controllo ortografico di Microsoft Word. |
| |
Il correttore ortografico non può dirti se hai scritto un romanzo avvincente, ma può dirti se hai dimenticato una virgola da qualche parte. L'analisi statica fa lo stesso per il codice. |
| |
Una volta individuati e corretti problemi davvero ovvi come questo, passerò a individuare problemi meno evidenti. Per questo, utilizziamo una suite di test automatizzata. |
| |
Questa differenza si differenzia dall'analisi statica perché esegue effettivamente il codice. Esegue una parte del codice con un certo input e si aspetta un certo output. Abbiamo scritto un'ampia gamma di test per il nostro codice. |
| |
Poi mi siederò e scriverò i test per la funzionalità su cui sto lavorando. |
| |
Questo è davvero utile perché sedermi a scrivere i test mi obbliga a chiarire le mie idee su come esattamente il codice dovrebbe funzionare. Inoltre, offre una protezione contro l'eventualità che qualcun altro rompa accidentalmente la funzionalità in futuro. È un ottimo modo per individuare i problemi in anticipo. |
| |
Ora passiamo ai test manuali. Eseguirò JMP Live sul mio computer, eserciterò la nuova funzionalità e mi assicurerò che funzioni come ritengo debba funzionare. |
| |
Potrei anche dare un'occhiata al database che sta dietro a JMP Live e che tiene traccia di record, post, gruppi, utenti e commenti per assicurarmi che tutti quei record vengano scritti nel modo in cui ritengo che debbano essere. |
| |
Ora sono moderatamente ottimista di aver scritto del buon codice e il prossimo passo è la revisione paritaria. Vorrei che i miei colleghi mi aiutassero a esaminare il codice e a trovare qualsiasi cosa che potrei aver tralasciato. |
| |
Potrei essermi perso qualcosa perché ho i paraocchi su qualcosa o perché qualcun altro nel mio team ha conoscenze che io non ho. Questo passaggio è spesso molto utile anche per il revisore, perché potrebbe imparare nuove tecniche. |
| |
Dopo aver superato la revisione paritaria, siamo pronti a inviare effettivamente il codice o a depositarlo in un repository del codice sorgente. |
| |
Abbiamo un sistema di build continuo sui nostri server che controlla quando eseguiamo il check-in del codice. E quando lo facciamo, esegue un sacco di operazioni con quel codice. |
| |
Ad esempio, assicurarsi che i file giusti siano presenti al posto giusto, nominati correttamente e così via. Inoltre, tornerà indietro e rieseguirà l'analisi dello stack e l'intera suite di test automatizzata. |
| |
Questo è utile perché, dopotutto, siamo solo umani. Qualcuno potrebbe aver dimenticato di fare questa cosa in precedenza, o potrebbe essere cambiato qualcosa dall'ultima volta che l'ha fatto. |
| |
Una volta che il codice supera la build continua, è disponibile anche al di fuori del gruppo di sviluppo. I primi ad accorgersene sono stati i professionisti dei test all'interno di JMP. |
| |
Li esamineranno e potrebbero aggiungerli alla nostra suite di test automatizzati. Potrebbero anche eseguire alcuni test manuali. |
| |
Potrebbero osservare come funziona il software su diversi sistemi operativi, diversi browser e così via. Inventeranno cose folli che l'utente potrebbe fare e osserveranno cosa succede e come risponde il software. |
| |
Sono una parte davvero fondamentale del nostro processo. Pensano in modo davvero creativo per trovare i problemi nel nostro prodotto. |
| |
Una volta approvati, il software è disponibile per essere ritirato nella prossima versione. Ora, lasciatemi allargare lo sguardo e mostrarvi il prodotto... il processo nel suo complesso. |
| |
E sono tanti passaggi. Sono un sacco di cose. Facciamo davvero tutto questo per tutto il nostro codice? |
| |
Che ci crediate o no, questo processo è molto scalabile. Quindi, per un bug davvero semplice e ovvio, lo analizzeremo molto velocemente. |
| |
Ma per una nuova funzionalità molto complessa, in ogni fase di questo processo rallenteremo, ci prenderemo il tempo necessario e presteremo molta attenzione per assicurarci di fare tutto per bene. |
| |
Tutto ciò che richiede tempo, ha un costo per un'azienda. Perché JMP è disposta a investire così tanto nella qualità del software? |
| |
Un motivo è molto semplice: siamo orgogliosi del nostro lavoro e vogliamo realizzare un buon prodotto. |
| |
Il secondo motivo è un po' meno idealistico. Sappiamo che se il nostro prodotto ha dei problemi e non li troviamo noi, li troveremo i nostri clienti, e questo non giova agli affari. Quindi vorremmo minimizzare questo problema. |
| |
Vorrei sottolineare che, sebbene JMP investa tempo e denaro nella qualità del software, |
| |
Non investiamo la stessa cifra che, ad esempio, investe un'organizzazione come la NASA, quindi non possiamo promettere la perfezione. Come qualsiasi software disponibile sul mercato, |
| |
Potresti trovare qualcosa in JMP Live che non funziona come pensi. Se trovi qualche... suggerimento, |
| |
Ti invitiamo ad andare su www.jmp.com/support e a farci sapere se c'è qualcosa che ritieni dovrebbe funzionare diversamente o se desideri funzionalità in futuro. |
| |
Questo tipo di feedback concreto da parte di utenti reali è incredibilmente prezioso per noi e lo apprezziamo molto. Questo è tutto per voi oggi, ma spero davvero che il resto di Discovery vi piaccia. Grazie. |
