Scrittura del codice qualità [chiuso]

Gli schemi software riguardano principalmente il vocabolario. Offrono agli sviluppatori di software un linguaggio grazie al quale possono comunicare concetti di design di alto livello.

Ma i pattern non sono una metodologia di progettazione ; se stai cercando di scrivere software cucendo insieme modelli di software ben conosciuti, probabilmente stai sbagliando. Ciò di cui hai veramente bisogno è un'architettura efficace

Ecco una migliore regola empirica:

Strive to write your programs as a series of small functions that each do one specific thing and do it well. Have them accept parameters, return a result, and create as few side effects as possible.

Puoi farlo in qualsiasi linguaggio di programmazione. Se segui questo precetto e nient'altro, i tuoi programmi saranno migliori del 95 percento di quei programmi scritti da nuovi laureati.

Non leggere libri per seguire nuove regole. Leggi i libri per esporti a nuove idee. Incorporare quelle idee che rendono il software migliore e farti uno sviluppatore di software migliore.

Ogni disciplina, sarebbe contabilità, archeologia o chirurgia cerebrale, ha numerosi libri e molte cose da ricordare. Sì, devi leggere molti libri per acquisire le conoscenze minime necessarie e no, non sarai in grado di ricordare tutto ciò che è scritto in quei libri.

Ridurre tutti i principi relativi al codice pulito in un paragrafo e affermare che non è necessario leggere più alcun libro non ti aiuterà. Semplicemente non funziona in questo modo, e non ti aiuterà a diventare uno sviluppatore professionista.

we have to just seek that pattern and try to reduce the repetitive part as hard as possible

Ci sono parti di codice che non hanno pattern specifici.

Ci sono casi in cui la duplicazione del codice ha senso, perché il fatto che il codice appaia identico è solo secondario.

Ci sono molti casi in cui la differenza tra il codice pulito e quello non pulito risulterebbe da qualcosa che non ha nulla a che fare con i pattern e la duplicazione del codice. Un esempio è chiaro, nomi di variabili autodocumentanti.

Si spera che l'apprendimento sia un processo iterativo. Ci sono cose che al momento non sono utili, ma ne ricorderai alcune. Si presentano dei problemi che farai ricerca. Li applicherete male, ma è parte dell'apprendimento. Mentre fai le cose, ti ricorderai di più. Probabilmente ho dimenticato molti particolari di molte lingue di quante ne potrei sapere sulle lingue che uso attualmente. Certo, ho perso conoscenza.

Non c'è motivo di pensare che sia necessario imparare tutto in un manuale di programmazione come quello che stai studiando per un esame finale. Sono destinati ad essere aperti molte volte. Alla fine, non dovrai continuare a cercare la stessa cosa più e più volte se la stai usando abbastanza.

Refactor ciò che attualmente sai non è il modo migliore per fare il lavoro. Forse hai imparato qualcosa di nuovo. I problemi nel tuo codice possono portarti a nuove soluzioni proprio come un buon mentore o qualche podcast che hai ascoltato.

Avere un'enciclopedia di conoscenze di programmazione deriva da anni di esperienza se hai fatto una vera programmazione. Certo che aiuta, ma non è la fine tutto di essere uno sviluppatore.

Continua a programmare, riconosci quello che non funziona e sii aperto a nuove soluzioni. Non devi sapere tutto subito.