Actualmente estoy trabajando en un proyecto que está a punto de llegar a más de 5,000 líneas de código, pero nunca pensé completamente en el diseño. ¿Qué métodos debo usar para estructurar y organizar mi código? ¿Papel y bolígrafo? Diagramas UML? ¿Algo más?
architecture
uml
Ryan
fuente
fuente
Respuestas:
Probablemente obtenga tantas vistas diferentes como habrá respuestas. Pero aquí está mi perspectiva.
Para empezar, más de 5000 líneas de código es un proyecto muy muy pequeño. Ahora, ¿cómo haces para diseñar proyectos que crecen? En primer lugar, diseñas tu sistema y no un código. El código es realmente secundario a la arquitectura. Comience apoyando los requisitos mínimos actuales. Ponga un dibujo simplista de los componentes involucrados. Personalmente me gusta UML, pero cualquier cosa visual será buena. Idealmente, desea adherirse a las buenas prácticas de diseño aquí (interfaces, separación de preocupaciones, etc.).
Una vez que admita requisitos mínimos en su diseño, codifíquelo. Nuevamente, intente adherirse a las buenas prácticas de codificación.
Después de eso, agregue iterativamente más funcionalidad a medida que surjan nuevos requisitos. Idealmente, también desea actualizar su diseño.
Lo importante, según mi experiencia, es no diseñar su sistema en anticipación de requisitos no existentes. De lo contrario, su proyecto crecerá muy rápidamente y se volverá muy complejo en poco tiempo. Nuevamente, adhiérase a las buenas prácticas y comience con los requisitos actuales concretos.
fuente
Diagrama de flujo, Diagrama de clase, Diagrama de casos de uso son los diagramas imprescindibles para grandes proyectos. Busque y seleccione las bibliotecas externas que necesita y busque los códigos de código abierto similares que pueda usar (para aprender y reducir el tiempo de desarrollo).
Le sugiero que compre una pizarra y algunos imanes coloridos y post-it. Le ayudará a identificar sus tareas.
Sin embargo, las líneas de códigos ps 5000+ no son "grandes". Un software CMS / Forum tiene más de 5000 líneas de códigos.
fuente
Crearía diagramas de paquetes y clases. En el diagrama del paquete me interesaría agrupar clases e interfaces de manera lógica. También me gustaría crear paquetes internos, etc.
Pero primero debe pensar qué debe hacer el programa. Puede crear diagramas de casos de uso o hacerlo manualmente. Lo hago manualmente con el diagrama de clases porque prefiero obtener el código de inmediato y es más fácil cambiar a diagramas de clases de paquetes más tarde. Usar el diagrama de clase me da mi java. Si no me gusta, entonces lo cambio manualmente. El nuevo código se actualiza automáticamente en mis diagramas. Tengo una representación visual actualizada de alto nivel de mi código. Realmente útil porque incluso si codifico, siempre puedo tomar unos minutos para ver la forma en que mi proyecto se desarrolla de manera gráfica. Simplemente arrastre y suelte entidades en el paquete correcto manualmente para organizarlo. Creo que mi código es mejor usando paquetes de mayor nivel de abstracción y diagramas de clases.
(fuente: ejb3.org )
Algunos de mis colegas dijeron que mi forma de trabajar es una mierda ... pero me gusta :-)
fuente
Seguro. Tengo un pequeño tablero de borrado en seco de "tableta" para usar para este tipo de cosas, pero use lo que le resulte más cómodo. Lo importante es que puedes expresar tus pensamientos fácilmente y ver el panorama general de cómo todo encaja.
Algunas personas prefieren planes más formales, como los diagramas UML, pero creo que es demasiado fácil quedar atrapado en la microgestión de cómo debería ser cada método. Sin embargo, una vez más, usa lo que te resulte cómodo.
EDITAR: También te puede interesar la programación alfabetizada . La idea es que puede planificar todo y gradualmente ser más específico. Por ejemplo, podría decir que su programa consiste en:
Luego, puede refinar su idea de convertir el texto en una imagen. Entonces eso podría verse así:
Entonces puede refinar la idea de elegir colores aleatorios, y pronto solo está escribiendo un código regular.
fuente
Para mí, la actividad de desarrollo de software es una serie de diseños progresivamente más precisos para resolver un problema particular. Cuando solo tiene una idea de alto nivel de lo que está construyendo, su diseño puede ser algo de alto nivel, como "habrá una aplicación web que se comunique con una base de datos SQL y múltiples servicios web" o algo así. Luego, a medida que profundiza en los detalles de cada pieza, obtiene un diseño más fino. Dependiendo de la complejidad de la solución, habrá más o menos iteraciones del esfuerzo de diseño. La iteración final implica crear el código real que implementa los niveles más altos del diseño.
Para mí, la diferencia entre arquitectura y diseño es mínima, y son solo iteraciones diferentes del proceso que describo anteriormente. La línea entre los dos es difusa y diferente para diferentes personas.
Hay un arte en decidir en qué nivel de detalle de diseño entrar, para qué partes de la aplicación y en qué puntos del ciclo de vida del proyecto. Para proyectos de alto riesgo y alta complejidad, es posible que desee tener un diseño muy detallado antes de escribir una línea de código. Para proyectos más pequeños, puede salirse con la suya haciendo muy poco diseño inicial y simplemente eliminando algo de código y luego viendo lo que no funciona y rediseñando esas áreas. No hay una sola respuesta de escritura aquí. Por lo general, está en algún lugar entre esos dos extremos.
Tengo una publicación de blog que habla sobre algunos de los principios que uso cuando me acerco a la arquitectura. Puede ser útil para usted pensar en este sentido. Parte del artículo es específico de .NET, pero la mayoría no lo es.
fuente
Solía hacerme la misma pregunta. Ahora solo practico el desarrollo basado en pruebas, y no me preocupo por eso. No "planifico" el código en absoluto, excepto para seguir los estándares de la arquitectura elegida. Cuando comienzo un proyecto, tengo una idea de lo que se necesitará, pero a medida que avanza el desarrollo trato de mantener una mente abierta. Siguiendo el desarrollo basado en pruebas y refactorizando continuamente el código, no tengo que "planear" el código. Simplemente satisfago un caso de prueba tras otro, y el diseño surge de la refactorización. Este es siempre un mejor diseño que cualquier plan que podría haber hecho antes de la codificación.
fuente