¿Debería esperarse que las bases de código grandes o antiguas sean fáciles de navegar?

Soy un estudiante universitario de ciencias de la computación actualmente en un año de colocación en una empresa que produce y admite una aplicación web de gran empresa. Me encanta la experiencia de ver cómo se produce el software en el mundo real, y me siento muy afortunado de encontrar una compañía que ofrezca la oportunidad no solo de mantener y ampliar la funcionalidad existente, sino también de desarrollar características completamente nuevas para el producto.

Dicho todo esto, sin embargo, soy muy consciente de que es muy, muy poco probable que sea un ejemplo perfecto de cómo desarrollarse correctamente. Lejos de eso, de hecho. Siento que estoy aprendiendo una gran cantidad de mi experiencia aquí, y no quiero aprender las cosas equivocadas o aprender malos hábitos de colegas que podrían ser difíciles de eliminar en el futuro. En general, es fácil saber qué es bueno y qué no, por ejemplo, la cobertura de la Prueba de Unidad aquí es prácticamente inexistente por varias razones (en su mayoría, excusas pobres mezcladas con uno o dos puntos válidos). Últimamente, sin embargo, he notado una ocurrencia regular de la que no estoy seguro.

Cada vez que comenzamos un nuevo proyecto, naturalmente necesitamos encontrar cualquier código relevante que deba ampliarse, modificarse o eliminarse. Me parece que, la gran mayoría de las veces, cualquier cosa que no se encuentre dentro de las secciones más utilizadas de la aplicación lleva a las personas una edad para encontrar dentro de la base de código. Hay uno o dos clientes potenciales que conocen bien su sección del código, pero incluso a veces se quedan perplejos y tienen que pasar mucho tiempo buscando lo que necesitan, o recurrir a alguien que ha estado editando esa parte del código recientemente ( si alguien) por ayuda. Cuando digo mucho tiempo, no me refiero a horas (por lo general), pero me parece que una buena base de código sería navegable a cualquier punto dentro de unos minutos en el peor de los casos, a cualquiera que esté vagamente familiarizado con el sistema.

Entonces, mi pregunta. ¿El problema anterior se debe a un código mal estructurado? Alternativamente, ¿se debe a que los desarrolladores no tienen suficiente conocimiento de la base de código? ¿O es simplemente inevitable en aplicaciones grandes, independientemente de cuánto trabajo se requiera para mantener clara la estructura de archivos?

O, de hecho ... ¿estoy perdiendo el tiempo en un tema que realmente no importa?

Las bases de código grandes no están diseñadas, evolucionan. Muchas cosas que no tienen sentido cuando se mira una instantánea actual, tienen mucho sentido cuando se tiene en cuenta el historial. Y no solo me refiero a la historia individual de la base del código, también me refiero a la historia de las prácticas de ingeniería de software en general.

Las pruebas unitarias siempre existieron hasta cierto punto, pero en realidad no tuvieron un uso generalizado hasta que se "inventó" la programación extrema y el desarrollo impulsado por pruebas, alrededor de los años 1999 a 2003. Muchas bases de código son anteriores a eso, y en consecuencia no lo fueron. diseñado de una manera que facilitó las pruebas unitarias.

Hay una historia similar detrás de otras prácticas de ingeniería de software. Por ejemplo, la revolución DVCS de 2005 cambió la forma en que las personas piensan sobre los flujos de trabajo y los modelos de ramificación, incluso con el control de versiones no distribuido. Para otro ejemplo, a pesar de que existía, casi nadie había oído hablar del patrón de diseño de MVC hasta que Microsoft creó un marco con ese nombre, y ahora no se desalienta mucho más la separación del modelo y la vista de lo que solía ser, incluso en proyectos que no usan el marco de Microsoft.

La creación y popularización de herramientas de revisión por pares en línea esencialmente terminó con la práctica de una revisión por pares como una reunión formal, y las hizo mucho más fáciles de realizar y, por lo tanto, más ubicuas. La popularización de los lenguajes recolectados de basura impulsó las innovaciones de administración de memoria en C ++, como los punteros inteligentes y RAII, que ahora se consideran una práctica estándar, pero desconocidos cuando se iniciaron muchas bases de código actuales. Podría seguir y seguir.

A medida que las empresas crecen, intentan aprovechar la reutilización del código tanto como sea posible, por lo que una arquitectura de código que sea ideal para un producto podría incorporarse a otro proyecto con poca modificación, aunque la arquitectura sea un poco incómoda en el nuevo contexto . Cuando esto sucede varias veces, posiblemente durante décadas, el panorama general deja de tener sentido.

No es que las empresas no quieran cambiar con los tiempos, sino que las bases de código son como los transatlánticos. Toman mucho tiempo y una planificación cuidadosa para darse la vuelta. Por lo tanto, es muy poco probable que encuentre una base de código grande que no se rediseñe de una manera diferente si se comienza desde cero hoy. Lo importante a tener en cuenta es si una empresa se esfuerza por girar en la dirección correcta.

Ciertamente, hay un límite en la complejidad que la mente humana puede comprender. No puede esperar que alguien sepa cómo manejar millones de líneas de código. Es por eso que debe estructurarlo y documentarlo de manera razonable y comprensible. Por lo general, se omiten las posibilidades de estructurar el código. No encontrará una clase de base de datos en el paquete para una interfaz gráfica de usuario. Pero también puede encontrar una clase de base de datos haciendo algo bastante diferente (por ejemplo, informes). Las clases y los módulos tienden a crecer casi orgánicamente. Es preferible organizar el código en más pero en clases más pequeñas con responsabilidades únicas para que el código sea más fácil de entender. El código fácil de entender es clave para lograr los objetivos de la ingeniería de software, por ejemplo, software correcto, robusto, reutilizable y extensible.

No encontrarás ningún desarrollador que quiera escribir mucho código. La idea es escribir solo lo mismo y tenerlo escrito de manera extensible.

Desafortunadamente, los desarrolladores tienen que reunir los requisitos s / w de negocios / ventas / marketing y generalmente nunca son específicos. Entonces, tiene casos de uso que deben ser parcheados en algún código que nunca tuvo la intención de hacer lo que está haciendo en primer lugar.

No hay forma de alterar esta situación, a menos que tenga una forma con las mentes humanas. Lo que puede salvarlo es la documentación obligatoria, un sólido marco de pruebas de unidad e integración, un sistema de seguimiento de errores, una lista de correo de desarrolladores dentro de la compañía que puede archivar correos, revisión por pares y aprender técnicas de programación genéricas.

Además, considere usar todo lo que pueda de los componentes de código abierto, ya que generalmente tienen una buena base de usuarios y niveles moderados de documentación. Más importante aún, tiene personas a las que hacer preguntas si su líder tecnológico está de vacaciones.

Los libros relacionados con el diseño de software a gran escala también son una adición bienvenida.

Al abordar una aplicación brownfield, el primer paso ideal es escribir pruebas unitarias para ella.

Esto logra varias cosas:

1. Te obliga a trabajar a través del código y comprenderlo
2. Las pruebas unitarias sirven como documentación y código de muestra para la funcionalidad existente, y
3. Las pruebas unitarias proporcionan una red de seguridad para la refactorización.

Si la organización tiene o no la inclinación de permitirte hacer esto, es otro asunto. Han vivido sin pruebas unitarias durante tanto tiempo; lograr que acepten reducir la deuda técnica de esta manera será difícil.