9 formas de dominar el código horrible, rápido

Se te ha dado la tarea de implementar una nueva función en una base de código antigua, pero el código se ve horrible. ¿Cómo puedes entenderlo lo más rápido posible? Aquí hay varios atajos para ayudar a aprender las partes importantes del nuevo código sin perderse en los detalles irrelevantes.

Como programadores, a menudo tenemos que unirnos a nuevos proyectos, y la calidad del código puede estar por todas partes. Incluso con un equipo organizado, mantener la calidad del código constante en un proyecto de tamaño mediano a grande es un desafío.

Es por eso que entender código pobre rápidamente puede ser una habilidad valiosa. Puede ayudarte a ser muy productivo en poco tiempo y a reducir el estrés que normalmente conlleva ser el chico nuevo y tener que ponerse al día. Estar en una conversación con un compañero de trabajo y no saber de qué está hablando esa persona la mitad del tiempo es una sensación terrible.

Por otro lado, esta es una excelente oportunidad para mostrarle a su cliente o jefe su valía y que puede ponerse al día rápidamente e impresionarlos. La mayoría de los desarrolladores tardan semanas o meses en ser realmente productivos con una base de código que no construyeron ellos mismos.

Aquí te mostramos cómo dominar el código horrible rápidamente.

Pida ayuda. Es la estrategia más eficiente

Otras personas ya han aprendido cómo funciona el código, así que ¿por qué no preguntarles al respecto? Puedes pensar que te hace parecer un novato, pero mostrar curiosidad puede tener un fuerte impacto en tu imagen como empleado. Si la expectativa de su jefe era que usted fuera productivo rápidamente sin hacer preguntas, eso es un error de juicio de su parte.

Todos se toman su tiempo para ponerse al día. Haz preguntas y impresionarás a las personas que tienen la actitud adecuada para el trabajo en equipo.

En muchos casos, los desarrolladores originales habrán tomado decisiones extrañas o inesperadas, y ahí es donde hablar del código será mucho más valioso que leerlo. Esto es aún más cierto si falta documentación. Recuerde, los desarrolladores existentes tienen un valioso conocimiento del proyecto que no está escrito en ninguna parte.

Haga una lista de conceptos que no tienen sentido para usted

Puede haber conceptos de negocios que son nuevos para usted o que son demasiado complejos. Es importante obtener aclaraciones sobre ellos antes de intentar trabajar en código que maneje esos conceptos, para evitar malentendidos que podrían tardar un tiempo en descubrirse.

Incluso podría darse el caso de que esas ideas estén mal etiquetadas o representadas de una manera inesperada en una base de datos. Por lo tanto, evite estresarse por envolver su cerebro alrededor de eso, y simplemente vaya a la fuente y pregúntele a sus compañeros de trabajo al respecto.

En la misma línea, puede haber módulos, clases o entidades que no tengan nombres apropiados. Toma nota de ellos. Los elementos mal nombrados pueden llevar a una gran confusión, así que documéntelos con anticipación, así como cualquier otra cosa que afecte negativamente su capacidad de pensar en cómo funciona el código.

Facilitar la reproducción de errores

Al agregar el control de versiones de código y una máquina virtual como Docker o Vagrant, reducirá en gran medida el tiempo necesario para reproducir un error y probar su trabajo en una nueva función.

Cualquier tipo de malentendido sobre cómo funciona el código podría conducirte por el camino de construir lo incorrecto, ya sea porque lo que estás construyendo podría estar ahí y no lo has visto, o porque las cosas simplemente no funcionan como pensabas.

En este punto, quieres tener el control de versiones de Git en tu proyecto. De esa manera, podrá volver a una versión estable, o incluso trabajar en ramas separadas que se pueden descartar si es necesario.

Incluso es posible obtener una mayor reproducibilidad con Git, ya que puedes usar el alijo para agregar código de prueba o depuración mientras profundizas en un problema difícil de rastrear.

Para conocer la arquitectura de su proyecto, asuma las tareas de configuración y documentación desde el principio.

Lo mismo puede decirse de las máquinas virtuales y la reproducibilidad. Se han vuelto omnipresentes para cualquier equipo de desarrollo moderno, pero sin duda encontrará proyectos que no los están utilizando o incluso listos para ejecutarse dentro de uno. A veces, su primer paso como nuevo miembro del equipo es documentar los pasos que tomó para que un entorno funcione y, finalmente, convertir esos pasos en un script de configuración de VM.

Construir un diagrama de componentes

Un mapa mental de conceptos de negocio, un diagrama entidad-relacional (ERD) de las tablas de la base de datos y un diagrama simple de componentes de código pueden ayudar en gran medida a reducir la dificultad de comprender el nuevo código. ¿No recuerdas cómo funciona algo? Mantén abierto el ERD.

De hecho, cualquier herramienta gráfica que le ayude a digerir la información rápidamente y tener una vista de diez mil pies de un proyecto será valiosa. Otros ejemplos de herramientas que podrían ayudarlo son gráficos de dependencias, registros y un mapa de la pila de tecnología del proyecto.

Uno de los mayores consumidores de tiempo en desarrollo es el punto de integración entre sistemas. Tener una visión global del panorama del proyecto le ayudará a identificar qué puntos de integración son interesantes de examinar. Esos son los lugares que tienen más trabajo puesto en ellos, y la mayoría de los errores.

Por otro lado, la tecnología se mueve rápidamente, y podría haber oportunidades para reemplazar grandes partes del código base con soluciones más modernas y adecuadamente integradas. Un marco antiguo podría haber desarrollado una forma nueva y oficial de resolver un problema, o una biblioteca completamente nueva podría haberse desarrollado con una mejor compatibilidad en mente.

Utilice herramientas de visualización y modelado para ver el panorama general.

Prepárese para pruebas automatizadas

Antes de comenzar a romper cosas, siempre es prudente agregar pruebas unitarias relevantes. El problema con las pruebas y el código deficiente es que el código deficiente generalmente está estrechamente acoplado y es difícil (si no imposible) de probar. No se pueden aislar componentes que están entrelazados e indivisibles.

En esos casos, dé un paso atrás y realice la prueba desde una distancia más lejana. Por lo general, eso significa hacer pruebas de integración, para las que hay muchas herramientas disponibles. Las aplicaciones web se pueden probar con solicitudes HTTP, por lo que al menos es posible verificar que el sistema responderá de la misma manera a las mismas entradas.Sin embargo,

Las pruebas de integración tienen un rendimiento mucho peor que las pruebas unitarias. Siempre que pueda, implemente pruebas unitarias para que pueda recibir información más rápida sobre los cambios de código. Si eso no es posible, opte por pruebas funcionales o incluso de integración.

Este paso debería arrojar algo de luz sobre las partes del código que necesitan trabajo. Si hay una gran cantidad de código estrechamente acoplado, ese es un buen objetivo para refactorizar después de que se realicen las pruebas de integración, y luego para las pruebas unitarias más tarde.

Identificar estrategias de codificación inusuales o inadecuadas

Es hora de comenzar a refactorizar, pero ¿por dónde empezar?

Por lo general, el mejor lugar es donde las cosas se ven extrañas, o donde no se han seguido las mejores prácticas de desarrollo. Para el desarrollo web, eso podría significar controladores fat con código de modelo estrechamente acoplado.

Tenga en cuenta que las mismas estrategias podrían estar en uso en otros lugares. Así que si, por ejemplo, identificas que los controladores fat están presentes, es probable que los desarrolladores anteriores no intentaran tener controladores delgados. Puede esperar ver el mismo problema en otros controladores también, ya que eso reflejaba el estilo o las deficiencias del proceso de desarrollo anterior.

Al principio, trabajar en una pequeña tarea

Corregir un pequeño error en una función que es conceptualmente simple será muy esclarecedor y lo ayudará a sentirse productivo desde el principio.

Esta es una idea similar a lo que Andy Hunt y Dave Thomas llaman “balas trazadoras” en The Pragmatic Programmer. La lógica subyacente es la misma: Trabaja en algo de extremo a extremo para demostrarte a ti mismo que es posible, y luego mejora progresivamente ese trabajo inicial.

La aproximación “bala trazadora”. Crédito: El Programador Pragmático

Un buen ejemplo del tipo de mejora simple que puede hacer es tomar pequeños pasos de refactorización con código simple. Identifique una práctica de programación común que no se está siguiendo y aplíquela.

Uno de mis favoritos para esto es desanidar bloques condicionales. Así que en lugar de tener varios bloques if-if-if, uno dentro del otro, niegue el primero y devuelva, y haga lo mismo para todas las comprobaciones de tipo de validación que pueda encontrar. Esto puede ser tan simple como invertir una comprobación “if” y mover un poco de código, por lo que el riesgo es casi inexistente y el código plano será más fácil de leer.

Asegúrese de trabajar primero en las funciones de refactorización que son fáciles de probar, porque a pesar de que los cambios son de bajo riesgo, siempre es una buena idea poder validar su código antes de enviarlo a producción.

Póngase en un terreno familiar antes de abordar el código crítico

Aprenda siempre cómo se configura el proyecto primero, y solo después sumérjase en el lado arquitectónico. Las piezas más críticas del código de negocio y de integración son las más difíciles de entender y modificar. Evite meterse en problemas desde el principio.

Como regla general, evite los problemas comerciales que requieran que sepa más de lo que sabe actualmente sobre el proyecto o sobre el lado comercial. Por lo general, eso significa mantenerse alejado de las transacciones, los pagos o el código con muchas matemáticas hasta que comience a familiarizarse.

Una vez que sea productivo, se sienta cómodo con el estilo de codificación para el proyecto y no tenga problemas para solucionar problemas simples, es hora de trabajar en las cosas más difíciles, pero no antes.

Incluso si existe cierta urgencia para solucionar problemas de pago, por ejemplo, ese tipo de tarea puede ser increíblemente arriesgada. Un error allí podría costar el proyecto caro, y eso también recaerá en usted. Rehúse absolutamente a trabajar en tareas de alto riesgo desde el principio, si es posible.

Cómo lidiar con una pila de tecnología desconocida

Para el último punto, un problema común con el que me he encontrado es que cada nuevo proyecto generalmente incluye alguna tecnología con la que no estoy familiarizado.

Cuando eso sucede, tengo un par de estrategias que me ayudan a ponerme al día rápidamente. El camino obvio para aprender es leer documentación y familiarizarse con la nueva tecnología. Pero si bien aprenderá mucho sobre la estructura, ese camino no lo ayudará a aprender los casos de esquina, que generalmente vienen con experiencia. (“Caso de esquina” es un término de ingeniería que se refiere a una situación que ocurre fuera de los parámetros de operación normales.)

Una forma de acelerar este proceso de adquisición de experiencia es tomar recursos basados en preguntas como Stack Overflow y Quora y simplemente leerlos como un libro. Encuentre las preguntas más populares sobre la biblioteca que está aprendiendo y vea qué tipo de problemas suelen tener otras personas. No necesariamente vas a encontrarte con ellos tú mismo, pero solo saber lo que es posible es como brillar una luz brillante en tu mapa mental de esas nuevas ideas.

Aproveche las preguntas de desbordamiento de pila para obtener experiencia rápidamente. Crédito: Desbordamiento de pila

Para un enfoque más específico, busque información sobre las funciones de biblioteca que se utilizan específicamente en su nuevo proyecto. Mira en aquellos que son nuevos para ti y apréndelos con anticipación, antes de que tengas que tocar ese código en absoluto.

Comparte tus ideas