¿Qué haces si, mientras desarrollas una aplicación grande y compleja, empiezas a notar que las cosas se vuelven ‘desordenadas’?

Answer 1

El diseño del software es propenso a tal desorden, dado que los requisitos siguen cambiando. El primer paso para mejorar su software es ” aceptar ” que su software no está limpio.

Hecho esto, el siguiente paso sería anotar todas estas cuestiones. Como mencionó Alex Garel, esto se denomina “Deudas técnicas”. Hecho esto, puede priorizar las tareas y realizar la refactorización cuando sea posible.

Una de las principales preocupaciones acerca de la refactorización posterior es el hecho de que las funciones críticas de su software podrían verse afectadas cuando refactoriza su código, y hace más daño que bien. Hay dos formas de manejar estos problemas.

1. Pruebas de regresión ,
2. Adaptar Test Driven enfoque de desarrollo

• El desarrollo guiado por pruebas es una práctica de ingeniería de software, en la que las pruebas correctas de todas las características críticas de su aplicación, antes de escribir la aplicación. Inicialmente, todas sus pruebas fallarían, y luego desarrollará su software para hacer que esas pruebas se aprueben. sigue el enfoque Fail -> Code -> Refactor . De esta forma puede asegurarse de que la refactorización no haya afectado ninguna de las características críticas del software. Una sobrecarga con este enfoque es el esfuerzo inicial para realizar las pruebas unitarias, pero una vez hecho, resulta realmente útil

Answer 2

Esta es una pregunta muy, muy abierta y hay bibliotecas de libros dedicados a responderla. Aquí hay una respuesta muy breve que en su mayoría se reduce a “ir a leer algunos libros”.

Hay un montón de razones diferentes para el “desorden” del software, que ocurren en diferentes niveles del proceso de desarrollo de software. Algunos a nivel de objetivos, prioridades, características, planificación. Algunos a nivel de arquitectura. Algunos a nivel de codificación. Esto es lo que hace que el desarrollo de software sea exigente.

Para obtener respuestas de nivel superior, consulte los libros sobre gestión de proyectos. Existen muchos de ellos, pero la gran mayoría de la gestión de proyectos de software se reduce a estrategias y tácticas para limitar el alcance.

Para arquitectura, consulte libros sobre patrones de diseño y arquitectura de software. Sea tan cauteloso con el cinismo de la rodilla como con la exageración del patrón de diseño.

A nivel de codificación, la “Refactorización” de Fowler es esencial. Refactorizar, al igual que el desarrollo ágil de software, es un término que se ha diluido con el paso de los años. Lea el original.

Una buena analogía para entender la verdadera idea de la refactorización es el “trabajo limpio” del mundo culinario, lo que significa que usted limpia y mantiene su área de trabajo e implementa a medida que avanza. Podría pensar que esto lo haría más lento, pero en realidad lo hace más rápido, porque todo está limpio, preparado y listo para funcionar. En esta analogía, el código en sí es lo que se mantiene limpio. Esta analogía también se puede extender a otros niveles de desarrollo de software, piénselo.

Otra analogía es el control de revisión. Cuando empiezas a usar el control de revisión, las restricciones artificiales que impone, el tiempo y los problemas que toma, pueden parecer un dolor en el culo y una distracción. Pero la sensación de seguridad y seguridad que obtiene de un buen control de revisión le permite desarrollarse mucho más rápido, con la certeza de que todos sus cambios están siendo rastreados y respaldados. Las limitaciones artificiales de la refactorización también llevan a moverse más rápido.

Pero más allá de la refactorización en sí misma, aprender a pensar en términos de refactorización y aprender la sección “Olores de código” del libro, son igual de importantes, quizás más importantes. Los olores de código son como patrones de diseño a nivel táctico. Introducen una capa adicional de abstracción y formalismo, entre métodos / objetos y patrones / arquitectura de diseño.

Puede quedar atrapado en el Código de Olores, lo cual está bien, es bastante denso. Pero intente volver a visitar esa sección cada año o dos. Te recordarán cosas que hayas olvidado. Recogerás cosas que te perdiste la vez anterior. Entenderás cosas que antes no entendías.

En general, pienso en el diseño de software en estas capas. Capas no es el término correcto, porque se superponen y se mezclan entre sí:

algoritmos y estructuras de datos
subrutinas / funciones / métodos / objetos
el código huele
patrones de diseño
modelos de aplicación / arquitectura
gestión de proyectos de software

Tenga en cuenta que se han realizado varios esfuerzos para traducir los patrones de diseño y los elementos clave de la “refactorización” (como los olores de código) a otros lenguajes de programación. Puede que le resulte útil encontrar algunos de esos esfuerzos. Además, los libros y tutoriales sobre programación idiomática en cualquier idioma en el que estés trabajando son una buena idea. Encuentro que aprendo más de los tutoriales que van de un idioma a otro, es decir, “python para programadores Java” o similares, porque tienden a dar mucho más razonamiento detrás del idioma.

Answer 3

Si se avecina una fecha límite, tiene que presionar y la calidad del código se queda atrás debido a la presión del tiempo. Como mínimo, trataría de aislar el “desorden” para que no contamine el código marco / infraestructura. En otras palabras, descubra cómo aislar su código desordenado como una caja negra utilizada por el resto de la aplicación.

Si es demasiado complejo, diría que el mejor enfoque es simplificar. ¿Por qué es complejo? Romperlo. Desacoplar Construya subsistemas más pequeños y simples que use para componer el sistema complejo más grande.

Si tuviera tiempo, me detendría y daría un paso atrás. Me gustaría hacer algunas preguntas pertinentes como:

• ¿Qué estamos tratando de entregar? Muchas veces el desorden es el resultado de infracciones del principio de ingeniería o de YAGNI.
• ¿Por qué lo estamos haciendo como estamos? ¿Hay alguna forma más limpia?
• ¿Cómo podemos reestructurarnos para limpiar el código? Algunos problemas pueden ser resueltos por los cambios de arquitectura.
• ¿Cómo podemos aislar el “desorden” como una implementación muy específica sin contaminar el marco abstracto general y la infraestructura? Con frecuencia, aislar el desorden funciona a la perfección mientras se desarrollan otras características y la comprensión crece y, finalmente, se hace evidente una mejor solución. Aislar el desorden le da tiempo para lidiar con él, pero también con frecuencia, termina nunca regresando y limpiándolo.

Luego haga preguntas como:

• ¿Por qué terminamos en el lío?
• ¿Cómo detectamos el desorden antes?
• ¿Cómo prevenimos o reducimos la cantidad de desorden que introducimos?
• ¿Cómo aislamos el desorden como parte de nuestro proceso diario?

La mejor manera de administrar su base de código es evitar el desorden y reaccionar rápidamente. Su equipo necesita estar consciente de esto y usar procesos que les permitan administrarlo. Utilice revisiones por pares, programación / diseño de pares para funciones complejas. Abordar la deuda técnica como parte de su proceso semanal, identificación y resolución de la deuda técnica.

La comunicación dentro del equipo es enorme para estar al tanto de la deuda técnica. No tendrá todo el conocimiento de cómo funciona todo el sistema y cómo se organiza. El equipo debe trabajar en conjunto para encontrar la solución más práctica o sencilla.

Answer 4

A menudo les he hecho esta pregunta a los colegas: “¿cuándo crees que un proyecto greenfield se convierte en brown-field?”

Las respuestas varían, pero mi respuesta no. “En el momento en que cometes la primera línea de código”. Digo esto para resaltar el hecho de que toda la codificación es un conjunto de compromisos desde la primera línea de código. Algunos de esos compromisos dan cuenta de desordenado vs limpio o elegante.

Para responder a su pregunta, “depende”. Depende de los compromisos que tengas que hacer en ese momento. Si tiene poco tiempo o tiene una fecha límite difícil, puede dejarlo desordenado, pensando que volverá a refactorizar más tarde. Si no, lo limpias ahora. Puede, en una circunstancia diferente, optar por refactorizar algunas cosas pero no otras. Depende de los riesgos de refactorización, tiempo y otras presiones.

Como casi todo en el mundo de la ingeniería de software, es bastante fungible lo que haces. En exactamente la misma base de código en circunstancias ligeramente diferentes, es muy posible que se tomen decisiones muy diferentes. El truco para tener una feliz vida de codificación, es recordar todas las razones por las que no has refaccionado algo en el pasado cuando te topas con ese montón de desorden que crees que debería haber sido refaccionado hace años, y todos tus colegas están jurando abiertamente acerca de qué tan malvados fueron los programadores que vinieron antes que ellos, y acepte con calma que las decisiones que se tomaron en ese momento fueron las correctas para ese momento en el tiempo … Incluso si no lo fueran.

Answer 5

Consulté a los equipos que trabajaban para mejorar las aplicaciones heredadas que iban mucho más allá de “desorden”. Mi enfoque es aplicar el paradigma de servicio / componente, y usar los diagramas de secuencia para asignar responsabilidades a los componentes de acuerdo con sus descripciones, mejorando así el diseño lentamente. Funciona.

Todo se reduce a “admitir que tienes un problema”. Sin lugar a dudas, “los ingenieros con talento escriben código limpio y eficiente con el diseño en sus cabezas” es, con mucho, la forma más eficiente de desarrollar software, si usted es tan bueno. Usted, a juzgar por su pregunta, no lo es, al igual que casi todos en la industria. Eso significa que debe retirarse a enfoques más organizados y más estructurados: dibuje algunos UML, asigne propietarios a componentes / servicios, asigne responsabilidades en un juego estructurado. Si eso no mejora las cosas, el siguiente paso es introducir los diagramas de secuencia.

Si su desorden está en la interfaz de usuario, hacer algunos casos de uso esenciales con referencias cruzadas con la arquitectura de la información realmente cambiaría las cosas si se hace correctamente.

Solo manténgalo liviano, asegúrese de dibujar diagramas y escribir casos de uso nunca requiere más del 10% de codificación. Si requiere más, está en Parálisis de análisis.

Answer 6

Estás hablando de “deuda técnica”. Este término puede ayudarte a razonar al respecto.

Puede acumular algunas deudas, puede ayudar a progresar en el momento adecuado, pero solo debe saber que tendrá que pagarlas. Y cuanto más tarde, más caro.

En SCRUM, normalmente esto es parte de la discusión de la planificación del sprint entre el equipo técnico y el propietario del producto.

Answer 7

Tengo problemas similares porque principalmente hago prototipos para la investigación automotriz, por lo que tengo dos ferias de investigación al año en las que se presentan los prototipos. Lo que normalmente hago es ponerlo en marcha para una feria y después de la feria planeo un período de tiempo más largo para la refactorización.

Con el tiempo, mi necesidad de refactorización disminuyó debido a una mayor experiencia en arquitecturas y previendo cosas que podrían suceder y que realmente podrían romper esa arquitectura.