Digamos que uno trabaja en una compañía hipotética que tiene varios desarrolladores que rara vez trabajaron juntos en proyectos y el Jefe no creía que las revisiones de código valieran el tiempo y el costo.
¿Cuáles son los diversos argumentos que podrían presentarse en este escenario que retratarán el beneficio de la revisión de código? Además, ¿cuáles son los posibles argumentos en contra de la revisión del código aquí y cómo se pueden contrarrestar?
Respuestas:
Si tiene que justificarse para cosas tan básicas, tiene un problema mayor.
Usted es el experto, su equipo debe decidir qué prácticas usa. Tal vez deberías comenzar a convencer a tu jefe de ese principio tan importante.
Se supone que su jefe debe decidir QUÉ hacer y, lo que es más importante, POR QUÉ hacerlo. Debes cuidar el CÓMO construirlo
(eso no significa que no pueda sugerir qué y por qué hacer las cosas en su empresa, por supuesto). Un gran jefe debe alentar a sus empleados a participar en la estrategia empresarial)
Sin embargo, así es como veo las revisiones de código de pares:
Debido a que la programación es un trabajo intelectual muy intenso, una persona no puede garantizar que todo sea perfecto. Por lo tanto, la revisión del código asegura que:
Todos están obteniendo beneficios directos:
La revisión de código puede familiarizar a varios desarrolladores con el mismo código. Ésto es una cosa buena. ¿Qué pasa si el autor original decide renunciar o algo peor? Le sucede algo malo. Si las revisiones de código se realizan regularmente, otros pueden hacerse cargo rápidamente.
Los pares pueden detectar posibles errores o problemas de rendimiento durante la revisión del código. Esto reduce el control de calidad y el esfuerzo de desarrollo. Esto puede compensar el costo adicional involucrado en las revisiones de código.
Las revisiones de código promueven el intercambio de conocimientos. Los compañeros pueden contar formas mejores o formas alternativas de hacer cosas. Yo mismo he aprendido mucho de mis compañeros a través de revisiones de código.
Las revisiones de código ayudan a reforzar las pautas de codificación seguidas por el equipo. Si el equipo no tiene uno, eso debe ser rectificado. El código debe escribirse una vez y leerse muchas veces. Las pautas de codificación son un paso hacia el código legible. El código debe ser legible por los pares. ¿Qué mejor manera que tener revisiones de código para garantizar la legibilidad?
Muchas respuestas geniales aquí. Algunas cosas que agregaría:
Cuando tiene que explicar el código a otra persona, a menudo en el curso de la explicación, el desarrollador puede darse cuenta de repente de que tiene un error. He visto que sucede una y otra vez que el desarrollador se detiene en seco y dice "oh, espera, eso está mal" antes de que el revisor haya entendido la cosa lo suficientemente bien como para ver el error.
Saber que su código será inspeccionado por otra persona le da más incentivos para usar estándares de codificación (lo que facilita el mantenimiento) o usar menos métodos "vaqueros" que nadie más que usted (y a veces ni siquiera usted) entenderá. No quiere avergonzarse cuando muestra su código a otra persona, por lo que, en primer lugar, lo hace mejor. Debido al factor de vergüenza, deja menos comentarios del código con: "No sé por qué esto funciona, pero no te metas con eso". en la base del código.
Los desarrolladores que tienen la necesidad de una supervisión o capacitación más extensa se identifican fácilmente. También lo son los incompetentes. Cuanto antes pueda encontrar y abordar los problemas de rendimiento, mejor será el equipo en su conjunto y mayor será la calidad de la aplicación. Es bueno averiguar esta información antes de tomar al nuevo tipo que necesita capacitación y asignarlo a la parte más difícil y crítica de su aplicación.
A veces es solo una cuestión de corregir una percepción errónea que ahorrará cometer el mismo error en muchos otros lugares. Por ejemplo, recientemente estábamos revisando algunos SQL para obtener informes complejos y descubrimos que varios de nuestros nuevos desarrolladores tenían el mismo malentendido sobre dónde encontrar una información específica en la base de datos (es cierto que el lugar que eligieron parecía lógico, que es un problema de diseño de la base de datos). también es necesario corregirlo) que sería crítico para escribir correctamente todos los informes. Al encontrar el problema y corregirlo en los primeros informes que escribieron, evitó que ocurriera el mismo error en el resto de los informes. Y algo a lo que los desarrolladores mayores (en el tiempo trabajando aquí, no a la edad) estaban tan acostumbrados que no pensaron que fuera necesario explicarlo salió a la luz.
Los juniors pueden aprender del código más sofisticado escrito por seniors (que tienden a comprender mejor la captura de errores y los casos límite, por ejemplo) y los seniors pueden aprender de las nuevas técnicas utilizadas por juniors a las que aún no han estado expuestos.
A veces, las personas que trabajan en partes diferentes pero relacionadas de la aplicación se dan cuenta de que van en dos direcciones diferentes y mutuamente excluyentes. Vaya, más fácil de arreglar ahora.
No es tan fácil colarse en valores codificados que cambiarán con el tiempo solo para que funcione. Esto evita muchos errores futuros, como cosas que cambian al comienzo de cada año fiscal.
A veces me he quedado atrapado en cómo hacer algo y aprendí una nueva técnica que era justo lo que quería al revisar el código de las cosas de otra persona.
Si está familiarizado con la forma en que piensan los otros miembros de su equipo (qué revisión de código le ayudará a comprenderlo), será más fácil resolver los problemas más adelante porque comenzará a comprender cómo Joe se habría acercado a ese tipo de problema.
Además del intercambio de conocimientos mencionado por los demás, encuentre ejemplos de errores que se habrían encontrado durante una revisión del código y mida cuánto tiempo tardaron en solucionarlo; esto incluye el tiempo dedicado a investigar el problema y liberar la versión parcheada, así como Tiempo real arreglando el error.
Tome este costo, que probablemente será un esfuerzo de al menos un par de días, y compárelo con el tiempo que habría dedicado a una revisión del código y a actuar según los resultados.
Esto le mostrará a su jefe que las revisiones de código valen la pena.
Las revisiones de código pueden:
Contras
Si eso es cierto, entonces, ¿cómo es que siempre parece que tenemos tiempo para hacer las cosas dos o tres veces por el mismo cliente, pero nunca tenemos suficiente tiempo para hacerlo bien la primera vez?
Si necesita hacer referencia a un documento, entonces no buscaría más que el estimado "Código completo". En él, el libro describe cuántos errores se detectan con las pruebas unitarias en comparación con la revisión por pares. Es asombroso Las pruebas unitarias, si la memoria me sirve, solo detectan ~ 30% de todos los errores, mientras que las revisiones formales de pares detectan ~ 70%.
Toma esa información, muéstrala en el libro y apela a su lado financiero. Lleva mucho más tiempo y es mucho más costoso dejar pasar los errores que atraparlos temprano.
¿Qué tal si ejecutamos una demostración (un proyecto tipo "mickey mouse" de una semana) ejecutada en paralelo por dos equipos, uno con revisión de código y el otro no.
Al final de la semana, evalúe la calidad del trabajo de cada equipo, estoy bastante seguro de que los revisores del código saldrán como mejores.
De Construx de Steve McConnell Business Case El software para mejores prácticas y fruta de software de desarrollo de software que cuelgan bajo la dirección (LHF) esto. De este último "LHF que no será resistido por la alta gerencia" enumera las inspecciones.
Al presentarlo, concéntrese en la imagen más grande.
Enumere los beneficios (mejor código, menos errores, menos reescrituras, etc.) y mencione la revisión del código como una de las técnicas que recomendaría.
Lo haría parte de una imagen más amplia de la artesanía de software
Esté preparado para hacer mucho trabajo usted mismo en la promoción de estos principios.
Más que nada, no esperes que la persuasión sea algo de "una reunión y hecho".
Debe construir el caso con el tiempo con calma y coherencia. Cuando le molestan más los errores que se habrían solucionado con mejores técnicas, a menudo es el peor momento para presentar su caso, ya que es más probable que sea demasiado emocional y menos racional. Esto puede parecer algo contraintuitivo, pero es lo que he aprendido durante más de 30 años de programación. Obviamente ymmv.