¿Cómo se empieza a diseñar un sistema grande?[cerrado]

Question

Me han 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é alguna orientación, pero me gustaría poder dejarlos boquiabiertos.¿Qué puedo hacer mientras tanto para prepararme y qué debo tener en cuenta cuando me siento frente a mi computadora con las especificaciones?

Un par de cosas a tener en cuenta:Soy un estudiante universitario en mi primer trabajo real de programación.Usaré Java.Ya tenemos SCM configurado con pruebas automatizadas, etc., por lo que las herramientas no son un problema.

Answer 1

¿Sabes mucho sobre programación orientada a objetos?Si es así, consulte Spring e Hibernate para mantener su implementación limpia y ortogonal.Si entiende eso, debería encontrar que TDD es una buena manera de mantener su diseño compacto y ágil, especialmente porque tiene "pruebas automatizadas" en funcionamiento.

ACTUALIZAR:Al observar la primera serie de respuestas, no podría estar más en desacuerdo.Particularmente en el espacio Java, debería encontrar muchos mentores/recursos para desarrollar su aplicación con Objetos. no es un enfoque centrado en la base de datos.El diseño de bases 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, es decir, Alt.Net).Si mantiene el enfoque en lo que necesita entregar a un cliente y deja que su ORM descubra cómo conservar sus objetos, su diseño debería ser mejor.

Answer 2

Esto se parece mucho a mi primer trabajo.Nada más salir de la universidad, me pidieron que diseñara la base de datos y la capa de lógica empresarial, mientras que otras personas se encargarían de la interfaz de usuario.Mientras tanto, el jefe miraba por encima de mi hombro, sin querer soltar lo que solía ser su bebé y ahora era mío, y metiendo el dedo en él.Tres años después, 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 tu primer trabajo, voluntad comete errores y tu voluntad Necesitas 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 a nivel de base de datos como en la API que presentaba a otros desarrolladores.Al final, todo fue demasiado complicado para soportarlo de una vez y simplemente murió.

Entonces mi consejo:

1. Si no está seguro de asumir un trabajo tan importante sin ayuda de nadie, no lo haga.Dígaselo a sus empleadores y pídales que busquen o contraten a alguien con quien trabajar y que pueda ayudarlo.Si es necesario agregar personas al proyecto, entonces debe hacerse cerca del inicio y no después de que las cosas empiecen a salir mal.

2. Piense muy detenidamente para qué sirve el producto y, reduciéndolo al lo más simple conjunto de requisitos que se te ocurran.Si las personas que le brindan las especificaciones no son técnicas, intente ver más allá de lo que escribieron y vea lo que realmente funcionará y generará dinero.Hable con clientes y vendedores y comprenda el mercado.

3. No es ninguna vergüenza admitir que estás equivocado.Si resulta que es necesario reescribir todo el sistema porque cometiste algún error en tu primera versión, entonces es mejor admitirlo lo antes posible para poder solucionarlo.En consecuencia, no intente crear una arquitectura que pueda anticipar todas las contingencias posibles en su primera versión, porque no sabe cuáles son cada contingencia y simplemente se equivocará.Escribe una vez con miras a tirarlo y empezar de nuevo; puede que no sea necesario, la primera versión puede estar bien, pero admítelo si es así.

Answer 3

Tampoco estoy de acuerdo con comenzar con la base de datos.La base de datos es simplemente un artefacto de cómo se conservan sus objetos comerciales.No conozco un equivalente en Java, pero .Net tiene herramientas estelares como Subsónico que permiten que el diseño de su base de datos se mantenga fluido a medida que itera a través del diseño de sus objetos comerciales.Yo diría que, ante todo (incluso antes de decidir qué tecnologías introducir), céntrate en el proceso e identifica tus sustantivos y verbos...luego construye a partir de esas abstracciones.Oye, realmente funciona en el "mundo real", ¡tal como te enseñó OOP 101!

Answer 4

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

Answer 5

Lo principal es ser capaz de abstraer la complejidad del sistema para que no te quedes estancado nada más empezar.

• Primero lea la especificación como una historia (hojeándola por encima).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.Empiece a anotarlos (use una herramienta de mapas mentales si lo desea).

• Luego tome cada componente y comience a explotarlo (y a vincular 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 empezar a observar las relaciones entre los componentes y si hay repeticiones de características o funciones en los distintos componentes (que luego puede extraer para crear componentes de utilidad, o algo así).A estas alturas, tendrá en mente un buen mapa detallado de sus necesidades.

• AHORA, debería pensar en diseñar la base de datos, los diagramas ER, el diseño de clases, los DFD, la implementación, etc.

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

Answer 6

Yo lo hago al revés.Encuentro que hacerlo primero con el esquema de la base de datos hace que el sistema se atasque en un diseño basado en datos que es difícil de abstraer de la persistencia.Primero intentamos hacer diseños de modelos de dominio. y luego basar el esquema de la base de datos en ellos.

Y luego está el diseño de la infraestructura:En primer lugar, el equipo debe establecer 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.).Este se convierte en el marco del sistema.

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

Answer 7

Según mi experiencia, es muy probable que las aplicaciones Java (también .NET) que consideran la base de datos en último lugar tengan un rendimiento deficiente 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 manera, la infraestructura que está implementando es importante al considerar cómo maneja sus datos.

No importa qué metodología considere, cómo obtiene y guarda sus datos y su impacto en el rendimiento debe ser una de sus prioridades número uno.

Answer 8

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

Dibújalo en papel normal, pensando en dónde dividir el código.Recuerde no mezclar lógica con código GUI (error común).De esta manera estará preparado para ampliar 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 puedas responder a grandes cambios más rápido sin tener que reconstruir todo.Las capas no deberían ver ninguna otra capa que no sean sus capas vecinas más cercanas.

Comience con la verdadera funcionalidad central.Toda esa tontería que consume mucho tiempo (que hará que su proyecto se retrase 4 semanas) no le importará mucho a la mayoría de los usuarios.Se puede agregar más tarde una vez que esté seguro de poder realizar la entrega a tiempo.

Por cierto.Aunque esto no tiene nada que ver con el diseño, solo me gustaría decir que no entregarás 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.Es posible que necesite capacitar a las personas a mitad del proyecto, que la gente se vaya de vacaciones o necesite cirugía, etc.

Answer 9

Divida el sistema grande en partes más pequeñas.Y no penséis que es tan complejo, porque normalmente no lo es.Pensar demasiado complejo simplemente arruina tus pensamientos y eventualmente el diseño.En algún momento 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 al diseñar.

¡Mantenlo simple!

Answer 10

Encontré ideas muy interesantes sobre cómo iniciar un nuevo gran proyecto, basado en

• buenas practicas comunes
• Desarrollo basado en pruebas
• y enfoque pragmático

en el libro Creciente software orientado a objetos, guiado por pruebas.

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