¿Hay alguna manera de evitar el código de spaghetti a través de los años?

Question

He tenido varios trabajos de programación. Cada uno con 20-50 desarrolladores, proyecto que se desarrolla durante 3-5 años.

Cada vez es lo mismo. Algunos programadores son brillantes, algunos son promedio. Todos tienen su grado de CS, todos leen patrones de diseño. Las intenciones son buenas, la gente está tratando de escribir un buen código, pero aún después de un par de años el código se convierte en espagueti. Los cambios en el módulo A rompen de repente el módulo B. Siempre hay partes del código que nadie puede entender, excepto la persona que lo escribió. Cambiar la infraestructura es imposible y los problemas de compatibilidad con versiones anteriores impiden que entren buenas características. La mitad de las veces lo único que desea es volver a escribir todo desde cero.

Y las personas con más experiencia que yo tratan esto como normal. ¿Lo es? ¿Tiene que ser? ¿Qué puedo hacer para evitar esto o debería aceptarlo como un hecho de la vida?

Edit: Chicos, estoy impresionado con la cantidad y la calidad de las respuestas aquí. Este sitio y su comunidad rock!

Answer 1

La diligencia sin cuartel combinada con pruebas unitarias constantes es la única forma de prevenir el código de spaghetti. Incluso entonces solo es una solución de curita. Tan pronto como dejas de prestar atención, viene la pasta.

Muy a menudo encuentro que se introduce el código de spaghetti porque alguien simplemente es perezoso ese día. Saben que hay una mejor manera de hacerlo y simplemente no tienen tiempo. Cuando ve que eso sucede, solo hay una cosa que hacer.

llamar a cabo en él y pedirles que cambiarlo

me parece que señalar la mejor manera durante una revisión de código suele ser suficiente para que la gente que va. Si lo comprueban y lo siento fuertemente, lo refactorizaré yo mismo.

¿De vez en cuando me sale un poco excéntrico? Estoy seguro de que sí. Francamente, aunque no me importa. No soy un idiota al respecto y abordar esto de la mejor manera social posible.Sin embargo, dejar que se revisen los códigos incorrectos asegura que tendré que depurarlo en algún momento en el futuro. Prefiero tomar un pequeño flak ahora y obtener el código correcto.

También siento que una cultura de pruebas unitarias también ayuda a prevenir el código de spaghetti. Es mucho más difícil probar el código de spaghetti que código bien factorizado. Con el tiempo, esto obliga a las personas a mantener su código un tanto factorizado.

Answer 2

20 a 50 desarrolladores es probablemente el problema. Eso es bastante alto y necesitaría mucha administración y recursos para mantener todo bajo control.

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

Answer 3

Crea "firewalls" entre diferentes áreas del código. Para ello, defina diferentes áreas o capas de código y defina una única API (en Java, esto generalmente se hace con una interfaz) a la que responde cada capa. Debería haber intefaces básicas o clases que utiliza la API, pero que "no saben" nada sobre las partes internas de esas capas. Por ejemplo, la interfaz gráfica de usuario no debe saber ni importar cómo se almacenan los datos, y su base de datos no debe saber ni importar cómo se presentan los datos al usuario final.

Estas API no tienen que ser inamovibles: debería poder agregar cosas según sea necesario, siempre y cuando se asegure de no estar contaminando los firewalls.

Answer 4

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

Si piratea un código al azar, entonces no le importa tanto como el código que "posee". Si es su responsabilidad mantener un módulo del proyecto, desea brillar.

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

Answer 5

Tienes que seguir de cerca las prácticas de desarrollo de software. Tiene que haber revisiones de códigos y pruebas unitarias que constantemente aseguren 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 lo salvará en este entorno. Los estándares de codificación obligatorios también son clave.

Answer 6

Refactoring

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

Answer 7

Parece que muchos no siguen algunos principios básicos de encapsulado y buen diseño.

Mantener las cosas aisladas y no confiables en otras partes es esencial para evitar el problema que describes. Es posible que necesite un diseñador o arquitecto de más alto nivel. Este es un escenario típico en el que las personas han justificado algunos procesos draconianos y la gestión del cambio. (No defiendo eso)

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

Answer 8

seguimiento de defectos y rendimiento de varias partes del sistema le permitirá identificar problemas. A medida que 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 de "problema", se puede tomar una decisión para reescribir el módulo (NO la aplicación).

Answer 9

Creo que el punto principal es cuando se dice

lo que desea es volver a escribir todo desde cero

Sólo abrazarla.
Utilice tantas pruebas unitarias como sea posible, luego permita que la refactorización sea una práctica común.
La prueba automatizada y de unidades asegurará que los cambios no introduzcan regresiones; dedicar un cierto porcentaje de su tiempo a la refacturación de código antiguo (y esto significa, menos funciones nuevas!) asegúrese de que la base de código existente no envejecerá, o al menos no tan rápido.

Answer 10

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

La única forma de evitarlo es cambiar la actitud:

“La actitud que los desarrolladores ágiles tienen como objetivo el diseño del software es la misma actitud que los cirujanos tienen hacia 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 tolerarlo. Los desarrolladores ágiles sienten lo mismo sobre sus diseños.El riesgo de dejar lo más mínimo de la podredumbre comienza es demasiado alto como para tolerar.” Martín C. Robert ‘ágiles Principios, patrones y prácticas en C#’

le recomiendo mirar en este libro de consejos. Nombra todos los "olores de diseño", las razones de su existencia y las consecuencias de dejarlos. Puede que esto lo ayude a persuadir a su administración de que la situación actual no es apropiada.

¡Buena suerte!

Answer 11

Creo que el acoplamiento flojo que puede obtener con el uso completo de la inyección de dependencia es una característica técnica que puede ayudar mucho. Cuando se separan las piezas de la aplicación, es menos probable que obtengas espaguetis resultantes de una reutilización "interesante".

En su lugar, puede estar abocado a una fragmentación excesiva, pero ese es otro problema y menos problema estructural global.

Answer 12

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

Answer 13

Refactorización continua. Usted tiene para refactorizar sobre la marcha, especialmente en el nivel de diseño. Cuando vea código o diseño roto, prepárese para solucionarlo. Este es a menudo el caso de arreglar algo que no está roto, per se. Excepto que es ... simplemente no está manifestando que está roto ... todavía.

Answer 14

No

:)

Answer 15

revisiones de los códigos, normas y políticas de la firma de codificación.

Lo siguiente es aplicable a nuestra tienda, ya que no sé qué tipo de tienda tiene, su millaje puede variar. Al pasar a Team Foundation Server, gran parte de nuestro enfoque se centró 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 del código como parte del proceso. Contiene una política que evitará que ocurran check-ins si el código no ha sido revisado.
• TeamReview - Hace que las revisiones de códigos 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 para asegurarse de que no se pueda registrar ningún trabajo sin un elemento de trabajo correspondiente.

Como dije, si está utilizando una plataforma diferente, tal vez las herramientas disponibles y lo que puede hacer es diferente. Pero no descarte las 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, al menos vale la pena considerarlo.

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

Answer 16

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 estar limpio y ordenado, y seguir las convenciones no es suficiente para garantizar que la calidad sea aceptable.

Hay intentos de cambiar this, pero es poco probable que obtengan suficiente interés o aceptación principalmente porque la cultura de programadores establecida desde hace mucho tiempo es muy difícil mantenerse alejado de cualquier cosa que se asemeje a la ingeniería. La filosofía de programación del "arte puro" significa que sus desarrolladores de 20-50 van a arremeter contra el código a su manera única, de modo que no importa cuán buenos 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 sea parte de su convención, o persiga los trabajos si los equipos de desarrollo son más pequeños (1-3 personas) y usted es gran kahuna. Algún día los grandes equipos encontrarán la manera de construir mejores cosas, pero hasta entonces incluso los mejores de ellos son extremadamente afortunados si pueden acercarse a 6 de cada 10. Desarrollamos software de baja calidad porque eso es lo que hemos establecido nuestra industria para hacer ...

Paul.

Answer 17

Creo que la clave para evitar la podredumbre del código radica en el diseño de fondo y las metodologías de implementación (creo que es tan fuerte que nombré mi negocio - ¡Piensa de abajo hacia arriba - después de eso!). Las herramientas de elección aquí son:

• Programación por contrato
• diseño en capas
• Focus on desacoplamiento
• siempre construir con reutilización en mente, en busca de soluciones genéricas
• Keep marcos de peso ligero, simple y centrado

Según lo sugerido por otros encuestados, debe detectar los problemas con anticipación. Con los desarrolladores verdes, esto significa tutoría (la programación de pares es excelente aquí) y revisiones (revisiones de códigos y diseños). Con más desarrolladores senior, esto significa vigilancia.

Más que nada, no tenga miedo de refactorizar. Si la refacturación te asusta, ya estás hundido. Si la refacturación se considera "mala", entonces hay algo mal con su negocio.

Cuando arreglas algo, corrígelo correctamente. Utilizo el término "fux" para describir una solución que se hizo de forma incorrecta: simplemente "fux" su código base.

Saludos,

Dan

Answer 18

No permita código que se ha comprometido hasta por lo menos dos pares de ojos lo han visto.

Answer 19

Shore and Warden's The Art of Agile Development 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 luche duro: superar esa deuda técnica es difícil y hará cada vez más difícil enviar lanzamientos aceptables. La única solución es reducir la velocidad a la que entregas nuevas funciones y dedicar el tiempo ahorrado a mejorar la cobertura de prueba y la refactorización.

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

Aunque el equipo tendrá que perder tiempo mejorando el código para hacerlo limpio y comprobable, probablemente no podrá dejar de entregar durante el tiempo que "terminará" la limpieza. Por lo tanto, debe hacerlo paso a paso mientras agrega nuevas características. Está bien, elija las áreas peores primero y no espere un beneficio obvio de inmediato. Mantente alerta, porque eventualmente llegarás allí. No escuche las voces que dicen que todos los proyectos grandes son malos.

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