Tendría que decir que sí, ya que el sistema final que estaría produciendo definitivamente tendría algunos defectos (en virtud de que cambia el diseño y el código repetidamente), así como también es difícil de mantener. En mi sugerencia, debe cambiar a una metodología de diseño adecuada como OOAD o quizás diseño estructurado. Me gustaría darle un plano de OOAD.
Análisis y diseño orientado a objetos
Bueno, estás en la dirección correcta tratando de darle al diseño el debido respeto que se merece. Entonces, ¿cómo debe ir sobre Diseño -> Código
- ¿Es útil la certificación de desarrollador certificado por AWS para ingenieros de infraestructura o ingenieros de desarrollo de software? Necesito ayuda para entender esto.
- ¿Qué tan difícil es la transición del desarrollo web a la ingeniería de software?
- ¿Debo ir a terapia ocupacional o informática?
- ¿El mapeo relacional de objetos sigue siendo "el Vietnam" de la informática?
- ¿Qué tan difícil es conseguir un trabajo como ingeniero de software en Silicon Valley? ¿Cómo cambiará esto en 10 años?
La forma en que lo hago, que es de lo que se trata el diseño orientado a objetos, es que primero debe pensar en los casos de uso de su sistema.
- Intente crear un diagrama de casos de uso y encuentre casos de uso que pueda reutilizar (casos de uso interno), esto le ayuda a escribir el sistema con una duplicación mínima de código en diferentes módulos.
- Una vez que tenga casos de uso, debe tratar de pensar en los objetos de negocios y cómo interactúan entre ellos, tratar de crear un boceto muy simple (algo así como un automóvil tiene un conjunto de accesorios, el usuario ve la pantalla principal que muestra una lista de automóviles, etc.), intente hacer un diagrama de colaboración simple y un diagrama de clase (esto se conoce efectivamente como UCRR-R [Informe de realización de caso de uso – Requisito])
- A partir de aquí, pasará a la fase de Análisis (esto puede considerarse opcional) donde, según la arquitectura que vaya a utilizar (supongamos que Modelo-Vista-Controlador), obtendrá objetos de análisis (por ejemplo, objetos de controlador, objetos de interfaz de límite, etc. ), este documento se conoce como UCRR-A .
- Luego, debe decidir su estrategia de transición (supongamos que dice que usaría Java EE, luego su objeto Controlador se convierte en Servlets, los objetos de interfaz de límite se convierten en JSP, los Modelos son EJB o JPA) y luego traducen los objetos de Análisis a Documento de Diseño que contiene diagramas de secuencia [UCRR-D] , solo necesita escribir código simplemente siguiendo el diagrama de secuencia.
- Ahora, si sigue todo este procedimiento, confíe en mí, el código producido es muy robusto y la codificación lleva muy poco tiempo, ya que todo lo que está haciendo es traducir su diagrama de secuencia en código con una estrategia predeterminada (que es un diseño de alto nivel).
- Además, al pasar por un análisis y un diseño tan extensos, casi no le quedan defectos y nunca necesitará volver a la pizarra a menos que haya un cambio en el requisito.
Después de pasar por este ciclo para algunos proyectos, sería lo suficientemente experto como para pasar la fase de análisis y saltar al diseño directamente desde el requisito.
Puede referirse a otra respuesta que di: ¿Es la metodología orientada a objetos o el análisis y diseño orientado a objetos (OOAD) una metodología?
¡¡Espero que esto ayude!!