Desde principios de 2018, ocupo el puesto de líder/jefe/desarrollador líder en el equipo; llámalo como quieras, pero la cuestión es que soy enteramente responsable de uno de los módulos y de todos los desarrolladores que trabajan. en eso. Este puesto me da una nueva perspectiva sobre el proceso de desarrollo, ya que estoy involucrado en más proyectos y más activamente en la toma de decisiones. Recientemente, gracias a estas dos circunstancias, de repente me di cuenta de cuánto afecta la medida de comprensión al código y a la aplicación.
Lo que quiero señalar es que la calidad del código (y el producto final) está estrechamente relacionada con el grado de conciencia de lo que están haciendo las personas que diseñan y escriben el código.
Quizás estés pensando ahora mismo: “Gracias, Cap. Por supuesto, sería bueno entender lo que escribe en general. De lo contrario, también podrías contratar a un grupo de monos para que presionen teclas arbitrarias y dejarlo así”. Y estás absolutamente en lo cierto. En consecuencia, doy por sentado que te das cuenta de que es necesario tener una idea general de lo que estás haciendo. A esto se le puede llamar el nivel cero de comprensión y no lo analizaremos en detalle. Analizaremos en detalle qué es exactamente lo que necesita comprender y cómo afecta las decisiones que toma todos los días. Si hubiera sabido estas cosas de antemano, me habría ahorrado mucho tiempo perdido y códigos cuestionables.
Aunque no verá ni una sola línea de código a continuación, sigo creyendo que todo lo dicho aquí es de gran importancia para escribir código expresivo y de alta calidad.
Primer nivel de comprensión: ¿Por qué no funciona?
Los desarrolladores suelen alcanzar este nivel muy temprano en sus carreras, a veces incluso sin la ayuda de otros, al menos en mi experiencia. Imagine que recibió un informe de error: alguna función de la aplicación no funciona, es necesario solucionarla. ¿Cómo procederás?
El esquema estándar se ve así:
- Encuentre el fragmento de código que está causando el problema (cómo hacerlo es un tema aparte, lo cubro en mi libro sobre código heredado)
- Realizar cambios en este fragmento
- Asegúrese de que el error esté solucionado y que no se hayan producido errores de regresión
Ahora centrémonos en el segundo punto: realizar cambios en el código. Hay dos enfoques para este proceso. La primera es profundizar en qué está sucediendo exactamente en el código actual, identificar el error y solucionarlo. Segundo: moverse por sensación: agregue, digamos, +1 a una declaración o bucle condicional, vea si la función funciona en el escenario deseado, luego intente algo más, y así hasta el infinito.
El primer enfoque es correcto. Como explica Steve McConnell en su libro Code Complete (que, por cierto, recomiendo mucho), cada vez que cambiamos algo en el código, deberíamos poder predecir con confianza cómo afectará a la aplicación. Estoy citando de memoria, pero si una corrección de error no funciona como esperaba, debería alarmarse mucho y cuestionar todo su plan de acción.
Para resumir lo dicho, para realizar una buena corrección de errores que no degrade la calidad del código, es necesario comprender tanto la estructura completa del código como el origen del problema específico.
Segundo nivel de comprensión: ¿Por qué funciona?
Este nivel se comprende de forma mucho menos intuitiva que el anterior. Yo, siendo todavía un desarrollador novato, lo aprendí gracias a mi jefe y posteriormente expliqué repetidamente la esencia del asunto a los recién llegados.
Esta vez, imaginemos que recibió dos informes de error a la vez: el primero es sobre el escenario A, el segundo es sobre el escenario B. En ambos escenarios, sucede algo mal. En consecuencia, primero aborda el primer error. Utilizando los principios que desarrollamos para la comprensión del Nivel XNUMX, usted profundiza en el código relevante para el problema, descubre por qué hace que la aplicación se comporte como lo hace en el Escenario A y realiza ajustes razonables que produzcan el resultado esperado. . Todo va genial.
Luego pasas al escenario B. Repites el escenario en un intento de provocar un error, pero ¡sorpresa! — ahora todo funciona como debería. Para confirmar su suposición, deshace los cambios que realizó mientras trabajaba en el error A y el error B regresa. Su corrección de errores resolvió ambos problemas. ¡Afortunado!
No contabas con esto en absoluto. Se le ocurrió una forma de corregir el error en el escenario A y no tiene idea de por qué funcionó en el escenario B. En esta etapa, es muy tentador pensar que ambas tareas se han completado con éxito. Esto es bastante lógico: se trataba de eliminar errores, ¿no? Pero el trabajo aún no ha terminado: todavía tienes que descubrir por qué tus acciones corrigieron el error en el escenario B. ¿Por qué? Porque puede que esté trabajando con principios equivocados y entonces tendrá que buscar otra salida. Aquí hay un par de ejemplos de tales casos:
- Dado que la solución no se adaptó al error B, teniendo en cuenta todos los factores, es posible que, sin saberlo, haya roto la función C.
- Es posible que también haya un tercer error acechando en alguna parte, relacionado con la misma función, y su corrección de errores dependa de él para el correcto funcionamiento del sistema en el escenario B. Todo parece estar bien ahora, pero algún día este tercer error se notará y se solucionará. Luego, en el escenario B, el error volverá a ocurrir, y está bien aunque solo sea allí.
Todo esto añade caos al código y algún día caerá sobre tu cabeza, probablemente en el momento más inoportuno. Tendrás que reunir tu fuerza de voluntad para obligarte a dedicar tiempo a comprender por qué todo parece funcionar, pero vale la pena.
Tercer nivel de comprensión: ¿Por qué funciona?
Mi reciente percepción se relaciona precisamente con este nivel, y es probablemente el que me habría brindado el mayor beneficio si hubiera llegado a esta idea antes.
Para que quede más claro, veamos 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 para ser compatible con ella necesita usar el marco F. Otros Los módulos que se integran con X funcionan exactamente con él.
Su código no ha tenido ningún contacto con el marco F desde el primer día de su vida, por lo que no será tan fácil implementarlo. Esto tendrá graves consecuencias para algunas partes del módulo. Sin embargo, te lanzas al desarrollo: pasas semanas escribiendo código, probando, implementando versiones piloto, obteniendo comentarios, corrigiendo errores de regresión, descubriendo complicaciones imprevistas, no cumpliendo con los plazos acordados originalmente, escribiendo más código, probando, obteniendo comunicación de comentarios, corregir errores de regresión: todo esto para implementar el marco F.
Y en algún momento, de repente te das cuenta, o tal vez escuchas a alguien, que tal vez el marco F no te brinde compatibilidad en absoluto con la característica X. Quizás todo ese tiempo y esfuerzo se dedicaron completamente mal a eso.
Algo similar sucedió una vez mientras trabajaba en un proyecto del cual era responsable. ¿Por qué pasó esto? Porque tenía poca comprensión de qué era la función X y cómo se relacionaba con el marco F. ¿Qué debería haber hecho? Pídale a la persona que asigna la tarea de desarrollo que explique claramente cómo el curso de acción previsto conduce al resultado deseado, en lugar de simplemente repetir lo que se hizo para otros módulos o confiar en su palabra de que esto es lo que la característica X debe hacer.
La experiencia de este proyecto me enseñó a negarme a comenzar el proceso de desarrollo hasta que tengamos una comprensión clara de por qué se nos pide que hagamos ciertas cosas. Rechace rotundamente. Cuando recibes una tarea, el primer impulso es asumirla inmediatamente para no perder el tiempo. 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 presionarte, obligarte a empezar a trabajar, aunque no entiendas el motivo de ello, resiste. Primero, averigüe por qué se le asigna tal tarea y decida si este es el camino correcto hacia la meta. Tuve que aprender todo esto de la manera más difícil; espero que mi ejemplo haga la vida más fácil a quienes lean esto.
Cuarto nivel de comprensión: ???
Siempre hay más que aprender en programación y creo que solo he arañado la superficie 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 tomó que tuvieron un impacto positivo en la calidad del código y la aplicación? ¿Qué decisiones resultaron equivocadas y le enseñaron una valiosa lección? Comparte tu experiencia en los comentarios.
Fuente: habr.com