{"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\/news\/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
\nDall'inizio del 2018 ricopro il ruolo di lead\/capo\/sviluppatore senior nel team \u2014 chiamalo come vuoi, ma il punto \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 pi\u00f9 attivamente alle decisioni. Recentemente, grazie a queste due circostanze, ho realizzato quanto profondamente il livello di comprensione influisca sul codice e sull'applicazione.<\/p>\n

Il pensiero che desidero esprimere si riduce al fatto che la qualit\u00e0 del codice (e del prodotto finale) \u00e8 strettamente legata a quanto le persone che progettano e scrivono codice siano consapevoli di ci\u00f2 che stanno facendo.<\/p>\n

Forse ora state pensando: \u00abGrazie, capitano. Certo, sarebbe utile capire cosa si sta scrivendo. Altrimenti, con lo stesso successo potremmo assumere un gruppo di scimmie per battere a caso sulla tastiera e rimanere soddisfatti\u00bb. E avete assolutamente ragione. Pertanto, prendo per scontato che sappiate che avere una visione generale di ci\u00f2 che state facendo \u00e8 necessario. Questo pu\u00f2 essere definito come un livello zero di comprensione, e non lo approfondiremo. Approfondiremo invece cosa \u00e8 necessario comprendere e come ci\u00f2 influisca sulle decisioni che prendete ogni giorno. Se avessi saputo queste cose in anticipo, mi sarei risparmiato un sacco di tempo sprecato e codice discutibile.
\n<\/a><\/noindex>
\nAnche se qui non vedrete una sola riga di codice, ritengo comunque che quanto detto finora sia di grande importanza per scrivere codice di qualit\u00e0, espressivo. <\/p>\n

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

\nI programmatori di solito raggiungono questo livello nelle fase iniziali della loro carriera, talvolta anche senza alcun aiuto da parte degli altri \u2014 almeno secondo le mie osservazioni. Immaginate di aver ricevuto un report di errore: una certa funzione nell'app non funziona, deve essere riparata. Come vi comportereste?<\/p>\n

Il principio standard \u00e8 il seguente:<\/p>\n

    \n
  1. Trovare il frammento di codice che causa il problema (come fare ci\u00f2 \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: le modifiche al codice. Ci sono due approcci a questo processo. Il primo: comprendere cosa sta accadendo nel codice attuale, identificare l'errore e correggerlo. Il secondo: procedere a tentoni, ad esempio aggiungere +1 a un'istruzione condizionale o a un ciclo, vedere se questa funzione funziona nello scenario desiderato, poi provare qualcos'altro e cos\u00ec via all'infinito.<\/p>\n

    L'approccio corretto \u00e8 il primo. Come spiega nel suo libro Code Complete Steve McConnell (che consiglio vivamente), ogni volta che apportiamo modifiche al codice, dobbiamo essere in grado di prevedere con sicurezza come questo influenzer\u00e0 l'applicazione. Riporto una citazione a memoria, ma se la correzione di un bug non funziona come previsto, questo dovrebbe mettere in guardia seriamente, e devi mettere in discussione tutto il tuo piano d'azione.<\/p>\n

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

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

    \nQuesto livello si raggiunge in modo molto meno intuitivo rispetto al precedente. Io, essendo ancora un programmatore alle prime armi, l'ho appreso grazie al mio capo, e successivamente l'ho spiegato pi\u00f9 volte ai neofiti.<\/p>\n

    Questa volta immaginiamo che ti siano arrivati due report di bug: il primo riguarda lo scenario A, il secondo lo scenario B. In entrambi gli scenari c'\u00e8 qualcosa che non va. Pertanto, inizi a lavorare prima sul primo bug. Seguendo i principi che abbiamo derivato per il primo livello di comprensione, esamini attentamente il codice pertinente al problema, scopri perch\u00e9 fa comportare l'applicazione in quel modo nello scenario A e apporti le modifiche sensate che producono esattamente il risultato che ti aspettavi. Tutto procede alla grande.<\/p>\n

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

    Non ti aspettavi affatto questo. Hai trovato un modo per correggere l'errore nello scenario A e non hai idea del perch\u00e9 abbia funzionato anche per lo scenario B. A questo punto, \u00e8 molto allettante pensare che entrambi i compiti siano stati eseguiti con successo. \u00c8 abbastanza logico: l'idea era di correggere gli errori, giusto? 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 essere che questo funzioni su principi errati, e quindi dovrai cercare un'altra soluzione. Ecco un paio di esempi di casi simili:<\/p>\n