Hace poco descubrí una entrevista muy interesante entre Allen Holub y Robert “Uncle Bob” Martin. Quizá el segundo sea más conocido por Clean Code o la saga de libros Clean, pero Allen cuenta con la experiencia necesaria para darle muy buen curso a la conversación con preguntas, acotaciones y puntos de vista que hacen que la media hora pase sin que nos demos cuenta.
En la entrevista se tocan puntos como: – Lo que debemos hacer si nos interesa evolucionar como desarrolladores de software – Libros que deberíamos leer y la importancia de los fundamentos que encontraremos en estos – La práctica hace al maestro, pero podría tomar algo de tiempo – Liderazgo y su impacto en el aprendizaje y productividad del equipo – El trabajo remoto y la necesidad de las interacciones personales – Puedes invertir tiempo enseñando y te irá bien con eso, pero tienes que aceptar que no vas a convencer a todo el equipo – Disciplina, estándares y ética
No entraré en detalles de la importancia de esta práctica, creo que ya es sabido y se tienen muy buenos artículos al respecto, pero yendo del dicho al hecho… ¿qué hacemos?
Aquí una lista de consideraciones a tener en cuenta:
1. Roles claros: El código se escribe (autor), se revisa (revisor) y aunque al principio no parezca, le pertenece a todos (dueño). Además, el autor no puede ser juez y parte de lo que propone, el revisor puede incluir a otro revisor en caso de que alguna revisión/observación se extienda más de la cuenta, y como dueños somos responsables de la calidad del código.
2. Reglas claras: Para no depender de opiniones y gustos, debe existir un checklist y este debe ser de conocimiento –y uso– general. Además hay que aceptar que –salvo posibles excepciones– no hay nada nuevo por inventar (estilos, nomenclatura, estructuras, etc.), así que el equipo debe acordar el conjunto de reglas a seguir (existen muchas, con casos ya comprobados), las excepciones del caso y cómo abordar cada una de estas.
3. Tiempos de entrega: El tiempo de revisión, entrega de feedback y correcciones no debe comprometer los avances del trabajo, pero de darse el caso, debemos ser conscientes y empáticos sobre las consecuencias del volumen de código a revisar. En caso de no haberse conversado, volver al punto 2.
4. Esquema de revisión: Se deben abordar aspectos de arquitectura (¿se cumple con la estructura y/o diseño propuesto?), estilos (¿se respetan los estándares de nomenclatura, formato, programación o pruebas?), legilibilidad (¿se entiende sin tener que preguntar al creador?), ubicuidad (¿se usa el lenguaje y terminologías del producto?), funcionalidad (¿cumple con lo requerido?) y cobertura (¿las pruebas automatizadas incluyen los casos no exitosos?). Aquí es importante tener en cuenta que cada uno de estos esquemas de revisión deben reflejarse de manera explícita en las reglas respetadas por el equipo. Caso contrario, volver al punto 2.
5. Feedback concreto, respetuoso y de atención rápida: Siempre hay que tener presente que por más que uno desee, no todos tenemos el mismo nivel de conocimiento y entendimiento, así que para acortar esa brecha, cada observación debe ser lo más clara posible. Incluir código de ejemplo y observar de manera propositiva ayudan mucho, pero ayuda mucho más proponer una sesión de revisión conjunta.
Antes de hablar, sea para explicar o responder algo, recuerda que no todos experimentaron lo mismo que tú. Y así hayan estudiado o tengan conocimiento de los mismos temas, cada persona tiene su proceso, su forma de entender las cosas y claro, podrías estar equivocado.
Clare Sudbery (she/her) plantea muy bien este tipo de situaciones en The Stupidity Manifesto, el cual por cierto, a pesar de tener un título algo crudo y directo, creo que refleja muy bien el punto al que quiero llegar.
Antes de despedirme les comparto una captura que tomé hace un tiempo en un O’Reilly Live Event, una publicación de Clare y claro, contarles que cada cierto tiempo evalúo situaciones por las que he pasado, reflexiono sobre mi comportamiento y creo que, como es natural, hay cosas en las que debo seguir trabajando.
Si no eres “intenso” o “intensa”, como muchos podrían esperar o incluso alardear, no hay problema con eso, es una posición que se debe respetar pero recuerda que la intensidad implica altos niveles de presión y energía que, como es natural, pueden ir disminuyendo.
Confieso no haber investigado a fondo el asunto y creo además que debería tener más conversaciones al respecto. Pero mientras tanto, comparto la reflexión de que hay situaciones en las que sin darnos cuenta, nos convertimos en nuestro peor enemigo, y que a veces –aunque nos cueste– solo queda pedir ayuda.
En mi caso, y esta también es una confesión, admito haber padecido de más de una de las causas aquí mostradas (por favor, si saben del autor, me avisan para darle los créditos correspondientes) y que las que me han generado mayor inconveniente –y quizá vuelvan a hacerlo, pues soy para nada perfecto– son:
1. Asumir que mis problemas son únicos o que soy el único que los tiene.
2. Quedarme atrapado en el pasado.
Como es natural, creo seguir aprendiendo al respecto y quizá por eso hago esta publicación, no sin esperar nada más que una reflexión de su parte, nada mejor que seguir conociéndonos y estar preparados para ese –para muchos– temido momento.
Jersson on the block 2.0 