{"id":36115,"date":"2019-10-31T22:09:42","date_gmt":"2019-10-31T19:09:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete\/"},"modified":"2019-10-31T22:09:42","modified_gmt":"2019-10-31T19:09:42","slug":"ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"No aceptes desarrollar lo que no entiendes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"No
\n
\nDesde principios de 2018, ocupo el cargo de l\u00edder\/jefe\/desarrollador principal en el equipo: ll\u00e1malo como quieras, pero la esencia es que soy completamente responsable de uno de los m\u00f3dulos y de todos los desarrolladores que trabajan en \u00e9l. Esta posici\u00f3n me brinda una nueva perspectiva sobre el proceso de desarrollo, ya que participo en m\u00e1s proyectos y me involucro m\u00e1s en la toma de decisiones. Recientemente, gracias a estas dos circunstancias, me di cuenta de cu\u00e1n importante es la comprensi\u00f3n en la calidad del c\u00f3digo y en la aplicaci\u00f3n.<\/p>\n

La idea que quiero expresar es que la calidad del c\u00f3digo (y del producto final) est\u00e1 estrechamente relacionada con el grado de conciencia que tienen las personas que dise\u00f1an y escriben el c\u00f3digo sobre lo que est\u00e1n haciendo.<\/p>\n

Es posible que est\u00e9s pensando: 'Gracias, capit\u00e1n. Por supuesto, ser\u00eda bueno entender lo que uno escribe. De lo contrario, uno podr\u00eda contratar a un grupo de monos para que golpeen teclas al azar y as\u00ed quedarnos tranquilos'. Y tienes toda la raz\u00f3n. Por lo tanto, doy por hecho que comprendes que tener una comprension general de lo que se hace es esencial. Esto podr\u00eda considerarse como el nivel cero de comprensi\u00f3n, y no lo vamos a desglosar en profundidad. Vamos a detallar lo que realmente es necesario entender y c\u00f3mo esto impacta las decisiones que tomas cada d\u00eda. Si hubiera conocido estas cosas desde el principio, me habr\u00eda ahorrado mucho tiempo desperdiciado y c\u00f3digo dudoso.
\n<\/a><\/noindex>
\nAunque a continuaci\u00f3n no ver\u00e1s ni una l\u00ednea de c\u00f3digo, pienso que todo lo que se dice aqu\u00ed tiene una gran relevancia para escribir c\u00f3digo de calidad y expresivo. <\/p>\n

Primer nivel de comprensi\u00f3n: \u00bfPor qu\u00e9 no funciona?<\/h4>\n

\nLos desarrolladores generalmente alcanzan este nivel en las primeras etapas de su carrera, a veces incluso sin ning\u00fan tipo de ayuda de los dem\u00e1s, al menos seg\u00fan mis observaciones. Imagina que recibes un informe de error: alguna funci\u00f3n en la aplicaci\u00f3n no funciona y necesita ser reparada. \u00bfC\u00f3mo proceder\u00e1s?<\/p>\n

El esquema est\u00e1ndar es el siguiente:<\/p>\n

    \n
  1. Encontrar el fragmento de c\u00f3digo que causa el problema (como se hace esto es un tema aparte, lo trato en mi libro sobre c\u00f3digo obsoleto)<\/li>\n
  2. Hacer cambios en ese fragmento<\/li>\n
  3. Asegurarse de que el error est\u00e9 corregido y que no hayan surgido errores regresivos<\/li>\n<\/ol>\n

    \nAhora nos centraremos en el segundo punto: realizar cambios en el c\u00f3digo. Existen dos enfoques para este proceso. El primero: comprender qu\u00e9 est\u00e1 sucediendo en el c\u00f3digo actual, identificar el error y corregirlo. El segundo: avanzar a ciegas; agregar, por ejemplo, +1 en una declaraci\u00f3n condicional o un bucle, observar si esta funci\u00f3n ahora funciona en el escenario necesario, luego intentar algo m\u00e1s y as\u00ed hasta el infinito.<\/p>\n

    El enfoque correcto es el primero. Como explica Steve McConnell en su libro Code Complete (por cierto, lo recomiendo mucho), cada vez que hacemos un cambio en el c\u00f3digo, debemos ser capaces de predecir con confianza c\u00f3mo afectar\u00e1 a la aplicaci\u00f3n. Cito de memoria, pero si la correcci\u00f3n de errores no funciona como esperabas, eso deber\u00eda alarmarte seriamente y cuestionar todo tu plan de acci\u00f3n.<\/p>\n

    Resumiendo, para realizar una buena correcci\u00f3n de errores que no degrade la calidad del c\u00f3digo, es necesario entender tanto la estructura del c\u00f3digo como la fuente del problema espec\u00edfico.<\/p>\n

    Segundo nivel de comprensi\u00f3n: \u00bfPor qu\u00e9 funciona?<\/h4>\n

    \nEste nivel se alcanza de manera menos intuitiva que el anterior. Yo, siendo todav\u00eda un desarrollador principiante, lo aprend\u00ed gracias a mi jefe, y posteriormente expliqu\u00e9 varias veces el tema a los novatos.<\/p>\n

    Esta vez, imagina que recibiste dos informes de errores a la vez: el primero se refiere al escenario A, el segundo al escenario B. En ambos escenarios algo est\u00e1 fallando. Por lo tanto, primero te ocupas del primer error. Siguiendo los principios que hemos extra\u00eddo para el primer nivel de comprensi\u00f3n, profundizas en el c\u00f3digo relacionado con el problema, descubres por qu\u00e9 hace que la aplicaci\u00f3n se comporte de esa manera en el escenario A y haces correcciones razonables que dan exactamente el resultado que esperabas. Todo va excelente.<\/p>\n

    Luego pasas al escenario B. Repites el escenario en un intento de provocar el error, pero \u2014 \u00a1sorpresa! \u2014 ahora todo funciona como deber\u00eda. Para confirmar tu hip\u00f3tesis, deshaces los cambios realizados en el proceso de solucionar el error A, y el error B vuelve a aparecer. Tu correcci\u00f3n resolvi\u00f3 ambos problemas. \u00a1Qu\u00e9 suerte!<\/p>\n

    No contabas con esto en absoluto. Has ideado una forma de corregir el error en el escenario A y no tienes ni idea de por qu\u00e9 funcion\u00f3 tambi\u00e9n para el escenario B. En esta etapa, la tentaci\u00f3n de concluir que ambas tareas se han completado con \u00e9xito es muy grande. Tiene sentido, \u00bfno? La idea era eliminar errores, \u00bfverdad? Pero el trabajo a\u00fan no ha terminado: todav\u00eda necesitas averiguar por qu\u00e9 tus acciones corrigieron el error en el escenario B. \u00bfPor qu\u00e9? Porque podr\u00eda estar funcionando sobre principios incorrectos, y entonces tendr\u00e1s que buscar otra soluci\u00f3n. Aqu\u00ed tienes un par de ejemplos de tales casos:<\/p>\n