Quali parti del codice completo non hanno superato la prova del tempo? [chiuso]

Stavo guardando Code Complete sullo scaffale, pensando: "Al di fuori del Mese dell'uomo mitico, questo potrebbe essere uno dei pochi libri di Ingegneria del software del mercato di massa a resistere alla prova del tempo". Per questo motivo, sto pensando di saltare dentro per rileggerlo.

Sono curioso: qualcun altro l'ha recentemente dato una seconda occhiata? Ho visto qualcosa che ha sbagliato molto?

Questo non è un attacco e non una richiesta di revisione di un libro: sono più interessato a quali idee sono cambiate nel corso degli anni.

E per favore - nessun commento su "Demarco / Spewak / Zachman ha resistito alla prova del tempo ..." Sono particolarmente interessato a Code Complete a causa dell'ampiezza del terreno che copre e dell'ampiezza dell'impatto che ha avuto sul campo.

Code Complete copre molti concetti senza tempo come:

• forte coesione
• accoppiamento lasco
• buoni nomi di routine
• programmazione difensiva
• codice auto-documentante
• recensioni di software
• test unitari

che sono certamente rilevanti oggi.

Alcuni dei concetti sostenuti in CC sono ora applicati sintatticamente in linguaggi più recenti, ad esempio C # non consente di definire variabili in sotto-ambiti in un modo che nasconde una definizione super-ambita.

Altri concetti, come la notazione ungherese per nomi di variabili, sono caduti ai margini della programmazione tradizionale (anche se chiunque lavori ancora con l'API Win32 sosterrà con veemenza che sono vivi e bene). Tuttavia, il vero concetto alla base della convenzione sulla denominazione variabile è quello di trasmettere il significato necessario e chiarire il codice, concetti che direi sono anche senza tempo.

Tutto sommato, da quello che posso ricordare (e una rapida occhiata alla mia venerabile copia di CC), direi che vale sicuramente la pena di rivederlo.

Non credo, tuttavia, che arrivi alla natura davvero senza tempo di The Mythical Man Month. MMM affronta i problemi di chi sta facendo il lavoro, come e perché lo stanno facendo; nonché i costi e la complessità delle comunicazioni (umane). MMM affronta questioni fondamentali per tutto ciò che facciamo. CC, in confronto, si concentra su questioni pratiche e pragmatiche di come lo facciamo. Detto in altro modo, se un progetto è in ritardo e un manager decide di aggiungere 100 persone al team, scrivere un codice comprensibile non farà davvero la differenza.

CC non affronta realmente problemi significativi che affliggono il nostro settore; ma fornisce una buona base per cercare il miglior risultato in una situazione spesso impossibile.

Li considererei sicuramente entrambi richiesti per chiunque si occupi dello sviluppo del software; e consiglierei di rileggere MM ogni volta che hai bisogno di un aggiornamento. CC vale la pena rileggere se stai guidando un team di sviluppo, stabilendo standard di gruppo o formando nuovi sviluppatori; al di fuori di ciò, trovo personalmente che da tempo ho interiorizzato il materiale in CC e lo pratico quotidianamente.

Speranze che aiutino. Sono sicuramente due dei miei preferiti.

Nel complesso, il libro è ancora buono. Tuttavia, ho alcuni piccoli problemi con esso:

• Capitolo 17 ( "Unusual Strutture di controllo") fa dichiarazioni di guardia menzione come di ritorno da una funzione di anticipo, ma gli esempi forniti nel Capitolo 15 sulla "if" consigliare contro le dichiarazioni di guardia. (Chiamate clausole di guardia / primi ritorni nel libro)
• L'esempio nella sezione 14.2 sembra contraddirsi. Dà prima un esempio di codice "cattivo" e come renderlo "buono". Indica quindi che, quando si raggruppano insieme dichiarazioni correlate, la somiglianza tra dati o attività sarebbe "buona". L'esempio "cattivo" dovrebbe quindi essere considerato "buono" - e, credo, molto più facile da leggere dell'esempio "buono", poiché tutti i dati vengono calcolati alla stessa velocità - c'è meno stato da tenere in testa .
• Capitolo 23, Debug, in cui le dichiarazioni di stampa sono diffuse in un punto elenco. Anche se concordo sul fatto che non dovrebbero essere l'unico strumento, sono enormemente utili nel ridurre la gamma di codice in cui si verifica il bug. Spargetene un po 'ovunque per vedere dove improvvisamente i dati non sono quelli che vi aspettate, offre un buon punto di partenza per il debug, a seconda del codice con cui state lavorando.

Ho un vago ricordo di un altro argomento che coinvolge funzioni, ma al momento non riesco a trovarlo. Potrebbe essere stato un altro libro.