¿Cómo comienzas a diseñar un sistema grande?

Question

Se me ha mencionado que seré el único desarrollador detrás de un gran sistema nuevo. Entre otras cosas, diseñaré una interfaz de usuario y un esquema de base de datos.

Estoy seguro de que recibiré algunas indicaciones, pero me gustaría poder quitarles los calcetines. ¿Qué puedo hacer mientras tanto para prepararme, y qué tendré que tener en cuenta cuando me siento en mi computadora con las especificaciones?

Algunas cosas a tener en cuenta: Soy un estudiante universitario en mi primer trabajo real de programación. Estaré usando Java. Ya tenemos SCM configurado con pruebas automatizadas, etc., así que las herramientas no son un problema.

Answer 1

¿Sabes mucho sobre OOP? Si es así, busque en Spring e Hibernate para mantener su implementación limpia y orthogonal. Si obtienes eso, deberías encontrar a TDD como una buena forma de mantener tu diseño compacto y delgado, especialmente desde que tienes "pruebas automatizadas" en funcionamiento.

ACTUALIZACIÓN: En cuanto a la primera serie de respuestas, no podría estar más en desacuerdo. Particularmente en el espacio de Java, debe encontrar muchos mentores/recursos para desarrollar su aplicación con Objects, , no con un enfoque centrado en la base de datos. El diseño de la base de datos suele ser el primer paso para la gente de Microsoft (lo cual hago a diario, pero estoy en un programa de recuperación, er, Alt.Net). Si mantiene el enfoque en lo que necesita entregar a un cliente y deja que su ORM descubra cómo persistir en sus objetos, su diseño debería ser mejor.

Answer 2

Antes de comenzar a codificar, planifique su esquema de base de datos; todo lo demás se derivará de eso. Obtener la base de datos razonablemente correcta desde el principio le ahorrará tiempo y dolores de cabeza más adelante.

Answer 3

Lo hago al revés. Me parece que hacerlo base de datos-esquema-primero hace que el sistema se atasque en un diseño basado en datos que es difícil de abstraer de la persistencia. Tratamos de hacer diseños de modelos de dominio primero y luego base el esquema de base de datos en aquellos.

Y luego está el diseño de la infraestructura: el equipo debe establecer primero las convenciones sobre cómo estructurar el programa. Y luego trabajamos juntos para acordar primero un diseño para la funcionalidad común del sistema (por ejemplo, cosas que todos necesitan, como persistencia, registro, etc.). Esto se convierte en el marco del sistema.

Todos trabajamos juntos en eso antes de dividir el resto de las funcionalidades entre nosotros.

Answer 4

Lo principal es ser capaz de abstraer la complejidad del sistema para que no se empantane tan pronto como comience.

• Primero lea la especificación como una historia (hojeando). No se detenga en cada requisito para analizarlo allí mismo. Esto le permitirá obtener una imagen general del sistema sin demasiados detalles. En este punto, comenzaría a identificar los principales componentes funcionales del sistema. Comience a poner esto abajo (use una herramienta de mapa mental si lo desea).

• A continuación, tome cada componente y comience a explotarlo (y vincule cada detalle con los requisitos del documento de especificaciones). Haga esto para todos los componentes, hasta que haya cubierto todos los requisitos.

• Ahora, debería comenzar a observar las relaciones entre los componentes, y si hay repeticiones de características o funciones en los diversos componentes (que luego puede extraer para crear componentes de utilidad, o similares).En este momento, tendrías en mente un buen mapa detallado de tus necesidades.

• ahora, usted debe pensar en el diseño de la base de datos, diagramas ER, Clase de diseño, DFD, despliegue, etc.

El problema de hacer el último paso primero es que se puede estancarse en la complejidad de su sistema sin realmente obtener una comprensión general en primer lugar.

Answer 5

También estoy en desacuerdo sobre comenzar con la base de datos. El DB es simplemente un artefacto de cómo persisten sus objetos comerciales. No conozco un equivalente en Java, pero .Net tiene herramientas estelares como SubSonic que permiten que su diseño de base de datos se mantenga fluido a medida que itera a través del diseño de objetos comerciales. Antes que nada, diría (incluso antes de decidir qué tecnologías presentar) centrarse en el proceso e identificar sus nombres y verbos ... luego construir a partir de esas abstracciones. ¡Oye, realmente funciona en el "mundo real", al igual que OOP 101 te enseñó!

Answer 6

Esto suena muy parecido a mi primer trabajo. Al salir de la universidad, me pidieron que diseñara la capa de base de datos y la lógica de negocios, mientras que otras personas se encargarían de la interfaz de usuario. Mientras tanto, el jefe estaba mirando por encima del hombro, no estaba dispuesto a dejar ir lo que solía ser su bebé y ahora era mío, y metiendo su dedo en él. Tres años más tarde, los desarrolladores huían de la empresa y todavía estábamos a X meses de vender algo.

El gran error fue ser demasiado ambicioso. Si este es su primer trabajo, hará cometer errores y tendrá necesidad de cambiar cómo funcionan las cosas mucho después de haberlas escrito. Teníamos todo tipo de características que hacían que el sistema fuera más complicado de lo necesario, tanto en el nivel de la base de datos como en la API que presentaba a otros desarrolladores. Al final, todo fue demasiado complicado para apoyar a todos a la vez y simplemente murió.

Así que mi consejo:

1. Si no está seguro acerca de tomar en un trabajo tan grande con una sola mano, no lo hacen. Dígale a sus empleadores, y haga que busquen o contraten a alguien para que trabaje con quien pueda ayudarlo. Si las personas necesitan ser agregadas al proyecto, entonces debe hacerse cerca del inicio en lugar de después de que algo empiece a ir mal.

2. Piense cuidadosamente sobre para qué es el producto, y para reducirlo al , el conjunto más simple de que pueda imaginar. Si las personas que le dan las especificaciones no son técnicas, intente ver más allá de lo que han escrito para saber qué funcionará realmente y para ganar dinero. Hable con clientes y vendedores, y comprenda el mercado.

3. No es ninguna pena admitir que estás equivocado. Si resulta que todo el sistema necesita ser reescrito, porque cometió un error en su primera versión, entonces es mejor admitirlo lo antes posible para poder acceder a él. En consecuencia, no intente hacer una arquitectura que pueda anticipar todas las contingencias posibles en su primera versión, porque no sabe qué es cada contingencia y se equivocará. Escribe una vez con un ojo para tirar y comenzar de nuevo - puede que no tengas que hacerlo, la primera versión puede estar bien, pero admítelo si lo haces.

Answer 7

Divida el sistema grande en piezas más pequeñas. Y no creo que sea tan complejo, porque generalmente no lo es. Al pensar demasiado complejo, solo arruina tus pensamientos y, finalmente, el diseño.Algún punto te das cuenta de que podrías hacer lo mismo más fácilmente, y luego lo rediseñas.

Al menos este ha sido mi mayor error en el diseño.

¡Mantenlo simple!

Answer 8

Ha sido mi experiencia que las aplicaciones Java (.NET también) que consideran que la base de datos es la última vez es muy probable que tengan un bajo rendimiento cuando se colocan en un entorno corporativo. Necesitas pensar realmente en tu audiencia. No dijiste si era una aplicación web o no. De cualquier forma, la infraestructura en la que está implementando es importante al considerar cómo maneja sus datos.

Independientemente de la metodología que considere, cómo obtiene y guarda sus datos y su impacto en el rendimiento debería ser una de sus prioridades n. ° 1.

Answer 9

me encontré con ideas muy interesantes acerca de cómo iniciar un nuevo proyecto grande, basado en

• buenas prácticas comunes
• desarrollo basado en pruebas
• y aproximación pragmática

en el libro Growing Object-Oriented Software, Guided by Tests.

Todavía está en desarrollo, pero los primeros 3 capítulos pueden ser lo que está buscando y en mi humilde opinión vale la pena leer.

Answer 10

Sugiero pensar en cómo se usará esta aplicación. ¿Cómo trabajarán los futuros usuarios con él? Estoy seguro de que conoce al menos algunas cosas sobre lo que esta aplicación debe manejar, pero mi primer consejo es "pensar en el usuario y lo que necesita".

Dispóngalo en papel normal, pensando en dónde seccionar el código. Recuerde no mezclar la lógica con el código GUI (error común). De esta forma, estará listo para extender el alcance de sus aplicaciones en el futuro a servlets y/o applets o cualquier plataforma que se presente. Sección en capas para que pueda responder a grandes cambios más rápido sin reconstruir todo. Las capas no deberían ver ninguna otra capa más que sus capas vecinas más cercanas.

Comience con verdadera función central. Todo ese tiempo de consumo de pelusa (que hará que su proyecto llegue 4 semanas tarde), no importará mucho a la mayoría de los usuarios. Se puede agregar más tarde una vez que esté seguro de que puede entregar a tiempo.

Btw. Aunque esto no tiene nada que ver con el diseño, me gustaría decir que no entregará a tiempo. Haga una estimación realista del consumo de tiempo y luego duplíquelo :-) Supongo que no estará solo en este proyecto y que la gente irá y vendrá a medida que avance el proyecto. Puede que necesite capacitar a personas a mitad del proyecto, la gente se va de vacaciones/necesita cirugía, etc.