coding style - solucion - ¿Hay alguna manera de evitar el código de spaghetti a través de los años?
mascarilla para el codigo de barras (19)
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!
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.
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.
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.
Creo que el acoplamiento flexible 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 un problema estructural global.
Creo que el punto principal es cuando dices
solo quieres reescribir todo desde cero
Sólo abrázalo.
Use tantas pruebas unitarias como sea posible, luego permita que la refactorización sea una práctica común .
La prueba automatizada y de unidad 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 !) garantizar que la base de código existente no envejecerá, o al menos no tan rápido.
Debe 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.
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 esto , pero es poco probable que obtengan suficiente interés o aceptación, principalmente porque la cultura de los programadores, establecida desde hace mucho tiempo, se esfuerza por mantenerse alejado de cualquier cosa que se parezca 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, consiga que todos los codificadores estén 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 el 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 ...
Pablo.
Más revisiones de código y quizás propiedad del código.
Si solo pirateas un código aleatorio, entonces no te importa tanto como el código que "posees". 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.
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 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 tolerarlo. Los desarrolladores ágiles sienten lo mismo sobre sus diseños. El riesgo de dejar que comience siquiera la más mínima podredumbre es demasiado alto para tolerarlo ". Martin C. Robert" Principios, patrones y prácticas ágiles en C # "
Recomiendo consultar este libro para 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!
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 en su código: complejidad de clases, métodos públicos, diagramas UML construidos a partir de ingeniería inversa del código, etc.
Refactorización continua. Tienes que 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.
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 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á usando 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.
el seguimiento de los defectos y el rendimiento de varias partes del sistema le permitirán 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).
Esfuércese por mantener el diseño lo más limpio posible. Esto no es fácil, pero vale la pena el esfuerzo.
No
:)
No permita que se cometa código hasta que al menos dos pares de ojos lo hayan visto.
El arte de desarrollo ágil de Shore and Warden 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.
Por lo general, 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 forma 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 por el tiempo que tomaría "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 a ordenar cada semana, y asegúrese de que el código sea mejor la próxima semana de lo que es esta semana.
Creo que la clave para evitar la podredumbre del código radica en las metodologías de diseño e implementación de abajo hacia arriba (creo que fue tan fuerte que nombré mi negocio, "Think Bottom Up", ¡después de eso!). Las herramientas de elección aquí son:
- Programación por contrato
- Diseño en capas
- Centrarse en el desacoplamiento
- Siempre construya pensando en la reutilización, buscando soluciones genéricas
- Mantenga los marcos ligeros, simples y enfocados
Como lo sugirieron otros encuestados, es necesario detectar problemas temprano. 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.
Por encima de todo, no tengas miedo de refactorizar. Si la refacturación te asusta, ya estás hundido. Si la refacturación es vista como "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.
Aclamaciones,
Dan
La diligencia implacable combinada con las constantes pruebas unitarias 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.
Llámelos y pídales que lo cambien
Me parece que señalar la mejor manera durante una revisión del código suele ser suficiente para que la gente funcione. 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.