En mi punto de vista, la capacidad de diseño es más difícil de obtener que desarrollo/habilidades de codificación.¿Cómo mejorar las habilidades de diseño de software?
Al enfrentar un requisito, ¿cómo diseñar los módulos de función, cómo construir la arquitectura del programa correctamente?
Por cierto, ¿hay algunos libros relacionados?
Creo que la respuesta es lo que la mayoría de los programadores mediocres a menudo no hacen: leer el código de otras personas y aprender de él, analizar sus puntos fuertes y débiles, y también incorporar en sus propios trucos de programación lo que les parezca interesante. Hay muchas buenas técnicas que ya están inventadas, le darán más poder a sus habilidades de codificación y le ahorrarán mucho tiempo.
Hay muchos códigos de alta calidad disponibles en proyectos de código abierto para la investigación.
Prueba y error es la mejor manera de ver cómo sus propios diseños pueden mejorar. Siempre busca una mejor solución. ¿Qué errores cometiste? ¿Qué parte fue menos flexible de lo que necesitaba ser? ¿Qué hizo que debas hackear una decisión de diseño que tomaste?
Piense en las implicaciones del diseño en lugar de pura flexibilidad y elegancia. ¿Qué intercambios ha realizado para que esto sea reutilizable? ¿Está siguiendo el seperation of concerns y el single responsibility principle? Open closed principle? ¿Sabes cuáles son y sus implicaciones?
También estudie el trabajo de los expertos en forma de patrones de diseño.
Leer Design Patterns Explained by Shalloway, Read Head first design patterns
Sin embargo recordar que estos no son soluciones mágicas bala y tomar todo con una pizca de sal. Usa tu propia creatividad y PERMANECE PRAGMATIC.
Creo que todo se reduce a la experiencia. Poder leer un conjunto de requisitos y traducirlos en un diseño de software bueno, limpio y fácil de mantener es uno de los más difíciles de programar (imho) y no se aprende solo con la lectura de un libro. Se trata de intentar, cometer errores, aprender de esos errores y aprender qué diseños han funcionado para ti en el pasado o no.
Para mí, a menudo me ayuda realmente tomarse mi tiempo y crear un buen diseño en UML, por ejemplo, un diagrama de clases. A menudo me ayuda a identificar y componentes que puedo reutilizar a lo largo de la aplicación de software, donde puedo usar un determinado patrón de diseño, etc.
Algunos libros que puedo recomendar: Software Architecture in Practice, que es un muy buen libro sobre arquitectura de software, y Design Patterns de Gang of Four, que es una gran referencia para cualquier patrón de diseño que pueda utilizar.
No creo que hay alguna sustituto para la experiencia y el talento, y nunca he leído un libro en el diseño de software que podría recomendar desde el punto de vista de la enseñanza diseño, a pesar de haber leído un buen número . Algunas personas son buenas y mejoran a medida que adquieren experiencia, y otras no y nunca parecen aprender. Triste pero cierto.
Creo que al mirar el diseño de algunos grandes proyectos de código abierto disponibles. Leer el Código y buscar el diseño de proyectos de código abierto es la mejor manera de aprender a diseñar en mi opinión.
En lugar de decir "prueba y error", digamos "iteración".
Independientemente de lo que esté diseñando, simplemente dele la mejor oportunidad con la información que posee, sabiendo que no tiene un conocimiento completo. Entonces, sin duda, se encontrará con un problema imprevisto que complica las cosas. Aquí es cuando tienes que preguntarte qué salió mal y qué hacer de manera diferente. Luego regrese y rediseñe/reimplemente con su nuevo entendimiento. Repetir. Siempre adivine su diseño y mire a su alrededor para encontrar mejores soluciones. Por ejemplo, "¿Cómo implementa Firefox? Oh, ya veo, no usan ventanas emergentes, y es mucho más limpio".
Al aceptar el hecho de que cometerá errores y está dispuesto a arreglarlos, ya está muy por delante del resto.
A medida que adquiere experiencia, sus iteraciones serán más largas, y de vez en cuando obtendrá las cosas correctas la primera vez, sin duda porque puede prever errores y su solución del pasado.
En lo que respecta a los libros, si mal no recuerdo, "Inside Steve's Brain" habló sobre cómo la iteración es intrínseca al desarrollo de Apple.
Estoy de acuerdo con la mayoría de las sugerencias hasta ahora, todas son válidas - leer código, leer libros, probar cosas.
Donde he visto las mayores ganancias, tanto en lo personal como en los miembros del equipo es un doble ataque: 1. Sacarlos de su zona de confort, es decir, un dominio o idioma desconocido, quitarle las muletas. 2. Y, probablemente lo más importante, emparejalos con alguien que ya tenga experiencia.
Mentoring tiene mucho que ofrecer, puede hacerlo usted mismo, pero un buen mentor puede salvarlo años de dolor.
Sin duda, la experiencia es la respuesta correcta. Pero más allá de eso, creo que hay algo que decir para comprender los patrones en su propio contexto: a medida que construye sus aplicaciones, tome decisiones de diseño que tengan un sentido pragmático para usted. A saber, no los hagas porque es la "mejor práctica", o porque un programador más experimentado te lo dijo. Hazlos porque tú entiendes el Por qué y te ayuda a ti (u otros programadores) a trabajar con el código y entenderlo mejor. Encuentro que lo mismo es cierto con cosas como el diseño de bases de datos. Haga lo que tiene sentido desde un punto de vista intuitivo de mantenimiento. 7 veces de cada 8, si realmente lo has pensado bien (o has aprendido de varias trampas), descubrirás que estás haciendo automáticamente una clase de "patrón" o práctica sin intentarlo activamente.
Por supuesto, no estoy sugiriendo que nadie trabaje en el vacío; ni que no persigan activamente e integren patrones de diseño como una cuestión de rutina. Simplemente creo que entenderlos en su propio contexto (y por razones prácticas específicas) es lo que más ayuda a desmitificar la cosa. Esa ha sido mi experiencia, de todos modos. La lectura de libros siempre me parece una tarea de aprendizaje. Buenas cosas útiles, pero pequeñas patatas al lado de meterse en la basura. Piensa tus decisiones y sé capaz de defenderlas. Siempre esté abierto a una mejor manera.
Yo diría que prueba y error sería la peor técnica para mejorar sus diseños. A menudo, pasar algunos días pensando sin teclear ahorra mucho esfuerzo más adelante y produce un diseño mucho mejor que será decisivo para el éxito del proyecto. – piotr
No estoy de acuerdo. Creo que Rob significa aprender de tus errores del pasado. Como también mencioné en mi publicación, no creo que pueda, con poca o poca experiencia, buscar un libro, leer algunas cosas sobre el diseño de software y luego encontrar algo excelente, especialmente si el software es bastante complejo. .Realmente tiene que experimentar por sí mismo lo que funciona y lo que no, y no cometer el mismo error dos veces. Eso no quiere decir, por supuesto, que pasar algunos días pensando no ayuda a su diseño, pero eso no es todo. – Razzie
Sí, no me refiero a hackear y diseñar esperanza, estoy hablando de implementar su diseño y ver qué funcionó desde su original y qué no. Entonces, como Razzie me aclaro, me refiero a aprender de los errores frente a la experiencia. –