¿Las revisiones de código realmente funcionan en Agile verdadero?

13

Así que empecé a trabajar para un gran cuerpo, uno de esos con 3 letras en el nombre, y están tratando de volverse ágiles, pero tienen toneladas de procesos, que no creo que sean ágiles.

El que más me tiene herido son las revisiones de código. Mi último trabajo fue con una startup que diría que es el equipo de desarrollo más ágil que he visto, estado y / o escuchado.

De todos modos, mi argumento es que las revisiones de código son una pérdida de tiempo en el desarrollo iterativo o ágil donde la UX / UI es extrema / intensa (creo que la perfección de Apple / Steve Jobs). Tal vez alguien aquí pueda ayudar a entender antes de despedirme?

Aquí está mi proceso de desarrollo y el de mi último inicio ... muy ágil.

Realizamos el primer trabajo de características para clasificar la tarea de desarrollo / todos. Nos gustaría burlarnos de un par de versiones y presentarlas a los usuarios, al equipo y al marketing para obtener comentarios. Luego hacemos otra iteración de maqueta para obtener una ronda de los mismos interesados mencionados anteriormente. Luego repartimos el trabajo y comenzamos. Tenemos hitos y fechas que cumplir, pero seguimos conectándonos. No tenemos revisiones de código durante nada de esto. Varias veces durante las semanas de nuestro desarrollo, celebramos sesiones con las partes interesadas de nuevo para ver si aún están de acuerdo en que las funciones / funciones / UX / UI siguen siendo un ajuste adecuado.

A medida que nos acercamos al final del ciclo de iteración de 8 semanas, el control de calidad comienza a probarse, luego va a los usuarios alfa y finalmente a los usuarios beta. Pero durante el alfa y beta, los desarrolladores están revisando las nuevas características y las características más antiguas, haciendo cambios iterativos diarios o de hora en la interfaz de usuario para mejorar la UX. Por lo tanto, una característica que se estaba desarrollando en esta versión podría terminar siendo cambiada 3 veces más en las últimas cuatro semanas para mejorarla y perfeccionarla o agregar algunas características pequeñas (por ejemplo, hacer que el componente sea un poco más pulido o más inteligente). A veces, los cambios pueden ser superficiales, lo que significa que no se modifican ni modifican las operaciones CRUD, pero solo cambia la interfaz de usuario.

Entonces, con este tipo de proceso de desarrollo, Agile extremo, ¿las revisiones de código no serían una pérdida de tiempo? Lo que significa que si otro desarrollador o dos revisaron mi código, pero luego ese código cambia 3 veces más antes de que salga por la puerta, debido a todas las mejoras de UI / UX, ¿no estamos perdiendo el tiempo las primeras 3 veces que lo revisaron? código como ese código / componente / UI fue desechado?

Nunca tuvimos muchos problemas de calidad con este proceso y sí, si un desarrollador dejó todo el conocimiento salió, pero siempre encontramos desarrolladores inteligentes que lo recogen y lo toman.

Y sí, tenemos muchos evaluadores porque es posible que tengan que volver a realizar las pruebas 3 o 4 veces. También, por favor, no se preocupe por preguntar por qué todos los cambios de UI / UX ... así es como se hacen las cosas ... por eso la aplicación gana toneladas de premios por UI / UX y los usuarios matarán por el la aplicación El proceso de pensamiento es si puedo lograr una mejora de hasta un 2% en algo porque tengo una hora extra y luego lo hago. Los usuarios serán más felices, lo que significa más $ o usuarios. Y sí, nuestros usuarios están de acuerdo con el cambio continuo de la aplicación porque así se ha hecho desde el primer día, por lo que no lo ven como algo malo o negativo.

Espero que esta publicación no parezca pomposa, pero simplemente no puedo ver cómo las Revisiones de Código no son un desperdicio. Tal vez el 2% de todo nuestro código en el código revisado tiene errores. Cada versión podríamos encontrar 3 errores a través de la revisión de código. Entonces, ¿terminan siendo 40 horas de revisión de código por desarrollador por lanzamiento (4 x 40 = 160 horas) para encontrar de 3 a 5 errores? Es probable que el 50% de los errores de 3 a 5 hayan sido recogidos por QA. ¿No sería mejor pasar esas 40 horas por desarrollador agregando una nueva función o mejorando las existentes?

    
pregunta user25702 19.05.2011 - 22:19

7 respuestas

13

Hay algunas cosas que las revisiones de código pueden hacer por usted, y otras no. Los argumentos en favor de las revisiones de código:

  • propiedad colectiva
  • Buscar errores (QC)
  • Aplicar estilo consistente (QA)
  • tutoría

Muchos procesos ágiles los abordan de diferentes maneras:

  • Propiedad colectiva: todos los miembros del equipo son responsables del proyecto, lo que significa que los ojos de todos estarán en el código en un momento dado.
  • Free to refactor: esto lleva las revisiones de código al siguiente nivel y permite que cualquier persona del equipo realice la refactorización según sea necesario.
  • Pruebas unitarias (QC): las pruebas unitarias son más eficientes y menos propensas a errores humanos que la inspección visual. De hecho, todavía tengo que encontrar un medio más eficiente.
  • Programación de pares (QA): se encarga de la mentoría y brinda consejos de refactorización temprana a medida que se escribe el código. Este tema también sigue siendo controvertido, pero me parece que ayuda a la vez que aumenta la capacidad de un nuevo desarrollador. También es un buen momento para hacer cumplir los estándares de codificación.

En esencia, hay otras formas de cuidar las ganancias potenciales que normalmente tendría al realizar revisiones por pares. Mi experiencia personal con revisiones por pares es que son mecanismos muy ineficientes y no son efectivos para encontrar errores o fallas de diseño más grandes. Sin embargo, tienen su lugar en algunos equipos, y en proyectos donde ágil no es factible (por cualquier razón), son muy necesarios.

    
respondido por el Berin Loritsch 19.05.2011 - 22:43
11

¿Las revisiones de código son solo para encontrar errores? Parece que piensas que eso es verdad y yo no.

Argumentaría que las revisiones de códigos pueden ser más acerca de la propiedad colectiva del código, asegurando que el conocimiento esté en múltiples direcciones y preparando a otros para heredar el código, que podría ser tanto para nuevas características como para errores. Me gustan las revisiones de código como una forma de revisar y equilibrar el sistema, ya que nunca se sabe cuándo alguien puede tener una idea de dónde se puede volver a escribir algo para mantener las convenciones.

    
respondido por el JB King 19.05.2011 - 22:27
4

La programación de pares es la respuesta de XP a las revisiones de código. Esencialmente, cada línea de código se revisa a medida que se escribe. Es revisiones de código llevadas al extremo.

    
respondido por el Dave 19.05.2011 - 22:25
4

Las revisiones y pruebas de código a menudo no detectan el mismo tipo de errores, y los errores detectados por la revisión de código probablemente sean más fáciles de solucionar, ya que se conoce la ubicación del error.

No se puede saber si el código está libre de errores solo porque pasa las pruebas y no se registra ninguna. "Las pruebas solo pueden probar la presencia de errores, no la ausencia". (Dijkstra?)

La revisión de código también mantiene el estilo del código igual, y es capaz de encontrar lugares donde el código no es bueno pero funciona por ahora. Ahorra costos de mantenimiento en el futuro.

Además, las demandas de una gran corporación y una startup son diferentes. Las startups normalmente fallan, y tienen que moverse rápido. Las grandes corporaciones obtienen mucho más valor de hacer las cosas bien en lugar de hacerlo lo más rápido posible. Es posible que prefieras trabajar en empresas nuevas que en empresas grandes, pero esa no es una razón para tratar de imponer estrategias de empresas donde no encajan.

    
respondido por el David Thornley 19.05.2011 - 22:56
2

¿Las revisiones de su código solo muestran cambios en UI / UX? Yo diría que eso no es una revisión de código, es una prueba de usabilidad. Las revisiones de código son mucho más acerca de los problemas que los usuarios / verificadores / negocios / lo que nunca ven, porque están en el código. La pista está ahí en el nombre.

Ahora estaré de acuerdo contigo en que hay una línea para dibujar en algún lugar. ¿Revisa 4 iteraciones del mismo cambio de interfaz de usuario? ¿O pasa por 4 iteraciones de eso, y cada una de ellas hace que el código sea menos fácil de mantener? Diría que intente medir ambos enfoques y encuentre el equilibrio adecuado para su equipo, pero no abandone las revisiones de código por completo.

Incluso si una revisión de código nunca presenta un problema, tiene un beneficio que rara vez se nota hasta que no está allí: dos programadores analizan cada pieza de código, por lo que dos desarrolladores saben cuál fue el cambio y qué fue. destinado a lograr. Así que uno de ellos se enferma al día siguiente y se va por una semana, el otro puede recoger cualquier trabajo urgente que estuvieran haciendo.

    
respondido por el pdr 19.05.2011 - 22:37
1

Tiendo a estar de acuerdo en que la propiedad colectiva del código y el emparejamiento junto con TDD y CI son los antídotos ágiles para las sesiones formales de revisión de código.

Incluso en UP / Spiral no era un gran fanático de un paso de proceso específico como "revisión de código" porque me parece el tipo de problemas que probablemente encuentre más tarde de lo que podría ser si la misma energía fuera invertida En alguna colaboración inicial y alguna automatización simple.

Sentí eso porque había: - alguna revisión compartida del diseño (generalmente expresada en UML al menos en una pizarra) significó problemas de diseño a gran escala o un uso deficiente de las API, etc., antes de que se escriba mucho código. - FxCop, CheckStyle, FindBugs (o similar) ejecutándose junto con compilaciones de integración continua automatizadas para capturar nombres, estilo, visibilidad, duplicación de código, etc.

Pudimos fallar antes y obtener comentarios más rápido de lo que hubiera producido un hábito de revisión de código descendente.

No estoy diciendo que es una pérdida de tiempo sentarte y echar un vistazo a tu base de código de vez en cuando, pero hacer que la revisión del código sea un paso de enlace para llamar a algo hecho parece que crea mucho trabajo en progreso podría haberse evitado con una mejor inspección / colaboración en la fase inicial.

    
respondido por el mmeyer 20.05.2011 - 00:26
0

Uno de los objetivos principales que espero de las revisiones de código es aumentar la facilidad de mantenimiento del código. Las revisiones de código deben ayudar a todos a escribir un código claro que cumpla razonablemente con los buenos estándares de codificación. La mayoría del código recibe mucho mantenimiento, especialmente en las grandes empresas. El reembolso por el código que se puede mantener debe comenzar antes de que se publique el código y continuar después.

Las revisiones de código en sí mismas nunca deben generar cambios en el código. Si la revisión del código indica que se requieren cambios, la implementación del cambio resultará en un cambio en el código.

El estado del código puede cambiar como resultado de la revisión, pero eso debería ser mayormente irrelevante para los problemas que menciona.

Si la revisión del código está dando lugar a múltiples cambios de código, entonces algo se rompe en su proceso de desarrollo. Dada la cantidad de evaluadores que tiene, puede haber un tiro en la pared y dejar que los evaluadores encuentren la mentalidad del problema.

Las cosas deberían ir a los evaluadores en estado completo. La mayor parte posible de las pruebas debería ser automatizada, para que los evaluadores no vuelvan a realizar las mismas pruebas una y otra vez.

UI / UX requiere cierto tiempo de prueba, pero contar con expertos en diseño / desarrollo en la parte delantera debería reducirlo. También requiere una cara delante de la pantalla. Sin embargo, en todas las aplicaciones con las que he trabajado, era una parte relativamente pequeña del código.

El costo de implementar cambios (incluidas las correcciones de errores) generalmente aumenta en cada etapa por la que pasa. En general, encontrar errores en el desarrollo es más barato que solucionarlos luego de las pruebas, encontrarlos.

    
respondido por el BillThor 19.05.2011 - 22:45

Lea otras preguntas en las etiquetas