salary - architecture software

Diseño de software/problemas de arquitectura (6)

Codifiqué por un tiempo y aprendí varios lenguajes de programación. Programé muchas pequeñas herramientas y cosas así. Creo que domino el hecho de codificar bastante bien, por lo que, por ejemplo, no tengo problemas con la sintaxis, tengo una buena comprensión de lo que sucede debajo del capó (conocimiento razonable del ensamblador), etc.

Mi gran problema es que no puedo diseñar aplicaciones más grandes / complejas. Aprendí los principios de la programación orientada a objetos, los patrones de diseño, aprendí un poco de programación básica y todo lo que pude encontrar y pensé que me ayudaría con mi problema.

Pero no importa lo que intente, cuánto tiempo lo intente: simplemente no puedo hacerlo bien. Mis diseños siempre me parecen mal de alguna manera. Debido a eso, nunca hice un proyecto más grande, nunca estoy satisfecho con la estructura de mi programa.

¿Has tenido un problema similar? ¿Cómo te las arreglaste para resolverlo? ¿Tienes algún consejo para mí sobre cómo seguir?

Creo que la experiencia es un factor clave aquí. Cada diseño falla en algún punto, entonces depende de usted mejorarlo y aprender de sus errores.

En mi opinión, un buen diseño de software no es algo que se pueda aprender leyendo algunos libros.

El diseño en sí es una actividad iterativa. Primero comienza con un determinado diseño y luego, en fases, lo mejora.

El diseño no se trata de lograr la perfección, que ni siquiera se puede lograr en aplicaciones más grandes. El diseño tiene que ver con hacer buenos balances y compensaciones que al final proporcionen una aplicación buena, robusta y mantenible, que cumpla con los requisitos.

Nunca lo conseguirás al 100% en todos los lados.

Leer algunos buenos libros sobre diseño / arquitectura no te convertirá directamente en una estrella de rock en el tema, pero sin duda te dará las herramientas que puedes utilizar para mejorar y perfeccionar tus habilidades.

Aquí hay algunos ejemplos de libros:

Por supuesto que la experiencia práctica también cuenta.

En primer lugar, observe el principio de Uncle Bob Martins: cada patrón de diseño cubre algunos de estos principios. Preste atención al Principio Abierto Abierto, siempre fallamos en esto, pero al aumentar la experiencia es más fácil hacerlo.

Creo que tratar de resolver y luego refactorizar es un buen enfoque, también ayuda a que el problema sea más sensible, tenga una solución y nos libere del estrés de cómo resolverlo.

Intente hacerlo paso a paso, no intente diseñarlo todo de una vez.

Define los requisitos de su aplicación.
Piense en los objetos que necesitará, intente que cada objeto sea lo más simple y específico posible, no haga grandes objetos con muchas funciones diferentes.
Piensa en las relaciones entre tus objetos.

Prueba y error te llevarán hasta allí. Después de algunos proyectos, tendrá la experiencia suficiente para hacerlo bien la primera vez (aunque para muchos proyectos no hay un diseño "correcto").

Recuerde que hacer que su diseño sea lo más simple posible, usar un diseño complicado para resolver un problema simple no es algo bueno.

Para agregar un poco más de sabiduría del calendario: "No se repita" y "Mantenga las dependencias al mínimo". Sin embargo, esos dos a menudo compiten.

design bigger/more complex applications

Cuando dice diseñar aplicaciones más grandes / más complejas , supongo que lo que tiene en mente es lo que generalmente se denomina "aplicaciones de escala empresarial". Puede consultar esta pregunta que habla sobre varios criterios que ayudan a tratar y objetivar qué es lo que hace que una aplicación sea una aplicación de escala empresarial.

Hablando de estas preocupaciones,

Las aplicaciones pequeñas no necesariamente tienen muchas de estas preocupaciones aplicables a ellas.
Incluso con las aplicaciones empresariales, con un conjunto tan amplio de inquietudes que deben abordarse, lo que diferencia el diseño es lo que a las inquietudes se les da más importancia. Además, en caso de problemas conflictivos, cuál se elige sobre el otro.

Al diseñar para su aplicación, si intenta tener en cuenta estas preocupaciones y toma decisiones de diseño basadas en estas preocupaciones, entonces esa será una forma de intentar avanzar en la dirección correcta. SIN EMBARGO , esto es más fácil decirlo que hacerlo. Aunque aparentemente es una lista de aspecto simple, hacer un diseño correcto es algo que los arquitectos experimentados pierden el sueño / el pelo / la vida y generalmente es difícil de encontrar, especialmente para un principiante.

Algunas de estas decisiones son cosas que se aprenden solo de la experiencia. En mi experiencia personal, lo que me ayudó mucho fue trabajar con y bajo la supervisión de arquitectos experimentados. Poder aprender y obtener el beneficio de su conocimiento y experiencia te enseña cosas que ningún libro / blog puede.

But no matter what i try, how long i try: i just can''t get it right. My designs always seem wrong to me somehow.

Hablando con franqueza, eres totalmente la persona equivocada para juzgar. ¿Cómo sabes realmente que tu diseño está mal? La única manera real de decir que el diseño es incorrecto es si su aplicación no hace lo que se supone que debe hacer.

Si desea tener alguna validación de su diseño, le sugiero que pregunte a alguien que haya trabajado en proyectos de tamaño similar que tenga en mente y pídales que miren su diseño y lo revisen, desde su perspectiva. Eso realmente le dará una buena idea de dónde se encuentra realmente su diseño.

Cause of that i never drawn through a bigger project, i''m kinda never satisfied with the structure of my program.

Desafortunadamente, algunas de las complejidades reales en el diseño de una aplicación empresarial resultan de una variedad de cosas que simplemente no se pueden simular de otra manera. Algunos de ellos pueden ser restricciones organizativas, por ejemplo, el CTO de mi cliente no utiliza el uso de la tecnología X), y otros, como necesitamos para integrar nuestra aplicación con la aplicación MS Access de uso doméstico que está utilizando uno de nuestros proveedores. Tales complicaciones para la aplicación y su diseño es algo que tiene que experimentar y por lo general hay mucho que aprender de ella.

Para obtener dicha experiencia, tienes que trabajar en lugares que ofrezcan este tipo de oportunidad. Por lo general, lo que he visto es que cuanto más grande es la empresa, más complicado es su entorno de TI y eso da la mayor oportunidad para que surjan escenarios complejos.