2010-11-04 13 views
16

código desde hace un tiempo y he aprendido varios lenguajes de programación. Programé muchas herramientas pequeñas y cosas así. Creo que domino el acto de codificarme bastante bien, así que tengo, por ejemplo, sin problemas con la sintaxis, entendí bastante bien lo que está sucediendo debajo del capó (conocimiento razonable del ensamblador), y así sucesivamente.Software de diseño/problemas de arquitectura

Mi gran problema es: simplemente no puedo diseñar aplicaciones más grandes/más complejas. Aprendí los principios de OOP, los patrones de diseño, aprendí algunos programas básicos de lisp y todo lo que pude encontrar y pensé que me ayudaría con mi problema.

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

¿Ha tenido algún problema similar? ¿Cómo te las arreglaste para resolverlo? ¿Tienes alguna pista sobre cómo seguir?

+1

esta es una pregunta típica de programmers.stackexchange.com –

Respuesta

12

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

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

11

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

El diseño no se trata de lograr la perfección, que ni siquiera se puede lograr en una aplicación más grande. El diseño se trata de hacer buenos equilibrios y compensaciones que al final proporcionan una aplicación buena, robusta y fácil de mantener que se ajusta a los requisitos.

Nunca lo obtendrás 100% derecho en todos los lados.

Leer algunos buenos libros sobre diseño/arquitectura no lo convertirán directamente en una estrella de rock en el tema, pero sin duda le proporcionará las herramientas que puede usar para mejorar y perfeccionar sus habilidades.

Éstos son algunos ejemplos de libros:

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

+0

Cualquier sugerencia de buenos libros ¿para empezar? – sorgenkind

2

Trate de seguir paso a paso, no intente diseñarlo todo de una vez.

  1. Defina los requisitos de su aplicación.
  2. Piensa en los objetos que necesitarás, trata de hacer que cada objeto sea lo más simple posible y específico, no hagas objetos grandes con muchas funciones diferentes.
  3. Piensa en las relaciones entre tus objetos.

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

Recuerde 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.

1

Para agregar algo más de sabiduría del calendario: "No repetir" y "Mantener las dependencias al mínimo". Sin embargo, esos dos a menudo compiten.

3

Primer vistazo a Uncle Bob Martins principle cada patrón de diseño cubre algunos de estos principios, Tomar atención a la Abierto Cerrado Principio siempre somos capaces de hacer esto, pero mediante el aumento de la experiencia hace más fácil hacer esto.

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

4
design bigger/more complex applications 

Cuando dice aplicaciones de diseño más grande/más complejas, supongo que lo que tiene en mente es lo que se conoce generalmente como "aplicaciones de escala de la empresa". Puede consultar this question que habla sobre varios criterios que ayudan a probar y objetivar en qué es lo que hace que una aplicación sea una aplicación de escala empresarial.

Hablando de estas preocupaciones,

  1. Pequeñas aplicaciones podrían no necesariamente tiene una gran cantidad de estas preocupaciones que les son aplicables.

  2. Incluso con las aplicaciones empresariales, con un conjunto tan grande de inquietudes que deben abordarse, lo que diferencia al diseño es qué preocupaciones se les da más importancia. Además, en caso de preocupaciones conflictivas, cuál se elige sobre el otro.

Al diseñar para su aplicación, si usted tratar de mantener estas preocupaciones en mente y tomar decisiones de diseño sobre la base de estas preocupaciones, a continuación, que será una manera de tratar de moverse en la dirección correcta. SIN EMBARGO, esto es más fácil decirlo que hacerlo. Aunque parezca una lista simple, conseguir un diseño correcto es algo que los arquitectos experimentados pierden el sueño/el cabello/la vida y suele ser NOTORIAMENTE difícil de conseguir, especialmente para un principiante.

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

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. 

Francamente, estás totalmente a la persona equivocada para juzgar. ¿Cómo sabes realmente que tu diseño es incorrecto? La única manera real de decir que el diseño es incorrecto es si su aplicación no hace lo que se suponía que debía hacer.

Si desea tener alguna validación de su diseño, le sugiero que pregunte a alguien que ha trabajado en proyectos de tamaño similar que tiene en mente y pídales que miren su diseño y lo revisen desde su perspectiva. Eso, realmente te dará una buena idea de dónde está realmente tu 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 enterpise resultado de una variedad de cosas que son simplemente no es posible simular lo contrario. Algunos de ellos pueden ser restricciones organizativas, p. el CTO de mi cliente no utiliza el uso de la tecnología X) para otros, como que necesitamos integrar nuestra aplicación con la aplicación MS Access que uno de nuestros proveedores usa. Esas complicaciones a la aplicación y su diseño es algo que debe experimentar y generalmente hay mucho que aprender de ello.

Para obtener dicha experiencia, debe trabajar en lugares que ofrecen este tipo de oportunidades. 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 que ofrece más oportunidades para que surjan escenarios complejos

Cuestiones relacionadas