Libros Ingeniería del Software

Meleagant

Estoy buscando libros sobre ingeniería del software. Principalmente necesito algo práctico, para organizarme mejor a la hora de sacar adelante proyectos, ya que veo que por falta de organización me acaban surgiendo bastantes problemas que al final suponen un tiempo de desarrollo extra, dolores de cabeza y revisiones de código que ya he olvidado lo que hacía con demasiada frecuencia.

He buscado por Internet y he visto estos títulos recomendados:

  • Rapid Developtment (Steve McCornell)
  • UML: el proceso unificado de desarrollo de software
  • Ingeniería del Software: Un enfoque práctico (Pressman)

¿Alguno conocéis alguno de estos títulos y sabéis si podrían serme útiles para lo que necesito? Me da la sensación de que algunos títulos están centrados en la división de tareas y el trabajo en equipo, cosa que ahora mismo no es lo que me interesa.

Si sabéis algún otro libro, se aceptan sugerencias.

Muchas gracias :)

PD: Moderadores, ante la falta de una categoría general de "Desarrollo", lo he etiquetado como "Se Busca", sé que no es la categoría adecuada, pero no encuentro otra mejor.

B

· TDD: El de Kent Beck está bien, aunque es exageradamente básico. Si sabes algo de diseño y lo complementas con lo que saques de esto, puede ayudar bastante.
· Patrones de diseño: GoF, muy fácil de leer y si te lo miras a fondo aprenderás bastante de diseño (y unos cuantos patrones).
· Luego también tienes el Pragmatic Programmer (a mí no me gustó nada, ni siquiera me lo acabé) y el Clean Code (que me encantó, es más a nivel de implementación pero ayuda mucho también a hacer mejor software).

Leerme un libro sobre UML me parece una locura, pero allá tú :)

PD: De todas formas, por lo que comentas tu problema es de diseño. Haz tests (intenta una cobertura cercana al 100%, si ves que no es posible en muchos casos es por no hacer un diseño todo lo deseable posible) y léete el GoF. En serio, los tests son básicos. Si tienes una buena cobertura puedes hacer cambios/mejoras al software sin preocuparte de romper nada.

PD2: Extra -> http://programmers.stackexchange.com/questions/124109/is-there-a-canonical-book-on-design-patterns

3 respuestas
gAdrev

Planteas varias cuestiones, y no todas se responden necesariamente con metodologías de ingeniería de software per se.

Para lo que dices que te olvidas qué hiciste en código, dos vías: una, control de versiones robusto y por otro lado temas de estilo y buenas prácticas.

Para lo primero git, period. Bueno, para no ser dogmático, te diría que te inclinases por cualquiera de las alternativas modernas, por ejemplo hg también está bien.

Para lo segundo mientras escribía este post ya han puesto algunos libros en el post de encima #2. GoF es el clásico en patrones de diseño, y principal referencia sin duda, pero para introducirte a los patrones más útiles puede gustarte también Head First Design Patterns.

Ten en cuenta que el proceso de desarrollo estilo cascada está siendo reemplazado en muchos tipos de proyectos por las metodologías ágiles. No te ciñas a una metodología fija, compara y mira cuál te va mejor según el tipo y tamaño de proyecto.

paulvandyk

Por lo que comentas, pienso que deberías concretar qué problemas tienes. Y a partir de ahí te recomendamos libros.

La Ingeniería del Software engloba tantas cosas, que da para libros y libros, probablemente no son lo que buscas realmente.

De los libros que has puesto:

  • Rapid Development (Steve McCornell) => Te va a explicar una metodología de desarrollo. (La palabra Rapid no es lo que parece).

  • UML: el proceso unificado de desarrollo de software => No sé que libro es, pero hay que puntualizar una cosa, el "proceso unificado de desarrollo de software" (RUP) que es otra metodología de desarrollo (muy buena, por cierto) y UML que es un lenguaje de modelado, muy útil e imprescindible, que sirve para describir cómo va a funcionar tu sistema, creado por los mismo que el RUP. Pero son cosas diferentes.

  • Ingeniería del Software: Un enfoque práctico => Mirando el índice parece que es un resumen de lo básico. Aunque no sé si es bueno el libro en sí, puede que sea un buen punto de partida.

Wasd

Como ha dicho #2, yo te recomiendo Clean Code (Código Limpio en su edición española). No trata directamente patrones de diseño pero sí que se enfoca en formas de ordenar el código que te pueden ahorrar muchos dolores de cabeza (a ti mismo, a tu equipo y a quienes toquen tu código en el futuro). Me lo estoy leyendo y está muy bien.

Meleagant

Muchas gracias a todos por la ayuda.

Quizá no me he explicado muy bien respecto a cuál es mi problema. La cuestión es que a menudo me pongo a programar, y voy añadiendo funcionalidades a medida que voy viendo cómo quiero que quede el resultado final. Esto suele conllevar cambios en el código para readaptar lo que ya había hecho al nuevo contenido. Está claro que el problema es que no parto de un análisis y planificación conjuntos de todo el proyecto.

Creo que me pondré con el libro de Clean Code, ya que leyendo resúmenes por ahí veo que toca temas como los que os comentaba, por ejemplo me doy cuenta de que a veces creo funciones que no son todo lo concisas que deberían, sino que hacen varias tareas en una misma función. Esto desemboca en que cuando tengo que hacer algún cambio que las afecta, y necesito revisarlas dos semanas después, por muy comentado que tenga el código (y esto sí que lo hago) tengo que dedicar tiempo extra a entender de nuevo por qué esa función hace todas las cosas que hace.

Me apunto todos los títulos que habéis comentado, porque es un tema que me interesa bastante.

Muchas gracias de nuevo :)

1 respuesta
Dostoievski

#6 RRR: Refactoring, refactoring y refactoring.

No te queda otra, es que no hay más. Experiencia y refactorizar el código. Comentar código suele ser bastante absurdo (diría que el 90% o 95% de los comentarios que vas a ver en un código son malos, redundantes, obsoletos y no sirven para nada) y el diseño global de tu aplicación, a medida que tengas más experiencia y hayas mamado mucho framework (o por ejemplo, participando en proyectos open source) irá mejorando pero tu código va a tener que cambiar siempre, por mucho análisis que hagas. Es algo que no podrás evitar porque hay decisiones que hay que tomar un poco a ciegas para avanzar o porque los requisitos cambian, sin más.

Por eso buenas las practicas son necesarias, para que sea más fácil cambiarlo y saber qué se rompe cuando se cambia algo (tests).

Clean Code es un libro muy bueno aunque te darás cuenta de que todo lo que dice ya lo sabías. Todos los conceptos son muy fáciles de asimilar y obvios, cualquier programador los conoce y el problema es que nos olvidamos de ellos para ir por la vía rápida que acaba siendo la vía lenta con la promesa de "en el siguiente proyecto lo haré bien" o "ya lo corregiré mañana".

eisenfaust

The Mythical Man-Month y Coders at Work son los unicos que me han gustado sobre el tema.

En cuanto a design patterns, Head First Design Patterns es un libro infravaloradisimo xD Aunque todo eso de los patrones es mas bien para los que les guste llevar corbata a cambio de un cuenco de arroz (bait).

2
1 mes después
Meleagant

Me compré el libro de Clean Code y lo voy leyendo con calma cuando tengo ratos.

Me parece curiosa la forma en que recomienda que ninguna función tenga más de 3 ó 4 líneas. Entiendo la lógica que sigue para hacer el código legible, pero ¿esto os parece práctico? Al final terminarías teniendo una ristra de funciones tan larga que creo que hasta resultaría incómodo manejarla. ¿No es un poco extremo? ¿Alguna opinión al respecto?

2 respuestas
B

#9 depende del software que estés haciendo aunque yo en general lo prefiero así. Si veo una función de más de 20 líneas me da alergia, la legibilidad pierde muchísimo.

Si tienes funciones muy largas es probable que o bien estés mezclando distintos niveles de abstracción (asqueroso) o bien violando el SRP.

1 1 respuesta
Meleagant

#10 Ya, pero es que una cosa es una función de más de 20 líneas, y otra una función de sólo 3, que es como sugiere el libro que deberían ser todas.

1 respuesta
B

#11: Cambia 3 por 5, o por 7. Ahí ya es tu criterio.

EDIT: Yo según lo que sea suelo ponerme un límite de unas 10, porque muchas veces entre mensajes de logging, declaración de variables y demás... pero vaya, la cosa es respetar el nivel de abstracción y el SRP.

Spacelord

"La cuestión es que a menudo me pongo a programar, y voy añadiendo funcionalidades a medida que voy viendo cómo quiero que quede el resultado final".

Este es el problema.

En mi opinión, lo primero que deberías mirar es el diseño en cascada (waterfall), que va desde el análisis y diseño hasta la implementación. Y sigue a rajatabla esa metodología, no empieces a programar hasta que no tengas bien claro qué va a hacer el programa y cómo va a hacerlo. Una vez entiendas y apliques correctamente el diseño en cascada ya puedes empezar a mirar TDD y demás patrones de diseño.

B

#9 En cuanto a libro sobre código legible yo prefiero The Art of Readable Code. Los libros de Uncle Bob están muy bien (el Clean Coder podrías echarle un ojo tambien) pero el TAoRC me gusta recomendarlo, especialmente, a los que empiezan a trabajar profesionalmente de programadores por su enfoque pragmático.

Luego en mi stack de la bibliografía para nuevos programadores y que no habeis mencionado por aqui yo tengo el Peopleware (si trabajas con gente), The Mythical Man-Month y User Interface Design for Programmers.

Y, cuando lleves dos o tres años currando profesionalmente, nunca está de más leerte The Passionate Programmer, que no es exactamente sobre "ingenieria de software", sino que estaría casi cerca del libro de auto-ayuda, pero vale bastante la pena.

p0stm4n

¿Nadie recomienda Code Complete? :-(

1
p0stm4n

Repetido.

1 año después
bultack

#2 Merece la pena el libro de Clean Code? He visto a gente decir que está bastante bien y que es útil pero me gustaría tener opiniones que vayan más allá del "te lo recomiendo, está muy bien"

1 respuesta
DarkSoldier

Bultack ha usado revivir, es muy efectivo.

2 1 respuesta
Meleagant

#17 Yo me lo compré y me ha venido muy bien, no sé qué es exactamente lo que quieres que te digamos...

2 respuestas
varuk

#19 ¿Te lo compraste en castellano o en inglés? He leido que la versión traducida es un poco floja...

Por cierto, os dejo esto por aquí, que creo que cuadra con lo que se está hablando como recurso:
http://97cosas.com/programador/

1 1 respuesta
bultack

#18 No me había fijado en las fechas xD

Weahl

#19 #20 Tuve la versión española y me acabé pasando al inglés porque la española hacía traducciones demasiado literales, no la recomiendo.

Camperito

Os voy a recomendar el unico libro que tenéis que comprar y ya.

Clean code. Me cago en la ostia ya que estoy hasta la polla de leer código de recién salidos de universidad que no tienen ni puta idea

http://www.amazon.es/Clean-code-Handbook-Software-Craftsmanship/dp/0132350882

eXtreM3

Alguien conoce algún buen libro sobre algoritmos? Ejemplos, conceptos, bases, para qué se utilizan, qué algoritmo crear/utilizar para X problema... A ser posible en español, pero si es un buen buen libro en inglés no me importaría adquirirlo. Gracias.

1 respuesta
MTX_Anubis

#24 Aquí hay uno en español que usé para la carrera

Si tienes cojones vete a por Art of computer programming. En la wikipedia hay referencias

Si quieres cosas más concretas tendrás que mirarte libros de esa materia y ver qué se utiliza, por ejemplo Paxos o Raft para negociar líderes.

1 respuesta
eXtreM3

#25 te resultó útil? 46€ lo veo algo caro a simple vista...

No necesito nada concreto, simplemente quiero ir aumentando mi capacidad de resolver problemas de la manera más eficiente posible.

1 respuesta
MTX_Anubis

#26 Útil? Por supuesto y completo también. 46€ no es caro para un libro técnico, es un precio normal en españa. Ahora que lo vayas a usar en tu día a día es otro cantar xD

http://ldc.usb.ve/bonet/courses/ci2525/Brassard_Bratley_Fundamentals_of_Algorithmics_ES.pdf

Ahí está el pdf por si le quieres echar un vistazo, si buscas encontrarás más pdfs también vamos, está en la bibliografía de todas las facultades de informática.

B

Además de algunos que te comentan, como el clean code, que está muy, muy bien. Yo te recomiendo los que utilizamos en la carrera, aunque uno es excesivamente teórico, el otro está bastante bien:

Ingenieria del Software, Ian Somerville. <-- Este es teoría, teoría y teoría, muy bien explicado eso si, pero mucha teoría, aunque bueno, como base para luego ir a algo práctico, lo recomiendo.
UML y patrones, Craig Larman. <--- Este está bastante bien, va a explicando los patrones con ejemplos de un caso práctico.

Usuarios habituales