Puedo escribir código ... pero no puedo diseñar bien. ¿Alguna sugerencia? [cerrado]

La única manera de llegar a ser realmente bueno en algo es intentar, fallar espectacularmente, volver a intentarlo, fallar nuevamente un poco menos que antes, y desarrollar con el tiempo la experiencia para reconocer las causas de sus fallas para que pueda manejar posibles situaciones de fallas. mas tarde. Esto es tan cierto como aprender a tocar un instrumento musical, conducir un automóvil o ganar un poco de edad PWN en su juego de disparos en primera persona favorito, como lo es aprender cualquier aspecto del desarrollo de software.

No hay atajos reales, pero hay cosas que puede hacer para evitar que los problemas se salgan de control mientras adquiere experiencia.

• Identifique un buen mentor . No hay nada mejor que poder hablar sobre sus problemas con alguien que ya ha pagado sus cuotas. La orientación es una excelente manera de ayudar a acelerar el aprendizaje.
• Lea , lea un poco más, practique lo que ha estado leyendo y repita durante toda la vida de su carrera. He estado haciendo estas cosas por más de 20 años, y todavía me encanta aprender algo nuevo cada día. Conozca no solo el diseño inicial, sino también el diseño emergente, las pruebas, las mejores prácticas, los procesos y las metodologías. Todos tienen diferentes grados de impacto en la forma en que surgirán sus diseños, tomarán forma y, lo que es más importante, cómo durarán con el tiempo.
• Encuentre tiempo para tinker . Involúcrate con un proyecto skunkwork en tu lugar de trabajo, o practica en tu propio tiempo. Esto va de la mano con su lectura, al poner en práctica sus nuevos conocimientos y al ver cómo funcionarán esas cosas. Esto también es lo que hace que sea una buena discusión con su mentor.
• Involúcrate con algo técnico fuera de tu lugar de trabajo. Esto podría ser un proyecto, o un foro. Algo que te permitirá probar tus teorías e ideas fuera de tu círculo inmediato de compañeros para mantener una nueva perspectiva de las cosas.
• Sé paciente . Reconozca que ganar experiencia lleva tiempo, y aprenda a aceptar que necesita retirarse por un tiempo para saber por qué y dónde ha fallado.
• Mantenga un diario o un blog de sus tareas, sus pensamientos, sus fracasos y sus éxitos. Esto no es estrictamente necesario, sin embargo, he descubierto que puede ser de gran beneficio para usted ver cómo se ha desarrollado con el tiempo, cómo han crecido sus habilidades y han cambiado sus pensamientos. Vuelvo a mis propios diarios cada pocos meses y veo las cosas que escribí hace 4-5 años. Es una verdadera revelación descubrir cuánto había aprendido en ese tiempo. También es un recordatorio de que me equivoqué de vez en cuando. Es un recordatorio saludable que me ayuda a mejorar.

Bueno, no hay una manzana dorada para este tipo de pregunta, y creo que esto es para que todos los programadores encuentren lo que es correcto para él. Aquí está mi opinión, de todos modos.

Usted podría leer libros sobre el tema. Grandes libros Libros fantasticos Pero me parece que estos libros solo te ayudan una vez que has intentado crear y diseñar una aplicación, y has fallado.

Para mí, todo se trata de la experiencia. Cuando comencé como novato leía libros sobre cómo diseñar. No entendí mucho del contenido en ese entonces. Cuando empecé a trabajar y tuve que diseñar aplicaciones yo mismo, hice aplicaciones muy desordenadas. Trabajaron, pero eran un dolor para mantener. Luego volví a leer esos libros, y esta vez los entendí mejor.

Ahora, continúo cometiendo nuevos errores y aprendiendo de los viejos.

Deja de diseñar y aprende a refactorizar el código. El desarrollo incremental con refactorización continua y agresiva dará como resultado un producto final mucho más limpio que cualquier diseño inicial.

Lea sobre patrones, por supuesto, pero ante todo lea sobre antitramas. Reconocer los anti-patrones es importante, y es más fácil entender por qué algo no debe hacerse de una manera que no debería hacerlo.

Vea enlace por ejemplo.

Escriba el código para que pueda ajustarse rápidamente si los requisitos cambian (lo cual es muy común en el entorno de producción).

Sea súper escéptico acerca de agregar "solo un pequeño truco más". Uno más aquí, uno más allí, y el código se vuelve inconfundible.

Valor el principio de apertura / cierre .

Escribir pruebas (como en TDD). Lo obligan a pensar en su diseño incluso antes de implementarlo.

Busque el código de los proyectos de código abierto (es decir, de tamaño razonable). Solía sorprenderme, por lo general, ver tantos niveles de abstracción. Ahora entiendo que no es arte por arte, hay una razón por la que se hace de esta manera.

Un principio que considero muy importante para un buen diseño es la descomposición: si una clase es demasiado grande (más de, por ejemplo, 300-400 líneas de código), divídala en clases más pequeñas; si un método es demasiado grande (digamos, más de 50 líneas de código) descomponerlo; si un proyecto contiene más de 50 clases, descomponerlo.

La clave es estimar el tamaño de su sistema y construir varias capas de abstracción (por ejemplo, subsistema, aplicación, proyecto, módulo, clase, método) que le permitan descomponer su código en unidades comprensibles con relaciones claras entre ellas y pocas dependencias .

Es difícil, de lo que realmente estamos hablando es de la capacidad de abstraer en lugar de crear un mejor código, pero dos cosas te harán mejor y una cosa te hará más feliz:

"Mejor"

A) Encuentre el mejor diseñador que pueda y empareje el programa / haga un diseño juntos. Pídales que expliquen lo que están pensando mientras abordan el problema, no se conformen con "simplemente se siente bien" y continúen investigando. Ese proceso también ayudará a la parte "mentora"

B) Imagina todo como actores individuales y conversaciones entre ellos. Cada uno de los actores debe tener un solo rol / responsabilidad y grupos de ellos manejan diferentes sistemas. Si esa conversación funciona y cada actor se siente coherente y cohesionado, entonces usted está en camino.

Y "más feliz"

C) Si has hecho tu mejor esfuerzo y aún no está sucediendo, no hay nada de malo en aceptar que algunas personas no puedan hacer algunas cosas. Podrías escribir código apretado y brillante, pero nunca ser capaz de diseñar o diseñar. ¿Y qué? No puedo practicar deportes físicos para el toffee, no tengo buena apariencia y mi auto nunca será mejor que el promedio. Disfruta y utiliza aquello en lo que eres bueno.

En mi experiencia personal, leer el código de otros es una buena fuente de "inspiración". Me refiero a tratar de entender los diseños de otras personas y preguntarse por qué él / ella hace las cosas de esa manera.

puedes encontrar una gran cantidad de proyectos de código abierto para investigación.

de todos modos necesitas práctica.

No vivas con miedo

Luchar por la simplicidad

Escucha a tus usuarios

Prueba muchas ideas

Crea algo, luego hazlo mejor

Trabaja en cosas que agregan valor, abandona cosas que no lo hacen

Aprende a hacer las preguntas correctas. La mayoría de las veces mejorará su diseño al observar el problema desde un ángulo diferente. En particular, esto le ayudará a dejar de centrarse en resolver el problema en cuestión y buscar más soluciones que resuelvan múltiples problemas relacionados.