code-reviews – Formas de explicar el código cuando se le dice que no tiene sentido

Pregunta:

Como programador, he descubierto que mi código provoca con frecuencia la reacción "No entiendo". Siempre que obtengo esta respuesta, hago todo lo posible por explicar mi código con paciencia y no hacer que nadie sienta miedo de hacer preguntas.

Estoy bastante seguro de que entendí bien la segunda parte, ¡la gente ciertamente no tiene miedo de hacer preguntas sobre mi código!

Sin embargo, tengo buenas razones para creer que mis explicaciones no son efectivas. Habitualmente tengo discusiones de una hora para tratar de explicar mi código, y en muchas ocasiones las conversaciones terminan con mi compañero de trabajo diciendo que todavía no entienden, pero que tienen que estar en otro lugar (almuerzo, casa, reunión, etc.) .

Creo que esto es un problema con mi código, ya que no puedo recordar la última vez que el código de otra persona tomó una hora de explicación para entenderlo. Además, rara vez veo a mis compañeros de trabajo dedicar tanto tiempo a explicarse su código entre sí.

Específicamente, cuando se me plantea la pregunta "No entiendo su código", ¿cuáles son algunas de las estrategias que puedo utilizar para explicar mi código?

Anteriormente he empleado las siguientes preguntas de seguimiento y estoy buscando mejores, o al menos más, preguntas de seguimiento:

  • ¿Qué parte específicamente parece ser confusa?
    • A veces esto funciona, pero a menudo la respuesta es "todo". He estado en reuniones con otros 5 programadores, donde todos los programadores estuvieron de acuerdo en que no entendían mi código, pero ninguno de ellos pudo dar partes específicas que fueran confusas.
  • ¿Está familiarizado con el patrón "X"?
    • He intentado aprender los nombres de los patrones de codificación que suelo usar. Mencionaré estos nombres, como "el patrón de visitante", y les preguntaré si están familiarizados con este patrón. Si están familiarizados con él, trato de mostrarles cómo mi código es una implementación de ese patrón. Esto parece evitar que hagan más preguntas inmediatamente, pero invariablemente parece que volvemos al mismo código, por lo que me temo que si bien comprenden completamente el patrón, la conexión entre el patrón y mi código no es obvia.
  • ¿Cuáles son algunas de las soluciones al problema "X"?
    • A veces trato de hacer que se comprometan activamente con la solución del problema general, con la esperanza de que si explican cómo lo resolverían, pueda mostrarles los paralelismos entre su solución y la mía. Esto funciona, sin embargo, muchas veces el problema es demasiado complicado para resolverlo mentalmente, por lo que no pueden describir rápidamente cómo lo resolverían.

INFORMACIÓN ADICIONAL:

El código en el que trabajo con más frecuencia es el código de estructura / arquitectura, a menudo código heredado con el que nadie está familiarizado actualmente en la empresa. Mi equipo está muy ocupado y, aunque son pacientes, honestamente no tienen tiempo para ayudarme a trabajar con el código heredado. Como resultado, mi enfoque ha sido entenderlo completamente yo mismo y luego tratar de explicárselo a mi equipo durante las reuniones del equipo.

Sin embargo, estarán interactuando con él e interactuarán con el código existente a diario.

Un ejemplo de este tipo de código sería nuestra canalización de registros, que toma errores del navegador, errores del servidor, errores del servicio, registros http, registros javascript, registros web y une correctamente el tiempo con la información de la sesión, siguiendo unos pocos pasos antes de que los datos terminen finalmente. en splunk. No es exactamente complicado, pero tampoco es exactamente trivial, ya que los servidores necesitaban manejar decenas de millones de registros por día, sin ningún impacto significativo en el rendimiento del servidor (nuestros servidores ya son más caros que mi salario anual).


MUESTRAS DE CÓDIGO

(Disculpe el volcado de texto. Traté de ser breve, pero las muestras de código parecen ser la mejor manera de demostrar mi problema).

Reuní una muestra de código de una pieza de código que parecía confundir más a mis compañeros de equipo. Ya no trabajo en la empresa, por lo que no es el código exacto, y el código exacto se eliminó de todos modos (confundió a todos, por lo que todos acordamos que nadie debería usarlo).

Un poco de historia, nuestra empresa estaba comenzando una reescritura importante, convirtiéndose de un marco heredado a React / Typecript / Redux. Lamentamos haber usado Redux, pero debido a las restricciones de soporte de nuestro navegador, no pudimos usar Mobx. Como resultado, estábamos usando Redux mal, tratando de hacerlo funcionar como Mobx o KnockoutJS. La mayoría de nuestros reductores establecen un estado simple, y la persona que llama sabe exactamente lo que quiere configurar (no cómo deberían funcionar las acciones / reductores de Redux). Sin embargo, debido a limitaciones de tiempo, simplemente no pudimos cambiar de marco y tuvimos que hacer que Redux funcionara. Eso fue hace al menos 3-4 años, y me sorprendería si el equipo todavía estuviera usando Redux ahora.

(Me he vinculado al campo de juego de Typescript para mi código, ya que es un poco largo para una pregunta)

Puede encontrar un ejemplo de código existente aquí: código original

Me opongo a este estilo, ya que, aunque está claro, requiere cambiar 4 piezas de código (repartidas en 3 archivos diferentes) para agregar una variable. Los pasos para agregar nuevas variables son: actualizar la definición de state , agregar una nueva action , agregar a la actions union y agregar un reducer handler .

Hice una clase de constructor (un término que puede que no esté usando correctamente, básicamente es como yargs, https://www.npmjs.com/package/yargs , donde haces una serie de llamadas a funciones encadenadas para crear un objeto más complejo ) que permite agregar propiedades a un solo lugar, conservando los tipos de todo.

(Esto fue antes de los tipos mapeados de TypeScript, que proporciona alternativas al enfoque del constructor).

Se puede encontrar una recreación de mi código propuesto: código cambiado

Respuesta:

Aislada

El código de infraestructura y marco es complicado. Son las partes oscuras y desordenadas de la base del código las que golpean las paredes reales, y la peor parte es que a menudo las soluciones son contrarias a la intuición, ya que tienen que trabajar en torno al usuario (también conocido como programador), las decisiones de idioma y las idiosincrasias de la plataforma. .

Lo que ha sucedido es que te has convertido en un experto y te has quedado encerrado de forma eficaz.

La peor parte es que este tipo de código no tiene un límite efectivo entre su código y el código de los usuarios.

Hay algunas formas de lidiar con esta situación.

Comparte el dolor

Nada genera más conocimiento que tener que palear el S # * T usted mismo.

No todos los miembros del equipo estarán a cargo del trabajo de infraestructura / marco, pero habrá algunos. La mejor manera de comenzar a distribuir conocimiento es hacer que estos desarrolladores trabajen en áreas pequeñas de la infraestructura / marco.

Por supuesto, mantenga la supervisión (después de todo, es fundamental), pero debe comenzar a hacer que los otros desarrolladores piensen más allá de la frontera del silo.

Hacer cumplir la frontera

Si por una razón u otra no se puede derribar el silo. La otra estrategia es hacer cumplir mejores límites entre su código y su código.

Esto se puede hacer de varias formas.

  • Inserte código en bibliotecas y, mientras lo hace, estabilice y documente la interfaz.
  • Institute Idioms. Los modismos se recuerdan fácilmente y pueden simplificar enormemente una implementación compleja a una historia simple desde la perspectiva de los usuarios.
  • Documentación. Si va a explicarlo más de una vez, es mejor capturarlo para referencia futura. Mejor aún, si puede multimedia con una grabación de su voz / presentándolo / gráficos / imágenes, o puede vincularlo a la fuente misma de alguna manera.
  • Deja de explicar. No es su trabajo describir los matices de los sistemas a todos los que preguntan. Si lo fuera, sería un escritor técnico, no un desarrollador de software. El conocimiento que no se ganó con esfuerzo, no se aprende. No malgastes tus esfuerzos.
  • Empuje la implementación fuera del marco hacia el espacio del usuario. Si lo están buscando mucho para entenderlo, están tratando de alterarlo, ergo, está cambiando y en la capa de corte incorrecta en la pila de tecnología. Proporcione una interfaz de complemento para él (como un patrón de estrategia) y un valor predeterminado si otros lo necesitan en el marco.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım