Los buenos instintos de codificación eventualmente te patearán los dientes

Escribí mis primeras líneas de código hace casi 32 años, cuando tenía 6 años. Desarrollé instintos de codificación muy fuertes. Podía ver cualquier problema e inmediatamente saber cómo resolverlo, solo por intuición.

Cuando empecé a codificar la web para vivir, me sentía como una estrella de rock. Encontré y solucioné errores más rápido que cualquiera de mis compañeros de trabajo. Mi equipo comenzó a asignarme todas las características más desafiantes y los errores más molestos. Incluso comenzaron a llamarme "mago".

Pero seguir tu intuición solo puede llevarte tan lejos. Llegué a una meseta. Y ninguna cantidad de instinto de codificación me iba a empujar más allá.

El problema de confiar en tu instinto

Desafortunadamente, la intuición como técnica para aprender y resolver problemas no se adapta muy bien. Cuando confías solo en el instinto y la intuición, obtienes una curva que se ve así:

Por supuesto, puede elegir aceptar sus límites y solo tratar problemas por debajo de la línea. Esto complacerá su fantasía de "codificador de estrella de rock", pero rápidamente comenzará a limitar su crecimiento y su carrera. Además, es aburrido.

A medida que avancé más y más en mi carrera, y comencé a desafiar realmente mis propias habilidades, comencé a notar una tendencia inquietante. Ya no era el chico más rápido de la cuadra.

Siempre supe que eventualmente me encontraría con personas más inteligentes y con más talento que yo. (Mis delirios de grandeza todavía estaban basados ​​en la realidad. No soy un genio).

Pero cuando miré a mi alrededor, me di cuenta de que algunas de las personas que me golpeaban no usaban un intelecto superior o algún tipo de regalo innato para el código. Simplemente tenían un arma secreta que me faltaba muchísimo: disciplina.

Resulta que un enfoque consistente, repetible y metódico para el aprendizaje y la resolución de problemas eventualmente superará cualquier don natural, o instinto, que pueda haber desarrollado.

Tus instintos no tienen oportunidad

Vamos a equipar esas habilidades de resolución de problemas

Independientemente de quién eres, cuánta pasión o talento natural tienes, eventualmente llegarás a un techo duro. Voy a compartir con ustedes algunas técnicas que mejorarán drásticamente sus habilidades disciplinadas para resolver problemas.

Supongo que, si tiene un depurador, ya lo ha ejecutado, buscó en Google la salida y no tuvo suerte.

También supongo que si alguien más informó el problema, usted podrá reproducir el problema. Esta segunda suposición es grande. Si no puede reproducir el problema, ese debe ser su primer paso.

Debe comparar el contexto y el entorno en el que se produjo el problema con el contexto y el entorno en el que está intentando reproducirlo. Comience a eliminar las diferencias que pueda, una por una, hasta que pueda reproducirse.

Una vez que pueda reproducir el problema, y ​​después de que el depurador no haya sido de alguna utilidad, puede probar los siguientes enfoques disciplinados.

RTFM

Lea la documentación, tonto! (Es cierto que esto no es lo que RTFM significa exactamente, pero puede haber niños leyendo).

En realidad, léelo, más de una vez si es necesario. No te limites a buscar algo que puedas copiar, pegar y rezar para que funcione.

El problema es que quieres una respuesta rápida. Quieres esa emoción de la victoria. Pero no estás dispuesto a trabajar. Tan despacio. Toma un respiro. Toma un café Y lea la documentación relevante hasta el final.

Si no tiene documentación, considere crear algunos y luego compartirlos con otros una vez que haya solucionado el problema.

Pon a prueba tus suposiciones

Si esperas que algo funcione y no funciona, es porque has hecho una mala suposición en algún lugar del camino. Haga un inventario de sus suposiciones e intente demostrar que cada una es verdadera.

Comience con los supuestos más básicos que pueden probarse rápidamente. ¿Se está ejecutando realmente el servidor? ¿Está conectado a la red? ¿Está todo escrito correctamente? ¿Están todos los corchetes y puntos y comas en el lugar correcto?

Si no comienzas con las cosas simples, y resulta ser una de estas cosas, cuando finalmente te des cuenta, querrás saltar por una ventana. Así que ahórrate el dolor de cabeza.

Desmontar y volver a montar

Johnny 5 puede haber estado vivo, pero su código no lo está. No tengas miedo de desmontarlo.

Retire los componentes de la solución hasta que comience a funcionar nuevamente, luego vuelva a colocar los componentes uno por uno para encontrar la pieza rota.

Esto se siente tedioso y aterrador, pero es una de las formas más efectivas y disciplinadas de encontrar la causa de un error en su código. Sin embargo, asegúrese de tener una copia de seguridad antes de comenzar, en caso de que accidentalmente termine con el código de Humpty Dumpty (código que no puede volver a armar).

Por cierto, si te encuentras en una situación en la que no sabes cómo volver a ensamblar el código como estaba, esto es una indicación de un problema potencialmente mayor: no entiendes la base de código con la que estás trabajando . Eso es malo plátanos, mi amigo.

Si tiene una fecha límite ajustada, busque ayuda inmediata de alguien que entienda la base de código mejor que usted. Si no existe tal persona, busque una larga noche y priorice conocer y comprender cómo funciona este código, para que pueda solucionarlo.

Eliminar variables

Todo lo que pueda cambiar de una prueba a la siguiente debe hacerse estático mientras se está depurando. No puedes alcanzar un objetivo en movimiento. Aquí es donde Test Driven Development (TDD) es útil. Si está utilizando TDD, entonces debería tener algunos objetos simulados a su disposición.

Los objetos simulados son objetos simulados que imitan el comportamiento de los objetos reales de manera controlada. Un programador generalmente crea un objeto simulado para probar el comportamiento de algún otro objeto, de la misma manera que un diseñador de automóviles usa un maniquí de prueba de choque para simular el comportamiento dinámico de un humano en los impactos de vehículos. - Wikipedia

Si no hiciste TDD, entonces tendrás que burlarte de las partes móviles ahora, para que puedas encontrar el error en condiciones estables.

Aquí hay un consejo: si te burlas de un objeto y el error desaparece repentinamente, entonces es probable que el error esté en el objeto que te burlaste.

Utilice el "apretón de saff"

Existe una técnica llamada "Saff Squeeze", nombrada y popularizada por Kent Beck, que es una especie de cruce entre las dos ideas anteriores.

Lo describe de esta manera:

"Para aislar un defecto de manera efectiva, comience con una prueba a nivel del sistema y progresivamente en línea y pode hasta que tenga la prueba más pequeña posible que demuestre el defecto". - Kent Beck

Entonces, en lugar de simulacros formales o desmontaje de código, simplemente agrega el cuerpo de las funciones que está probando en la prueba en sí, luego mueve las afirmaciones hacia abajo hasta que el error desaparezca.

Esto tiene el beneficio adicional de dejarlo con pruebas más pequeñas y más específicas.

Editar: Gracias a Jim Balter por señalar este enlace a un buen ejemplo y explicación de Saff Squeeze.

Después de arreglarlo, romperlo y arreglarlo de nuevo

Nunca deje un error hasta que comprenda completamente cómo lo solucionó. Debería poder reproducir el error y corregirlo nuevamente a voluntad.

No puedo enfatizar esto lo suficiente. Si corrige un error y no está seguro exactamente de qué lo causó o cómo logró solucionarlo, ese error volverá a morderlo en el peor momento posible.

¿Qué pasa con esos instintos?

Ahora que ha aprendido estas técnicas, ¿eso significa que siempre debe usarlas primero en lugar de confiar en sus instintos? No absolutamente no.

Lo que te recomiendo es que le des a tus instintos una caja de tiempo para tener éxito. Si tiene un fuerte presentimiento sobre cuál podría ser el problema, y ​​puede probar su presentimiento rápidamente, hágalo primero. Si el error está debajo de la línea verde en el cuadro anterior, es probable que sus instintos sean el camino más rápido hacia una solución.

Sin embargo, una vez que hayas intentado rápidamente tu primer o segundo presentimiento y te hayas equivocado, detén el enfoque de la escopeta y comienza a hacer las cosas metódicamente.

Tener instintos y disciplina te convertirá en uno de los mejores programadores de cualquier equipo.

Si te gustó esta pieza, por favor ❤ recomienda ❤ y compártela. Me gustaría ayudar a tantos desarrolladores como pueda.

Para ayudarlo aún más, he reunido una lista en PDF gratuita de mis cinco técnicas de refactorización de código favoritas, que conducen a menos errores.
haciendo clic aquí