¿Hay alguna manera de evitar el código espagueti a lo largo de los años? [cerrado]

Creo que la clave para evitar la putrefacción del código radica en las metodologías de diseño e implementación de abajo hacia arriba (lo creo tan firmemente que nombré mi negocio - Piense de abajo hacia Arriba - después de él!). Las herramientas de elección aquí son:

• Programación por contrato
• Diseño en capas
• Centrarse en la disociación
• Siempre construya con la reutilización en mente, buscando soluciones genéricas
• Mantenga marcos ligeros, simples y enfocados

Según lo sugerido por otros los encuestados, es necesario detectar los problemas temprano. Con los desarrolladores verdes, esto significa tutoría (la programación de pares es genial aquí) y revisiones (revisiones de código y diseño). Con desarrolladores más experimentados, esto significa vigilancia.

Sobre todo, no tengas miedo de refactorizar. Si la refactorización te asusta, ya estás hundido. Si la refactorización se ve como "mala", entonces hay algo mal con su negocio.

Cuando arregles algo, arréglalo correctamente. Uso el término "fux" para describir una solución eso se hizo de la manera equivocada: simplemente " fux " su base de código.

Salud,

Dan

20 a 50 desarrolladores es probablemente el problema. Eso es bastante alto y necesitaría una gran cantidad de gestión y recursos para mantener todo bajo control.

Consideraría dividir el proyecto en segmentos reutilizables más pequeños. Abstraer ciertas capas lejos del sistema central.

Cree "firewalls" entre diferentes áreas del código. Esto se hace definiendo diferentes áreas o capas de código, y definiendo una sola API (en Java, esto generalmente se hace con una interfaz) a la que responde cada capa. Debe haber intefaces o clases básicas que utiliza la API, pero que "no saben" nada sobre el funcionamiento interno de esas capas. Por ejemplo, la gui no debe saber ni preocuparse por cómo almacena los datos, y su base de datos no debe saber ni preocuparse por cómo se presentan los datos a la usuario final.

Estas APIs no tienen que ser fundidas en piedra, deberías poder agregar cosas según sea necesario, siempre y cuando te asegures de no contaminar los firewalls.

Creo que el punto principal es cuando dices

Solo quieres reescribir todo desde cero

Solo acéptalo.
Use tantas pruebas unitarias como sea posible, luego deje que la refactorización sea una práctica común .
La prueba automatizada y unitaria asegurará que los cambios no introduzcan regresiones; dedicando un cierto porcentaje de su tiempo a refactorizar código antiguo (y esto significa, menos nuevas características!) asegúrese de que el código base existente no se vuelva viejo, o en menos no tan rápido.

Revisiones de código, estándares de codificación y políticas de la empresa.

Lo siguiente es aplicable a nuestra tienda - ya que no se que tipo de tienda tiene, su kilometraje puede variar. Mientras nos mudábamos a Team Foundation Server, una gran parte de nuestro enfoque estaba en mantener la calidad del código, o al menos ayudar a mantener la calidad de cualquier manera posible. Algunos ejemplos de lo que estamos agregando:

• Flujo de trabajo de revisión de código: Impone la revisión de código como parte del proceso. Contiene una política que evite que se realicen check-ins si el código no ha sido revisado.
• TeamReview - Hace que las revisiones de código sean menos dolorosas al proporcionar una experiencia completa "dentro del IDE".
• Políticas de check-in (en general) - Muchas cosas interesantes disponibles para controlar el flujo de código. Cosas como asegurarse de que los métodos públicos y protegidos estén documentados antes del check-in o asegurarse de que no se pueda registrar ningún trabajo sin un elemento de trabajo correspondiente.

Como he dicho, si usted está utilizando un plataforma diferente, tal vez las herramientas disponibles y lo que puede hacer es diferente. Pero no descartes herramientas para ayudar de cualquier manera posible. Si puede usarlo para mejorar, controlar y auditar su flujo de trabajo y los elementos que se mueven dentro de él, debería valer la pena considerarlo.

Recuerde, cualquier cambio en el proceso va a implicar retroceso. La forma en que hemos ayudado a facilitar esto es construir las políticas en el entrenamiento para la transición de nuestro antiguo control de versiones / defecto sistema de rastreo.

Parece que muchos no están siguiendo algunos principios básicos de encapsualtion y buen diseño.

Mantener las cosas aisladas y poco fiables en otras partes es esencial para evitar el problema que describe. Es posible que necesite algún diseñador o arquitecto de nivel superior. Este es un escenario típico donde la gente ha justificado algunos procesos draconianos y la gestión del cambio. (No abogo por eso)

Debe evitar dependencias e interrelaciones y definir y usar interfaces públicas solo. Por supuesto, esto es una simplificación excesiva, pero probablemente aprenderá mucho por algunas métricas en su código: complejidad de clases, métodos públicos, diagramas UML construidos a partir de ingeniería inversa del código, etc.

Creo que el acoplamiento suelto que puede obtener con el uso completo de la inyección de dependencias es una característica técnica que puede ayudar mucho. Cuando rompes las piezas de la aplicación, es menos probable que obtengas espaguetis como resultado de la reutilización" interesante".

Puede que se dirija a una fragmentación excesiva, pero ese es otro problema y menos problema estructural global.

No permita que el código se confirme hasta que al menos dos pares de ojos lo hayan visto.

Refactorización

Esfuérzate por mantener el diseño lo más limpio posible. Esto no es fácil, pero vale la pena el esfuerzo.

No creo que sea normal. Es realmente difícil luchar contra esta cosa cuando estuvo allí durante un par de años.

La única manera de evitarlo es cambiar la actitud:

"La actitud que los desarrolladores ágiles tienen hacia el diseño del software es la misma actitud que los cirujanos tienen hacia el procedimiento estéril.  El procedimiento estéril es lo que hace posible la cirugía .  Sin ella, el riesgo de infección sería demasiado alto para tolerar.  Los desarrolladores ágiles sienten lo mismo sobre sus diseños.  El riesgo de dejar que incluso la más pequeña parte de la putrefacción comience es demasiado alto para tolerarlo." Martin C. Robert "Principios, Patrones y Prácticas Ágiles en C#"

Recomiendo encarecidamente mirar este libro para obtener consejos. Nombra a todos los "olores de diseño", las razones de su existencia y las consecuencias de abandonarlos. Que esto le ayude a persuadir a su dirección de que la situación actual no es apropiada.

¡Buena suerte!

El mayor problema en la industria del software es que la calidad del código de programación se ve como un problema subjetivo. Sin una métrica bien definida, solo ser ordenado y ordenado, y seguir las convenciones no es suficiente para garantizar que la calidad sea aceptable.

Hay intentos de cambiar esto, pero es poco probable que obtengan suficiente interés o aceptación principalmente porque la cultura establecida desde hace mucho tiempo de los programadores está en tratar muy duro para mantenerse alejado de cualquier cosa que se parezca a la ingeniería. La filosofía de" arte puro "de la programación significa que sus 20-50 desarrolladores van a cambiar el código en su propia manera única, por lo que no importa lo buenos que sean los codificadores individuales, la suma total del esfuerzo del grupo siempre va a ser"una gran bola de barro".

Para evitar esto, obtenga todos los codificadores en la misma 'página', haga que el código normalizado forme parte de su convención, o busque trabajos donde los equipos de desarrollo sean más pequeños (1-3 personas) y tú eres el gran kahuna. Algún día los grandes equipos pueden encontrar una manera de construir mejores cosas, pero hasta entonces, incluso los mejores de ellos son extremadamente afortunados si pueden acercarse a 6 de 10. Construimos software de baja calidad porque eso es lo que hemos establecido para hacer en nuestra industria ...

Paul.

Debe seguir de cerca las prácticas de desarrollo de software. Tiene que haber revisiones de código y pruebas unitarias que se aseguren constantemente de que las actualizaciones están afectando a otras cosas en el sistema. 20-50 desarrolladores es mucho, pero se puede hacer. Implementar buenos procesos es lo único que te salvará en este entorno. Las normas de codificación obligatorias también son clave.

El seguimiento de defectos y el rendimiento de varias partes del sistema le permitirá identificar problemas. A medida que se cambian los sistemas, las funciones o módulos mal diseñados o escritos tendrán una mayor tasa de defectos. Cuando se identifica un módulo "problema", se puede tomar la decisión de reescribir el módulo (NO la aplicación).

Refactorización continua. tiene para refactorizar a medida que avanza, especialmente a nivel de diseño. Cuando vea código o diseño roto, prepárese para arreglarlo. Este es a menudo un caso de arreglar algo que no está roto, per se. Excepto que lo es... simplemente no está manifestando su quebrantamiento... aun.

No

:)

Shore and Warden's El Arte del Desarrollo Ágil es un gran libro, con una sección sobre "Aplicar XP a un Proyecto Existente" (en el capítulo 4). Los proyectos empeoran con el tiempo a menos que luches duro: superar esa deuda técnica es difícil y hará que sea cada vez más difícil enviar liberaciones aceptables. La única solución es reducir la velocidad a la que entrega nuevas funciones y dedicar el tiempo ahorrado a mejorar la cobertura de las pruebas y la refactorización.

Normalmente, los proyectos no tiene mucha cobertura de prueba, y no tiene la opción de ejecutar un script automatizado de 10 minutos que construirá y ejercitará su código bastante a fondo. En cambio, la mayoría del código está estructurado de manera que es difícil de probar. La mejor opción entonces es agregar cobertura de prueba simple donde pueda, mientras comienza a refactorizar con el fin de hacer que el código se abstraiga de manera que sea más fácil de probar.

Aunque el equipo necesitará pasar tiempo mejorando el código para hacerlo limpio y comprobable, probablemente no será capaz de dejar de entregar por el tiempo que tomaría "terminar" la limpieza. Por lo tanto, usted tiene que hacerlo paso a paso, mientras que también la adición de nuevas características. Está bien, elige primero las peores áreas y no esperes beneficios obvios de inmediato. Sigue así, porque eventualmente llegarás allí. No escuches las voces que dicen que todos los grandes proyectos son malos.

En resumen, dedique un poco de tiempo cada semana a ordenar, y asegúrese de que el código sea mejor la próxima semana que esta semana.

Más revisiones de código y quizás propiedad de código.

Si simplemente hackeas algún código aleatorio, entonces no te importa tanto como el código que "posees". Si es tu responsabilidad mantener un módulo del proyecto, quieres brillar.

Y revisiones de código es un momento en el que muestra su código.

Comience a crear pruebas unitarias, esto le ayudará a desacoplar su código y evitar errores de seguimiento en correcciones de errores. Si tiene una buena cobertura, también le será más fácil eliminar el código no utilizado.