Le pratiche del "codice pulito" sono davvero così pulite e utili? [chiuso]

Attualmente sto facendo uno stage in una grande azienda e stanno subendo molti cambiamenti nella struttura di consegna del software (passando ad Agile).

Negli ultimi due mesi ho notato questo attaccamento religioso alle Clean Codepratiche e il libro è stato una bibbia per gli sviluppatori.

Ora, una delle caratteristiche più importanti del codice pulito è il codice autoesplicativo che si basa su una denominazione comprensibile e un rigoroso re-factoring. Questo è seguito dalla no commentingregola.

Capisco che questo codice pulito è un investimento a lungo termine che faciliterà la manutenzione e il miglioramento del codice, ma ... ne vale davvero la pena?

Qualcuno condividerebbe la propria esperienza su Clean Code e qualsiasi opinione se sono troppo conservatore o è solo una tendenza temporanea.

programming-practices agile clean-code

— Arturs Vancans
fonte

Molte buone domande generano un certo grado di opinione basato sull'esperienza degli esperti, ma le risposte a questa domanda tenderanno ad essere quasi interamente basate su opinioni, piuttosto che su fatti, riferimenti o competenze specifiche.

— moscerino

Non ho un'opinione molto alta di quel libro (nonostante il suo autore). In generale, paga non essere troppo dogmatico. La maggior parte dei consigli di programmazione è perché hanno dimostrato di funzionare in pratica, ma non sono la verità assoluta, quindi non preoccuparti troppo. Continua a leggere e vai con ciò che ritieni sia più corretto, ma non reinventare nemmeno la ruota. È probabile che qualcuno più intelligente di noi abbia già trovato soluzioni migliori delle nostre.

— DPM,

Un metodo con un nome di 70 caratteri probabilmente fa più di una cosa. Violazione SRP ho ragione ?!

— Tombatron,

Ecco un altro pensiero, tra 5 o 10 anni da quando sei uno sviluppatore in un'azienda a cui potrebbe interessare di meno il codice pulito, apprezzerai davvero questo esercizio dogmatico.

— Tombatron,

Avendo lavorato (brevemente) sotto "nessun commento", preferisco di gran lunga che sia una linea guida forte di una regola. Ci sono momenti in cui sono necessari commenti, di solito in una logica commerciale oscura. Un metodo chiamato CalculateFoonicityMetric()ti dice esattamente cosa sta facendo, e un codice ben scritto ti mostrerà come ... ma nessuno di questi ti dice perché . Il codice può essere ovvio in cosa (moltiplicare questo per quello, dividerlo per l'altra cosa, quadrarlo, aggiungerlo su questo bit ...) ma non è chiaro perché (fattore = a * b / c; quadrato per tenere conto di pippo negativo, regolare per deriva ...). Apprezzo un breve commento che spiega il perché.

— anaximander,

Risposte:

Capisco che questo codice pulito è un investimento a lungo termine che faciliterà la manutenzione e il miglioramento del codice, ma ... ne vale davvero la pena?

Assolutamente.

Il re-factoring è molto importante, ma passare il 75% del tempo a spostare i metodi e spendere un sacco di tempo per decidere il proprio titolo non sembra essere così produttivo.

Certo, ma considera che la grande azienda probabilmente ha anni o decenni di codice cattivo da ripulire. Ci vorrà molto tempo e sforzi per farlo.

La cosa principale da capire è che hai ragione entrambi. Il "codice pulito" è molto importante e il codice pulito è un modo universalmente rispettato per arrivarci. Dal momento che la società ha appena iniziato il percorso, saranno osservati nel libro più di un gruppo che ha più esperienza. Dopo averlo fatto per un breve periodo, inizieranno a imparare cosa funziona e cosa no. Una volta che lo capiranno meglio, seguiranno (si spera) un approccio più pragmatico e naturale che mantiene pulito il codice, ma non porta a 70 nomi di funzioni char.

— Telastyn
fonte

Inizialmente stavo scrivendo un commento. Proverò a dare meno di una risposta rispetto alle prospettive da considerare. Tuttavia, approvo assolutamente le pratiche "Clean Code" come la denominazione e il refactoring comprensibili.

Non ho sempre apprezzato le regole di non commento , in quanto vi sono casi in cui i commenti sono necessari per prevenire future rotture del codice. Normalmente dovrebbero essere limitati a ciò che viene fatto e perché. Usali con parsimonia quando il codice sta facendo qualcosa di inaspettato o è necessario sostituire un algoritmo.

Considera la produttività quando leggi o gestisci il codice. Nel corso della vita del codice, questo può essere più importante della produttività quando si scrive il codice. Queste pratiche aiuteranno la produttività in questi compiti?

Con l'esperienza, queste pratiche dovrebbero radicarsi, e meno di un killer della produttività. La scelta del nome giusto potrebbe richiedere più tempo perché stai chiarendo cosa deve fare il codice. (Questo chiarimento può rendere più veloce la codifica e il debug.) Questo porta a un codice che fa solo ciò che è richiesto o che ha meno bug? Che effetto ha questo sulla produttività?

Il tempo impiegato nella scelta del nome del metodo corretto probabilmente ripagherà immediatamente per una migliore comprensione dello scopo del metodo. Confronta i nomi dei metodi "iterateOverCustomers" con "LocateActiveCustomers". Quale trasmette l'intento della funzione? Quale sarà più facile da refactoring se necessario?

— BillThor
fonte

Vorrei sottolineare che la regola del "nessun commento" che alla gente piace attribuire al libro Clean Code non si trova in nessun punto del libro. Al contrario, c'è un intero capitolo sui commenti, la prima metà del quale viene spesa descrivendo molti tipi di "commenti positivi", seguita dalla sezione sui "commenti negativi". Le opinioni dell'autore sulla questione sono in realtà molto più ragionevoli di quanto molti gli attribuiscano credito.

— Eric King,

Stavo commentando le regole "nessun commento" in generale. Ho lavorato in lingue in cui ci sono state proposte per rimuovere i commenti dalla definizione della lingua. Nessun commento buono o cattivo. All'epoca avevamo un commento in un blocco di codice in cui in alcuni casi era desiderabile passare in rassegna. C'è stato un commento che avvertiva che era così e non aggiungere nuovi blocchi di codice a quel punto.

— BillThor,

Sì, mi sembra abbastanza estremo.

— Eric King,