{"id":36115,"date":"2019-10-31T22:09:42","date_gmt":"2019-10-31T19:09:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete\/"},"modified":"2019-10-31T22:09:42","modified_gmt":"2019-10-31T19:09:42","slug":"ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"Non accettate di sviluppare ci\u00f2 che non comprendete","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Non
\n
\nDal 2018 ricopro il ruolo di lead\/capo\/sviluppatore senior nel team \u2014 chiamatelo come preferite, ma la sostanza \u00e8 che sono completamente responsabile di uno dei moduli e di tutti gli sviluppatori che ci lavorano. Questa posizione mi offre una nuova prospettiva sul processo di sviluppo, poich\u00e9 sono coinvolto in un numero maggiore di progetti e partecipo attivamente al processo decisionale. Recentemente, grazie a queste due circostanze, ho realizzato quanto profondamente la comprensione influenzi il codice e l'applicazione.<\/p>\n

L'idea che voglio esprimere \u00e8 che la qualit\u00e0 del codice (e del prodotto finale) \u00e8 strettamente legata a quanto consapevoli siano le persone che progettano e scrivono il codice riguardo a ci\u00f2 che stanno facendo.<\/p>\n

Probabilmente stai pensando: \u00abGrazie, capo. Certamente, sarebbe bene capire ci\u00f2 che scrivi. Altrimenti, potresti benissimo assumere un gruppo di scimmie per battere a caso sui tasti e andare avanti\u00bb. E hai completamente ragione. Pertanto, accetto come dato di fatto che sei consapevole che avere una comprensione generale di ci\u00f2 che fai \u00e8 necessario. Questo pu\u00f2 essere definito come un livello zero di comprensione, e non lo analizzeremo in dettaglio. Esamineremo in dettaglio ci\u00f2 che \u00e8 necessario capire e come questo influisce sulle decisioni che prendi ogni giorno. Se avessi conosciuto queste informazioni in anticipo, mi sarebbero state risparmiate molte ore sprecate e codice discutibile.
\n<\/a><\/noindex>
\nAnche se qui sotto non vedrai una riga di codice, ritengo che tutto ci\u00f2 che \u00e8 detto qui abbia una grande importanza per scrivere codice di qualit\u00e0 e significativo. <\/p>\n

Primo livello di comprensione: Perch\u00e9 non funziona?<\/h4>\n

\nA questo livello, gli sviluppatori di solito ci arrivano nelle prime fasi della loro carriera, a volte anche senza alcun aiuto da parte degli altri \u2014 almeno secondo le mie osservazioni. Immagina di aver ricevuto un report di bug: una certa funzione nell'app non funziona e deve essere corretta. Come procederesti?<\/p>\n

Lo schema standard \u00e8 il seguente:<\/p>\n

    \n
  1. Trovare il frammento di codice che causa il problema (come si fa questo \u00e8 un argomento a parte, che affronto nel mio libro sul codice obsoleto)<\/li>\n
  2. Apportare modifiche a quel frammento<\/li>\n
  3. Assicurarsi che il bug sia stato corretto e che non siano emersi errori regressivi<\/li>\n<\/ol>\n

    \nOra concentriamoci sul secondo punto \u2014 apportare modifiche al codice. Ci sono due approcci per questo processo. Il primo: capire esattamente cosa sta succedendo nel codice attuale, identificare l'errore e correggerlo. Il secondo: procedere a tentoni \u2014 aggiungere, ad esempio, +1 in un'istruzione condizionale o in un ciclo, vedere se la funzione ha iniziato a funzionare nel caso previsto, poi provare qualcos'altro e cos\u00ec via all'infinito.<\/p>\n

    Il primo approccio \u00e8 quello corretto. Come spiega Steve McConnell nel suo libro Code Complete (che consiglio vivamente), ogni volta che apportiamo modifiche al codice, dobbiamo essere in grado di prevedere con certezza come questo influenzer\u00e0 l'applicazione. Cito a memoria, ma se una correzione di bug non funziona come previsto, dovresti preoccuparti; devi mettere in discussione l'intero tuo piano d'azione.<\/p>\n

    In sintesi, per eseguire una correzione di bug efficace che non comprometta la qualit\u00e0 del codice, \u00e8 necessario comprendere sia la struttura del codice sia la fonte del problema specifico.<\/p>\n

    Il secondo livello di comprensione: Perch\u00e9 funziona?<\/h4>\n

    \nQuesto livello \u00e8 molto meno intuitivo rispetto al precedente. Io, quando ero ancora un programmatori alle prime armi, l'ho assimilato grazie al mio capo e in seguito l'ho spiegato pi\u00f9 volte a nuovi arrivati.<\/p>\n

    Immagina di ricevere due report di bug contemporaneamente: il primo riguarda lo scenario A, il secondo lo scenario B. In entrambi gli scenari qualcosa non va. Pertanto, inizi prima con il primo bug. Seguendo i principi che abbiamo dedotto per il primo livello di comprensione, approfondisci il codice concernente il problema, scopri perch\u00e9 causa il comportamento dell'applicazione nello scenario A e apporti le modifiche ragionevoli che producono esattamente il risultato atteso. Tutto procede bene.<\/p>\n

    Poi passi allo scenario B. Ripeti lo scenario nel tentativo di provocare l'errore, ma \u2014 sorpresa! \u2014 ora tutto funziona come dovrebbe. Per confermare la tua ipotesi, annulli le modifiche apportate durante la risoluzione del bug A e il bug B riemerge. La tua correzione ha risolto entrambi i problemi. Che fortuna!<\/p>\n

    Non te lo aspettavi affatto. Hai trovato un modo per correggere l'errore nello scenario A e non hai idea del perch\u00e9 funzioni anche nello scenario B. A questo punto, \u00e8 molto allettante concludere che entrambi i compiti siano stati completati con successo. \u00c8 piuttosto logico: l'obiettivo era eliminare gli errori, vero? Ma il lavoro non \u00e8 ancora finito: devi ancora capire perch\u00e9 le tue azioni hanno corretto l'errore nello scenario B. Perch\u00e9? Perch\u00e9 potrebbe funzionare secondo principi errati, e in tal caso dovrai cercare un'altra soluzione. Ecco un paio di esempi di tali situazioni:<\/p>\n