Autor: John Lakos
Editorial: Addison-Wesley
Páginas: 988
ISBN: 978-0201717068
Prensa: 0201717069
Kindle: B0826523GZ
Público: programadores con mucho tiempo que perder
Calificación: 3
Revisor Mike James:
C ++ a gran escala, ¿qué puede significar?
Bueno, definitivamente significa un libro a gran escala: con más de 900 páginas tuve problemas en la muñeca al intentar leerlo. También debo admitir que no lo he leído todo y dudo que muchos lectores lo lean de principio a fin. También debo admitir que, después de comenzar a leerlo, me llamó la atención la sensación de que programar no puede ser tan difícil como sugiere este libro. ¿Quién, con un cerebro humano razonable, puede absorber esta cantidad de cosas? En un buen sistema lógico, lo que necesita son algunas reglas generales que puede aplicar, no 900 páginas de pequeñas reglas de diseño detalladas, cientos de ellas …
Este es un libro de hechizos y, aunque la mayoría de ellos se basan en el sentido común, no logran formar un todo coherente. Si se supone que los buenos programadores deben memorizar, o incluso intentar comprender. tantos detalles para que no tengan mucho que hacer para otra cosa.
Lo que también es importante es saber que estas reglas no son generales en el sentido de que se relacionen con el diseño en un contexto sin lenguaje. Se tratan de C ++ y algunos de sus extraños trucos. Algunos libros de arquitectura te hacen sentir mejor en tu idioma favorito. Esto comenzó a hacerme pensar que C ++ no era un lenguaje que cualquier programador en su sano juicio elegiría. En esto, ahora comparto la opinión de Linus Torvalds:
«C ++ es un lenguaje terrible».
El primer capítulo analiza compiladores y enlazadores y es mucho más fácil de entender si ya tiene una idea clara de lo que hacen y cuáles son las compensaciones. Algunos ejemplos son divertidos, pero la mayoría son obvios tan pronto como piensa en lo que está sucediendo: las declaraciones y definiciones no se resuelven hasta el momento en que se vincula. Mi sensación fue «y qué, siempre y cuando el problema se identifique en algún momento y no se haya hecho ningún daño» y mi segunda sensación fue que la mayoría de las cosas enumeradas deberían suceder automáticamente si el proyecto está razonablemente bien documentado.
El segundo capítulo mezcla ideas de empaque con reglas de diseño. Entre en algunos detalles muy pequeños, como cuándo debe usar guiones bajos en los nombres y cuándo el caso del camello. Personalmente, no creo que ninguna de estas ideas resuelva el problema de los nombres. Hay muchos diagramas de estructuras de programas aparentemente enormes; si tiene un programa tan grande, probablemente sea demasiado tarde para volver atrás y simplificar las cosas.
El capítulo 3 concluye el libro: sí, solo tres capítulos. Se trata de diseño físico y refactorización y básicamente se trata de evitar dependencias cíclicas y utilizar estructuras laterales en lugar de capas.
Conclusión:
Hubo grandes secciones de este libro que me parecieron interesantes, pero debo admitir que seguí tratando de ver una imagen más amplia y una no parecía estar disponible. O se trataba de microgestión de cosas o pasar a grandes visiones generales que eran difíciles de precisar. Esto no es tanto una filosofía de la arquitectura como un libro de reglas con justificaciones. También era repetitivo de los principios básicos: sí, las adicciones cíclicas son malas. Si el libro tuviera unas 200 páginas, podría funcionar mejor, ya que hay volúmenes II y III para contemplar.
Para mantenerse al día con nuestra cobertura de libros de programación, siga @bookwatchiprog en Twitter o suscríbase a la fuente RSS de The Programmer’s Books por cada día adicional para ver libros y nuevas reseñas.
