Si estoy a punto de desarrollar una aplicación Enterprise, pero por lo que sé del proceso ágil, divido las características en pequeños fragmentos y las desarrollo de forma iterativa. Solía crear primero la base de datos y el núcleo de la aplicación, luego los extendía de forma iterativa.
La pregunta es: ¿Tengo que mantener lo que solía hacer anteriormente (desarrollar el núcleo primero) o debo distribuir el desarrollo central sobre el desarrollo de las historias? ¡Más adelante, no estoy seguro de que el código sea lo suficientemente flexible para futuras extensiones!
¿Alguna idea?
architecture
agile
object-oriented-design
Sameh Deabes
fuente
fuente
Respuestas:
No desarrolles el núcleo primero . Un principio clave del desarrollo ágil es escribir el código mínimo necesario para las funciones completadas. De esa manera puede entregar en cualquier momento. El código se mantiene flexible porque refactoriza continuamente para eliminar la duplicación. La refactorización es compatible con las pruebas automatizadas que escribió para cada característica a medida que la construyó. El núcleo crece automáticamente a medida que elimina la duplicación del código de nivel superior.
Básicamente, en lugar de generar flexibilidad en un intento generalmente inútil de minimizar los costosos cambios futuros en el código, Agile crea pruebas automatizadas para admitir la refactorización, de modo que los cambios en el código sean relativamente económicos.
Refactorización de Martin Fowler es mi libro favorito sobre técnicas efectivas de refactorización. Es mucho más fácil factorizar un núcleo utilizable que definir uno desde el principio. Definir un núcleo utilizable antes de la implementación de características es casi imposible, a menos que simplemente esté reimplementando una API existente. Y no hay valor en eso.
fuente
Mi enfoque para el desarrollo ágil es construir "cortes verticales". Tomo una historia de la interfaz de usuario para el almacenamiento y la implemento. Tengo algunas herramientas livianas que utilizo para ayudar a este proceso (como un marco IRepository / UnitOfWork simple que tiene adaptadores para In Memory (generalmente para pruebas), Entity Framework y NHibernate. En este momento no creo que haya mucho de un argumento de si uno debe usar un O / RM, sino cuál usar, y para mí depende del entorno.
He descubierto que este enfoque se gana a los detractores con respecto al desarrollo ágil porque pueden ver el software en funcionamiento más rápidamente que si paso mucho tiempo por adelantado creando un núcleo. En combinación con el diseño impulsado por dominio y algunas otras técnicas que utilizo, generalmente puedo obtener mucha funcionalidad de trabajo frente a los usuarios muy rápidamente.
La prueba TDD o incluso la prueba de unidad post-hoc es importante porque parte del mantenimiento de la velocidad a medida que su aplicación crece es tener esa red de seguridad que proporciona un conjunto completo de pruebas unitarias. "Necesito hacer un cambio en esta clase, ¿cómo me aseguro de no romper nada?" Con un buen conjunto de pruebas unitarias, es tan simple como ejecutar ese conjunto de pruebas. Sin esto, se trata de ejecutar manualmente la aplicación para verificarla. No es divertido en absoluto.
fuente
Cree el marco horizontal mínimo que admita una porción vertical de funcionalidad. El marco está diseñado para ser extensible y es donde inicialmente se enfoca la mayor parte del esfuerzo. La parte vertical de la funcionalidad es demostrar que el marco admite un valor real. En las iteraciones posteriores, se dedica menos esfuerzo a medida que se realiza el marco y más para desarrollar capacidades utilizando el marco. Continúe de esta manera hasta que la gran mayoría del esfuerzo se centre en la funcionalidad utilizando el marco que se desarrolló a través de las iteraciones.
fuente