Quali parti di Code Complete non hanno superato la prova del tempo? [chiuso]

14

Stavo guardando Code Complete sullo scaffale, pensando: "Al di fuori del Mese di Mythical Man, questo potrebbe essere uno dei pochi libri di ingegneria del mercato di massa a superare la prova del tempo." Per questo motivo, sto pensando di saltare dentro per rileggerlo.

Sono curioso - qualcun altro ha dato un secondo sguardo di recente? Io così, hai visto qualcosa che ha sbagliato?

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 superato la prova del tempo ..." Sono interessato in particolare al Codice Completo a causa della vastità del campo che copre e dell'impatto che ha avuto sul campo .

    
posta MathAttack 11.03.2012 - 22:28
fonte

2 risposte

11

Codice completo copre molti concetti senza tempo come:

  • strong coesione
  • accoppiamento lento
  • buoni nomi di routine
  • programmazione difensiva
  • codice auto-documentale
  • recensioni di software
  • test delle unità

che sono certamente rilevanti oggi.

Alcuni concetti sostenuti in CC sono ora applicati in modo sintattico nei linguaggi più recenti, ad esempio C # non consente la definizione della variabile in sotto-ambiti in modo da nascondere una definizione super-spettrale.

Altri concetti, come la notazione ungherese per i nomi di variabili, sono caduti nel dimenticatoio della programmazione mainstream (sebbene chiunque stia ancora lavorando con l'API Win32 sosterrà con veemenza di essere vivi e vivi). Ciononostante, il vero concetto alla base della convenzione di denominazione delle variabili è quello di trasmettere significato necessario e chiarire il codice, concetti che anch'io sosterrei sono anche senza tempo.

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

Non penso, tuttavia, che salga alla natura veramente senza tempo del Mese di Mythical Man. MMM affronta i problemi di chi sta facendo il lavoro, come e perché lo stanno facendo; così come i costi e la complessità delle comunicazioni (umane). MMM affronta questioni che sono fondamentali per tutto ciò che facciamo. CC, in confronto, si concentra su questioni pratiche e pragmatiche su come lo facciamo. In altre parole, se un progetto è in ritardo sulla pianificazione e un manager decide di aggiungere 100 persone al team, scrivere un codice comprensibile non farà davvero la differenza.

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

Sicuramente li considererei entrambi obbligati a leggere per chiunque abbia a cuore lo sviluppo del software; e raccomanderei 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 questo, personalmente scopro di aver interiorizzato molto tempo fa il materiale in CC e di praticarlo quotidianamente.

Le speranze aiutano. Sono sicuramente due dei miei preferiti.

    
risposta data 11.03.2012 - 23:58
fonte
4

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

  • Il Capitolo 17 ("Strutture di controllo insolite") menziona le istruzioni di guardia come restituite da una funzione in anticipo, ma gli esempi riportati nel Capitolo 15 sulle istruzioni "if" consigliano istruzioni di contro . (Chiamate clausole di salvaguardia / ritorni anticipati nel libro)
  • L'esempio nella sezione 14.2 sembra contraddire se stesso. Prima fornisce un esempio di codice "cattivo" e come renderlo "buono". Quindi afferma che, quando si raggruppano insieme le dichiarazioni correlate, sia per dati che per somiglianza dell'attività sarebbe "buono". L'esempio "cattivo" dovrebbe quindi essere considerato "buono" - e, penso, molto più facile da leggere rispetto all'esempio "buono", perché tutti i dati vengono calcolati alla stessa velocità - c'è meno stato da tenere in testa .
  • Capitolo 23, Debug, in cui le istruzioni di stampa vengono villificate in un punto elenco. Mentre sono d'accordo sul fatto che non dovrebbero essere l'unico strumento, sono enormemente utili nel ridurre l'intervallo di codice in cui si verifica il bug. Spargere un po 'ovunque per vedere dove i dati improvvisamente non sono quelli che ti aspetti, fornisce un buon punto di partenza per il debug, a seconda del codice con cui stai lavorando.

Ho una vaga memoria di un altro argomento della funzione coinvolgente, ma non riesco a trovarlo al momento. Potrebbe essere stato un altro libro.

    
risposta data 12.03.2012 - 04:18
fonte

Leggi altre domande sui tag