¿Qué partes de Code Complete no han pasado la prueba del tiempo? [cerrado]

14

Estaba mirando el Código Completo 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 para pasar la prueba del tiempo". Por este motivo, estoy pensando en saltar para releerlo.

Tengo curiosidad: ¿alguien más le ha echado un vistazo recientemente? Yo, ¿viste algo que se equivocó mucho?

Esto no es un ataque, ni una solicitud de reseña de un libro. Estoy más interesado en saber qué ideas han cambiado con los años.

Y, por favor, no haga comentarios sobre "Demarco / Spewak / Zachman pasó la prueba del tiempo ..." Estoy especialmente interesado en el Código Completo debido a la amplitud del terreno que cubre, y la amplitud del impacto que tuvo en el campo .

    
pregunta MathAttack 11.03.2012 - 22:28

2 respuestas

11

El código completo cubre muchos conceptos atemporales como:

  • cohesión fuerte
  • acoplamiento suelto
  • buenos nombres de rutina
  • programación defensiva
  • código de auto-documentación
  • revisiones de software
  • pruebas unitarias

que son ciertamente 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 sub-ámbitos se defina de una manera que oculte una definición de ámbito amplio.

Otros conceptos, como la notación húngara para nombres de variables, se han quedado en el camino de la programación general (aunque cualquiera que aún esté trabajando con la API de Win32 argumentará con vehemencia que está vivo y en buena forma). Sin embargo, el concepto real detrás de la convención de nomenclatura de variables es transmitir el significado necesario y aclarar el código, conceptos que diría que también son atemporales.

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

Sin embargo, no creo que se convierta en la verdadera naturaleza eterna del Mes del Hombre Mítico. MMM aborda los problemas 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 cuestiones 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á una diferencia.

CC no aborda realmente los 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 releer MM cuando necesites un repaso. Vale la pena volver a leer CC si está liderando un equipo de desarrollo, estableciendo estándares de grupo o capacitando a nuevos desarrolladores; fuera de eso, personalmente encuentro que hace mucho tiempo que internalicé el material en CC y lo practiqué a diario.

Espera que ayude. Sin duda son dos de mis favoritos.

    
respondido por el Robert Altman 11.03.2012 - 23:58
4

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

  • El Capítulo 17 ("Estructuras de control inusuales") menciona que las declaraciones de guardia regresan de una función antes, pero los ejemplos dados en el Capítulo 15 sobre declaraciones "si" advierten a en contra de declaraciones de guardia. (Llamadas cláusulas de guardia / primeras devoluciones en el libro)
  • El ejemplo en la sección 14.2 parece contradecirse a sí mismo. Primero da un ejemplo de código "malo", y cómo hacerlo "bueno". A continuación, establece que, al agrupar declaraciones relacionadas, ya sea por datos o por similitud de tareas, sería "bueno". El ejemplo "malo" también debe 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. .
  • Capítulo 23, Depuración, donde las declaraciones impresas se villifican en un punto. Si bien estoy de acuerdo en que no deberían ser la única herramienta, son enormemente útiles para reducir el rango de código donde se produce el error. Espolvorear unos cuantos para ver dónde los datos no son lo que espera de repente, lo que proporciona un buen punto de partida para la depuración, según el código con el que esté trabajando.

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

    
respondido por el Izkata 12.03.2012 - 04:18

Lea otras preguntas en las etiquetas