Desde principios de 2018, he sido el desarrollador líder / jefe / líder del equipo, llámelo como quiera, pero la conclusión es que soy completamente responsable de uno de los módulos y de todos los desarrolladores que trabajan en él. Esta posición me da una nueva mirada al proceso de desarrollo, ya que estoy involucrado en más proyectos y participo más activamente en la toma de decisiones. Recientemente, gracias a estas dos circunstancias, de repente me di cuenta de cuánto afecta la comprensión al código y la aplicación.
La idea que quiero expresar es que la calidad del código (y el producto final) está estrechamente relacionada con cuánto saben las personas que diseñan y escriben el código lo que están haciendo.
Puede estar pensando ahora: “Gracias, cap. Por supuesto, sería bueno entender lo que escribes. De lo contrario, con el mismo éxito, puedes contratar a un grupo de monos para que toquen teclas arbitrarias y tranquilizarte ". Y tienes toda la razón. Por consiguiente, doy por sentado: te das cuenta de que es necesario tener una idea general de lo que estás haciendo. Esto puede llamarse un nivel cero de comprensión, y no lo analizaremos en detalle. Analizaremos en detalle qué es exactamente lo que debe entenderse y cómo afecta las decisiones que toma todos los días. Si supiera estas cosas de antemano, esto me ahorraría un montón de tiempo perdido y código dudoso.
Aunque no verá una sola línea de código a continuación, sigo pensando que todo lo que se dice aquí es de gran importancia para escribir código expresivo de alta calidad.
Primer nivel de comprensión: ¿por qué no funciona?
Los desarrolladores suelen llegar a este nivel en las primeras etapas de su carrera, a veces incluso sin la ayuda de otros, al menos según mis observaciones. Imagine que tiene un informe de error: alguna función de la aplicación no funciona, necesita corregirla. ¿Cómo actuarás?
El esquema estándar se ve así:
- Encuentre el fragmento de código que causa el problema (cómo se hace esto es un tema aparte, lo divulgo en mi libro sobre código desactualizado)
- Realizar cambios en este fragmento
- Asegúrese de que el error esté solucionado y que no haya errores regresivos
Ahora centrémonos en el segundo punto: realizar cambios en el código. Hay dos enfoques para este proceso. Primero: para profundizar en lo que está sucediendo exactamente en el código actual, identifique el error y corríjalo. Segundo: muévase al tacto: agregue, digamos, +1 a una declaración o bucle condicional, vea si esta función funcionó en el escenario correcto, luego intente algo más y así hasta el infinito.
El primer enfoque es correcto. Como Steve McConnell explica en su libro Code Complete (por cierto, lo recomiendo), cada vez que cambiemos algo en el código, deberíamos poder predecir con confianza cómo esto afectará la aplicación. Cito de memoria, pero si la corrección de errores no funciona como esperaba, debe ser muy cauteloso para usted, debe cuestionar todo su plan de acción.
Resumiendo lo anterior, para realizar una corrección de errores sólida que no degrade la calidad del código, debe comprender toda la estructura del código y la fuente de un problema específico.
Segundo nivel de comprensión: ¿por qué funciona?
Este nivel se comprende mucho menos intuitivamente que el anterior. Al ser un desarrollador novato, lo aprendí gracias a mi jefe, y más tarde le expliqué repetidamente la esencia del asunto a los principiantes.
Esta vez, imaginemos que recibió dos informes de errores a la vez: el primero es sobre el escenario A, el segundo sobre el escenario B. Algo está mal en ambos escenarios. En consecuencia, te llevan primero por el primer error. Guiado por los principios que introdujimos para el primer nivel de comprensión, profundiza en el código relevante para el problema, descubre por qué obliga a la aplicación a comportarse exactamente así en el escenario A y realiza ajustes razonables que dan exactamente el resultado que usted esperado. Todo va bien
Luego vas al escenario B. Repites el guión en un intento de provocar un error, pero ¡una sorpresa! - Ahora todo funciona como debería. Para confirmar su suposición, cancela los cambios realizados en el proceso de trabajar en el error A, y el error B regresa nuevamente. Su corrección de errores resolvió ambos problemas. Afortunado
No contabas con eso en absoluto. Se le ocurrió una manera de corregir el error en el escenario A y no tiene idea de por qué funcionó para el escenario B. En esta etapa, existe una gran tentación de decidir que ambas tareas se han completado con éxito. Esto es bastante lógico: el punto era eliminar errores, ¿no? Pero el trabajo aún no ha terminado: todavía tiene que descubrir por qué sus acciones corrigieron el error en el escenario B. ¿Por qué? Entonces, que él puede estar trabajando en los principios equivocados, y luego tendrá que buscar otra forma. Aquí hay un par de ejemplos de tales casos:
- Dado que la solución no pudo ser dirigida específicamente para el error B, teniendo en cuenta todos los factores, es posible que haya roto la función C.
- es posible que en algún lugar el tercer error relacionado con la misma función también se haya ocultado, y su corrección de errores hace que el sistema funcione correctamente en el script B. Ahora todo se ve bien, pero un buen día se notará y corregirá este tercer error. Luego, en el escenario B, se produce un error nuevamente, y bueno, aunque solo sea allí.
Todo esto introduce aleatoriedad en el código y algún día caerá en tu cabeza, muy probablemente en el momento más inoportuno. Tendrás que juntar tu voluntad en un puño para obligarte a pasar tiempo entendiendo por qué todo parece funcionar, pero vale la pena.
Tercer nivel de comprensión: ¿por qué funciona?
Mi percepción reciente está relacionada precisamente con este nivel, y probablemente me habría dado la mayor cantidad de beneficios si hubiera llegado a esta idea antes.
Para que quede más claro, echemos un vistazo a un ejemplo: su módulo debe ser compatible con la función X. No está particularmente familiarizado con la función X, pero le dijeron que necesita usar el marco F. para su compatibilidad. Otros módulos que se integran con X funcionan exactamente con el
Desde el primer día de su vida, su código no ha entrado en contacto con el marco F en absoluto, por lo que no será tan fácil implementarlo. Esto tendrá graves consecuencias para algunos componentes del módulo. Sin embargo, te diriges al desarrollo: escribe código durante semanas, prueba, implementa versiones piloto, obtén comentarios, corrige errores de regresión, encuentra complicaciones imprevistas, no encajas en el marco de tiempo acordado originalmente, escribe más código, prueba, obtén lo contrario conexión, errores de regresión correctos - todo esto para implementar el marco F.
Y en algún momento te das cuenta de repente, o tal vez escuchas de alguien, que tal vez el marco F no te dará compatibilidad con la función X. Tal vez todo este tiempo y esfuerzo no se aplicaron en absoluto a eso
Algo similar sucedió una vez en el curso del trabajo en un proyecto del que fui responsable. ¿Por qué sucedió esto? Porque no entendí bien cuál es la esencia de la función X y cómo se relaciona con el marco F. ¿Qué debo hacer? Pídale a la persona que establece la tarea de desarrollo que explique claramente cómo el plan de acción planificado conduce al resultado deseado, en lugar de simplemente repetir lo que se hizo para otros módulos, o decir que es necesario que la función X funcione.
La experiencia de este proyecto me enseñó a negarme a comenzar el proceso de desarrollo hasta que comprendamos claramente por qué se nos pide que realicemos ciertas acciones. Rechazar texto sin formato. Cuando recibe una tarea, el primer impulso es tomarla de inmediato para no perder el tiempo en vano. Pero la política de "congelar el proyecto hasta que entremos en todos los detalles" puede reducir el tiempo perdido en órdenes de magnitud.
Incluso si intentan presionarlo para obligarlo a comenzar a trabajar, aunque no entienda cómo se justifica, resista. Primero, descubra el propósito para el cual se le asignó dicha tarea y decida si este es el camino correcto hacia la meta. Tuve que aprender todo esto a través de una experiencia amarga. Espero que para quienes lean esto, mi ejemplo les facilite la vida.
Cuarto nivel de comprensión: ???
Siempre hay algo que aprender en programación, y supongo que solo toqué las capas superiores del tema de la comprensión. ¿Qué otros niveles de comprensión ha descubierto a lo largo de los años de trabajar con código? ¿Qué decisiones se tomaron que tuvieron un buen efecto en la calidad del código y la aplicación? ¿Qué decisiones resultaron incorrectas y te enseñaron una valiosa lección? Comparte tus experiencias en los comentarios.