8 cosas que aprendí trabajando en una enorme base de código heredada

Mi primer trabajo de desarrollo me arrojó a una enorme base de código heredada. Mi último gran boleto involucró hacer que una biblioteca moderna funcionara dentro del marco de interfaz de usuario obsoleto que usa. Después de ese viaje, quería compartir algunos consejos que aprendí en el camino. (1) Aprende el código base corrigiendo errores. Idealmente, su empresa tendrá una buena documentación, pero a menudo las bases de código heredadas son las que solía mantener el desarrollador que se fue. Leer todo el código base para ponerse al día puede ser casi imposible. Descubrí que corregir errores es una excelente manera de conocer la "personalidad" de su aplicación mientras se familiariza con sus flujos de trabajo. Incluso la simple lectura de los tickets de trabajo pendiente le da una idea de las prioridades de la empresa, las abreviaturas y lo que los usuarios quieren solucionar. (2) Los tutoriales y los materiales de referencia pueden ser difíciles de encontrar. Esto es especialmente cierto si alguno de los paquetes, bibliotecas o herramientas del código base ha quedado obsoleto. Familiarízate con las versiones de lo que tienes instalado. Incluye la versión en tu búsqueda en Google. Incluso si puede encontrar tutoriales, su aplicación puede estar escrita en un patrón de diseño diferente. Además, muchos tutoriales actúan como si la aplicación estuviera construida alrededor de la herramienta que están demostrando. Hacer que algo funcione dentro de una aplicación establecida y obstinada es un juego de pelota completamente nuevo. No tengas miedo de probar literalmente cualquier idea que se te ocurra. (3) Querrá apoyarse en personas que tengan más experiencia con la aplicación. Esto no solo significa otros desarrolladores. Los gerentes de control de calidad, ciencia de datos y proyectos que han trabajado en la aplicación durante años sabrán cosas que lo ayudarán inmensamente. Cuando me quedo atascado tratando de encontrar de dónde proviene un error, a menudo les pregunto "¿Hay algún flujo de trabajo que pueda afectar esto que me estoy perdiendo?" A veces, saber cómo se implementó una función le dará una idea de por qué un error recién comenzó a ocurrir ahora, se acaba de informar o no es una prioridad para corregir. (4) Siempre verifique si alguien ha resuelto el problema anteriormente antes de escribir una forma completamente nueva de resolverlo. Apóyate en utilidades y código previamente escrito. Si no está agregando un nuevo tipo de datos, las interacciones con la base de datos que está tratando de implementar probablemente ya existan. No olvide mirar los flujos de trabajo fuera del que está tratando de corregir actualmente. Los desarrolladores anteriores solo miraban sus entradas, no las tuyas. (5) Trate de no duplicar nunca el código. Familiarícese con las utilidades de su base de código y los métodos de importación para que pueda usar el código ya escrito que necesita en cualquier parte de la base de código. No es necesario agregar complejidad o tener que cambiar cosas en varios lugares. Una base de código heredada que ya ha tenido muchos desarrolladores probablemente tenga más de un ejemplo de ambos. Además, es posible que supieran sobre una peculiaridad en el sistema que tú no conoces. (6) Por otro lado, muchas utilidades significan mucha abstracción. Las funciones que dependen de las utilidades establecidas pueden volverse muy densas de leer de principio a fin. Está bien tener solo un alto nivel de comprensión de lo que hace una utilidad. Si alguna vez necesita implementarlo en otro lugar o si algo salió terriblemente mal dentro de él, ese es el momento de profundizar en cómo funciona. (7) Si no tiene una respuesta sobre cómo lo mejoraría, no se queje. No sabe las limitaciones de tiempo bajo las que estaba el desarrollador o si se les dijo que fueran en una dirección con la que no estaban de acuerdo personalmente. Si tiene una respuesta, discuta con su equipo si esa es una prioridad a la que puede dedicar tiempo. Si es un boleto pequeño o algo que puede dividir en boletos pequeños, puede usar esos proyectos apasionantes como recompensas por completar los errores que realmente lo desafiaron o que no lo desafiaron en absoluto. (8) "Vamos a limitar el alcance de esto". es su nuevo lema. Desea intentar afectar a la menor cantidad posible de flujos de trabajo. Una base de código heredada suele ser bastante estable y es algo con lo que la gente cuenta para funcionar. La reforma radical es tentadora, pero a menudo su trabajo consiste simplemente en tapar los pequeños agujeros.