¿Qué partes de Code Complete no han resistido el paso del tiempo? [cerrado]

Estaba mirando Code Complete en el estante, pensando: "Fuera del Mes del Hombre Mítico, este puede ser uno de los pocos libros de Ingeniería de Software del mercado masivo que resiste el paso del tiempo". Por esta razón, estoy pensando en saltar para releerlo.

Tengo curiosidad: ¿alguien más lo ha revisado recientemente? Entonces, ¿viste algo que se equivocó mucho?

Esto no es un ataque, y no una solicitud de revisión de un libro; estoy más interesado en las ideas que han cambiado a lo largo de los años.

Y por favor, sin comentarios sobre "Demarco / Spewak / Zachman resistió la prueba del tiempo ..." Estoy específicamente interesado en Code Complete debido a la amplitud del terreno que cubre y la amplitud del impacto que tuvo en el campo.

Code Complete cubre muchos conceptos atemporales como:

• fuerte cohesión
• bajo acoplamiento
• buenos nombres de rutina
• programación defensiva
• código autodocumentado
• revisiones de software
• examen de la unidad

que sin duda son relevantes hoy.

Algunos de los conceptos defendidos en CC ahora se aplican de manera sintáctica en lenguajes más nuevos, por ejemplo, C # no permite que la variable en los sub-ámbitos se defina de una manera que oculte una definición súper-alcance.

Otros conceptos, como la notación húngara para nombres de variables han quedado en el camino en la programación convencional (aunque cualquiera que todavía trabaje con la API Win32 argumentará con vehemencia que están vivos y bien). Sin embargo, el concepto real detrás de la convención de nomenclatura variable es transmitir el significado necesario y aclarar el código, conceptos que yo diría que también son intemporales.

En total, por lo que puedo recordar (y un vistazo rápido dentro de mi venerable copia de CC), diría que ciertamente vale la pena revisarlo.

Sin embargo, no creo que se eleve a la naturaleza verdaderamente atemporal del Mes del Hombre Mítico. MMM aborda cuestiones de quién está haciendo el trabajo, cómo y por qué lo están haciendo; así como los costos y la complejidad de las comunicaciones (humanas). MMM aborda problemas que son fundamentales para todo lo que hacemos. CC, en comparación, se centra en cuestiones prácticas y pragmáticas de cómo lo hacemos. Dicho de otra manera, si un proyecto está retrasado y un gerente decide agregar 100 personas al equipo, escribir un código comprensible realmente no hará la diferencia.

CC realmente no aborda problemas importantes que afectan a nuestra industria; pero proporciona una buena base para luchar por el mejor resultado en una situación a menudo imposible.

Sin duda consideraría que ambos requieren lectura para cualquiera que se preocupe por el desarrollo de software; y recomendaría volver a leer MM cada vez que necesite un repaso. Vale la pena releer CC si está liderando un equipo de desarrollo, estableciendo estándares grupales o capacitando a nuevos desarrolladores; fuera de eso, personalmente encuentro que hace mucho tiempo internalicé el material en CC y lo practiqué a diario.

Esperanzas que ayuden. Ciertamente son dos de mis favoritos.

En general, el libro sigue siendo bueno. Sin embargo, tengo algunos pequeños problemas:

• Capítulo 17 ( "inusuales Estructuras de Control") hace mención declaraciones de guardia como regresar de una función temprana, pero los ejemplos dados en el capítulo 15 de "if" aconsejar contra declaraciones de guardia. (Llamado cláusulas de guardia / devoluciones anticipadas en el libro)
• El ejemplo en la sección 14.2 parece contradecirse. Primero da un ejemplo de código "malo" y cómo hacerlo "bueno". Luego establece que, al agrupar las declaraciones relacionadas, ya sea por datos o por similitud de tareas sería "bueno". El ejemplo "malo" también debería considerarse "bueno", y creo que es mucho más fácil de leer que el ejemplo "bueno", ya que todos los datos se calculan a la misma velocidad: hay menos estado que mantener en la cabeza .
• Capítulo 23, Depuración, donde las declaraciones de impresión se vilipendian en una viñeta. Aunque estoy de acuerdo que no deben ser la única herramienta, que son enormemente útiles para reducir el rango de código en la que se produce el fallo. Espolvorea un poco para ver dónde los datos de repente no son lo que esperas, da un buen punto de partida para la depuración, dependiendo del código con el que estés trabajando.

Tengo un vago recuerdo de otro que involucra argumentos de funciones, pero no puedo encontrarlo en este momento. Puede haber sido otro libro.