Pausa caffè #79. 10 errori commessi dagli sviluppatori Java che impediscono loro di raggiungere il successo. Una guida per sviluppatori per scrivere commenti sul codice significativi

10 errori commessi dagli sviluppatori Java che impediscono il loro successo

Fonte: Dev.to Sulla base della mia esperienza, ho compilato un elenco di 10 errori commessi dagli sviluppatori che impediscono loro di raggiungere il successo:

1. Non scrivere test unitari

Gli sviluppatori che non scrivono unit test commettono più errori nel loro codice. Ciò porta all’instabilità del prodotto e all’insoddisfazione del cliente.

2. Non controllano il codice manualmente

Anche se copri completamente il tuo codice con test unitari, c'è ancora la possibilità che ti sia sfuggito qualcosa. Si consiglia sempre di testare manualmente il codice prima di inviarlo per la revisione. In questo modo è possibile rilevare gli errori in fase di sviluppo.

3. Pensano: “Questo non accadrà mai”.

Gli sviluppatori spesso commettono errori quando scrivono un nuovo codice, pensando che determinati scenari non si verificheranno mai. Alla fine si scopre che si sbagliano. Gestisci tutti gli scenari in cui il codice può essere eseguito. I metodi di programmazione difensiva ti aiuteranno in questo.

4. Non ricevere feedback

Sollecita regolarmente feedback da altri sviluppatori e utenti. Condividi la tua opinione con i tuoi colleghi.

5. Non controllano la funzionalità del codice.

Spesso gli sviluppatori scrivono il loro codice, ma non ne controllano la funzionalità. Di conseguenza, quando il codice arriva in produzione, crea diversi problemi.

6. Scrivere un codice procedurale lungo

È molto semplice scrivere metodi lunghi con molta logica. In questo modo, i programmatori implementano la stessa logica in molti punti. I progetti con un numero significativo di piccoli metodi consentono un riutilizzo del codice molto migliore e sono molto più facili da mantenere.

7. Non conoscono gli strumenti

Gli strumenti sono un'estensione delle tue mani. Meglio li conosci, più produttivo sarai. Dovresti avere molta familiarità con l'IDE che stai utilizzando. Impara comandi rapidi, ci sono sempre comandi che ti aiuteranno a essere ancora più produttivo. In IntelliJ IDEA questi sono Sonar Lint, Spot bugs e Code Metrics.

8. Ignora i problemi nel codice

Gli sviluppatori che lavorano sui prodotti di maggior successo modificano costantemente il codice. Non aver paura di rifattorizzare il tuo codice. Se il tuo codice è testato in unità, ci sono poche possibilità di regressione. Gli sviluppatori spesso ignorano il codice problematico. In qualità di sviluppatore, sei responsabile del mantenimento dell'applicazione in buone condizioni. Per questo motivo, risolvi eventuali problemi riscontrati.

9. Codificano senza rendersi conto delle conseguenze.

Gli sviluppatori non dovrebbero MAI apportare modifiche al codice e rilasciarlo in produzione senza comprenderne le conseguenze. Il codice può produrre risultati corretti per i valori del test specificati. Tuttavia, potrebbero verificarsi scenari in cui ciò potrebbe portare a risultati imprevedibili e creare seri problemi. La codifica "imprevedibile" spesso si verifica quando gli sviluppatori utilizzano funzioni di librerie che non comprendono appieno. Ciò può verificarsi anche quando uno sviluppatore risolve un problema senza comprendere la soluzione.

10. Non chiedere aiuto

Gli sviluppatori non sono persone molto socievoli. A loro piace risolvere i problemi da soli. Ma l'era in cui uno sviluppatore stesso crea un prodotto dall'inizio alla fine è finita. Lo sviluppo del software è un'attività di squadra. Quando incontri un problema durante la programmazione, prova a risolverlo da solo. Ma non perdere troppo tempo se non riesci a trovare una soluzione. C'è un'alta probabilità che alcuni dei tuoi colleghi abbiano già riscontrato lo stesso problema e conoscano la soluzione. Ciò farà risparmiare tempo e aumenterà la produttività.

Una guida per sviluppatori per scrivere commenti sul codice significativi

Fonte: Stepsize Nella maggior parte dei casi, non sei l'unico a lavorare sullo stesso progetto o base di codice. Ciò significa che altre persone devono comprendere il tuo codice. Questo vale anche per i commenti al codice. Gli sviluppatori spesso scrivono commenti “veloci e sporchi” senza molto contesto, lasciando i colleghi confusi su ciò che l’autore stava cercando di dire. Questa è una cattiva pratica e crea più confusione che chiarezza. Avere commenti sul codice chiari aiuta gli altri sviluppatori. Un commento al codice che descrive una funzione, la sua logica, l'input e l'output accelera il processo di apprendimento per altri sviluppatori. D’altra parte, i commenti al codice ci portano alla domanda: vale la pena scriverli? Un gruppo significativo di sviluppatori si oppone alla scrittura di commenti sul codice. Il motivo è che il codice, a loro avviso, si spiega da sé. Se un altro sviluppatore non riesce a comprendere lo scopo del tuo codice guardandolo, allora si tratta di un codice errato. Forse questo è vero. Ma pensate al piccolo sforzo richiesto per commentare il codice e ai potenziali vantaggi che ne derivano. I commenti sul codice sono importanti per accelerare il processo di onboarding di qualsiasi sviluppatore, in particolare dei più giovani. Diamo un'occhiata ai diversi tipi di commenti sul codice.

1. Commenti alla documentazione.

Lo scopo principale di tali commenti è chiarire rapidamente lo scopo di un file o componente. Invece di leggere l'intero codice di un componente per capire cosa fa, puoi aggiungere un commento al codice nella parte superiore del file "index". Questo aiuterà a spiegare cosa fa questo componente. Non sono un grande fan di questo tipo di commenti perché ingombra un po' il codice. Penso che questi tipi di commenti sull'architettura dovrebbero essere nella tua documentazione interna in cui puoi mantenere e discutere centralmente l'architettura del tuo progetto. Tuttavia, i progetti open source ne hanno davvero bisogno.

2. Commenti sulle funzioni.

Questo è il tipo di commento più utile. Descrivono lo scopo della funzione, i suoi parametri e il suo output.

/**
 * @desc Creates a welcome message
 */
function sayHello(name) {
    return `Hello ${name}`;
}

3. Commenti logici.

Questi sono commenti all'interno delle funzioni per chiarire percorsi di codice complessi. Come avrai intuito, la presenza di tali commenti indica che il tuo codice è troppo complesso. Inoltre, i commenti logici spesso contengono informazioni troppo dettagliate. Il livello di dettaglio creerà più caos e ridurrà la leggibilità del codice. Ecco un esempio di un commento di codice eccessivamente dettagliato.

let date = new Date(); // store today's date to calculate the elapsed time

Commenti sul codice: 4 migliori pratiche per commentare

1. Utilizza annotazioni o tag di codice

Molti linguaggi di programmazione definiscono standard per commentare il codice. Java utilizza Javadoc , mentre JavaScript utilizza il sistema di commento del codice JSDoc , supportato da molti strumenti di documentazione. Per le funzioni è necessario includere i seguenti tag di codice:

• @desc - descrizione della tua funzione
• @param: tutti i parametri di input accettati dalla funzione. Assicurati di specificare i tipi di input.
• @returns: output restituito. Assicurati di specificare il tipo di output.
• @throws è il tipo di errore che la funzione può generare.
• @example: uno o più esempi che mostrano l'input e l'output previsto.

Ecco un esempio di codice Lodash per la funzione Chunk .

/**
 * Creates an array of elements split into groups the length of `size`.
 * If `array` can't be split evenly, the final chunk will be the remaining
 * elements.
 *
 * @since 3.0.0
 * @category Array
 * @param {Array} array The array to process.
 * @param {number} [size=1] The length of each chunk
 * @returns {Array} Returns the new array of chunks.
 * @example
 *
 * chunk(['a', 'b', 'c', 'd'], 2)
 * // => [['a', 'b'], ['c', 'd']]
 *
 * chunk(['a', 'b', 'c', 'd'], 3)
 * // => [['a', 'b', 'c'], ['d']]
 */
function chunk(array, size = 1) {
  // logic
}

2. Spiega il motivo delle tue azioni

Molti sviluppatori utilizzano i commenti per descrivere cosa fa il loro codice. Quando lo fai, assicurati di includere il motivo per cui hai creato una particolare funzionalità o componente. Questa informazione è chiamata contesto. Il contesto è importante per fornire agli sviluppatori maggiori informazioni sulle decisioni di progettazione dietro una funzionalità o un componente. Il contesto è fondamentale quando altri sviluppatori desiderano apportare modifiche alla tua funzionalità o componente. Di seguito puoi vedere un cattivo esempio di codice di commento senza contesto.

/**
 * Sets the label property of a new form.
 *
 * @param label text for label of form
 */
function setFormLabel(label) {
    // logic
}

3. Non collegare ad altri documenti o commenti

Non è consigliabile collegare altri commenti al codice o documenti interni che spiegano una funzionalità o un componente.

/**
 * Sets the label property of a new form.
 *
 * @see {@link https://myinternaldocument.com}
 */
function setFormLabel(label) {
    // logic
}

4. Scrivi commenti durante la codifica

Questo può sembrare ovvio, ma molti sviluppatori (me compreso) trascurano questa regola. Lasciare i commenti per dopo è sbagliato perché potresti dimenticare parte della logica che hai scritto, il che porterà a commenti sul codice di qualità inferiore. Ciò è particolarmente vero se lavori sulla stessa richiesta pull da diversi giorni. È meglio scrivere commenti quando hai appena terminato una funzionalità o un modulo. Ricordarsi di mantenere i commenti sul codice il più brevi possibile. Non è necessario dedicare più tempo alla scrittura dei commenti che alla scrittura del codice stesso.