Así que comencé a trabajar para un gran grupo, 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 ha enredado 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, en el que he estado y / o he oído hablar.
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 (piense en la perfección de Apple / Steve Jobs). ¿Quizás alguien aquí pueda ayudarme a entender antes de que me despidan?
Aquí está mi proceso de desarrollo y el de mi última puesta en marcha ... muy ágil.
Hacemos el trabajo de las características iniciales para ordenar la tarea de desarrollo / todos. Nos burlaríamos de un par de versiones y las presentaríamos 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 anteriores. Luego dividimos el trabajo y comenzamos. Tenemos hitos y fechas para cumplir, pero seguimos desconectando. No tenemos revisiones de código durante nada de esto. Varias veces durante las semanas de nuestro desarrollo, tenemos sesiones con los interesados nuevamente para ver si aún están de acuerdo en que las características / funciones / UX / UI siguen siendo adecuadas y están en el objetivo.
A medida que nos acercamos al final del ciclo de iteración de 8 semanas, el control de calidad comienza a probar, luego se dirige a los usuarios alfa y finalmente a los usuarios beta. Pero durante la fase alfa y beta, los desarrolladores revisan las nuevas características y las características más antiguas y realizan cambios iterativos diarios u horarios en la interfaz de usuario para mejorar la experiencia de usuario. Por lo tanto, una característica que se estaba desarrollando en esta versión, podría terminar cambiando 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 elegante o más inteligente). A veces, los cambios pueden ser superficiales, lo que significa que no se cambian ni modifican las operaciones CRUD, pero todas las IU solo cambian.
Entonces, con este tipo de proceso de desarrollo, extremadamente ágil, ¿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 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 ya que ese código / componente / UI fue desechado?
Nunca tuvimos muchos problemas de calidad con este proceso y sí, si un desarrollador dejaba todo el conocimiento salía por la puerta, pero siempre encontramos desarrolladores inteligentes para recogerlo y tomar el control.
Y sí, tenemos muchos probadores porque pueden tener que volver a probar cosas 3 o 4 veces. Además, no se obsesione con preguntar por qué cambia toda la UI / UX ... así es como se hacen las cosas ... y por eso la aplicación gana toneladas de premios por UI / UX y los usuarios matarán por aplicación El proceso de pensamiento es si puedo mejorar incluso un 2% en algo porque tengo una hora extra y luego hacerlo. Los usuarios estarán más felices, lo que significa más $ o usuarios. Y sí, nuestros usuarios están de acuerdo con que la aplicación cambie continuamente porque así se ha hecho desde el primer día para que no la vean como mala o negativa.
Espero que esta publicación no sea pomposa, pero 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. En cada versión podemos encontrar 3 errores a través de la revisión de código. ¿Entonces termina 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? Las posibilidades son del 50% de esos 3 a 5 errores habrían sido recogidos por QA de todos modos. ¿No sería mejor pasar esas 40 horas por desarrollador agregando una nueva característica o mejorando las existentes?
fuente
Respuestas:
Hay algunas cosas que las revisiones de código pueden hacer por usted, y algunas cosas que no pueden hacer. Los argumentos a favor de las revisiones de código:
Muchos procesos ágiles los abordan de diferentes maneras:
En esencia, hay otras vías para ocuparse de las ganancias potenciales que normalmente tendría haciendo revisiones por pares. Mi experiencia personal con las 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 en los que no es factible ágil (por cualquier razón), son bastante necesarios.
fuente
¿Las revisiones de código son solo para encontrar errores? Parece que piensas que es verdad y yo no.
Yo diría que las revisiones de código pueden ser más acerca de la propiedad colectiva del código, asegurando que el conocimiento esté en múltiples cabezas y preparando a otros para heredar el código que podría ser para nuevas características y errores. Me gustan las revisiones de código como una forma de controlar y equilibrar un poco 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.
fuente
La programación de pares es la respuesta XP a las revisiones de código. Esencialmente, cada línea de código se revisa a medida que se escribe. Son revisiones de código llevadas al extremo.
fuente
Las revisiones y pruebas de código a menudo no detectan el mismo tipo de errores, y es probable que los errores detectados por la revisión de código sean más fáciles de corregir, ya que se conoce la ubicación del error.
No puede saber si el código está libre de errores solo porque pasa la prueba sin que se haya registrado ninguno. "Las pruebas solo pueden probar la presencia de errores, no la ausencia". (Dijkstra?)
La revisión de código también mantiene el estilo de 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 al hacer las cosas bien en lugar de lo más rápido posible. Es muy posible que prefieras trabajar en startups que en grandes empresas, pero esa no es una razón para intentar imponer estrategias de startup donde no encajan.
fuente
¿Tus revisiones de código solo muestran cambios en la UI / UX? Yo diría que no es una revisión de código, es una prueba de usabilidad. Las revisiones de código tienen mucho más que ver con los problemas que los usuarios / evaluadores / negocios / lo que sea que nunca vean, porque están en el código. La pista está ahí en el nombre.
Ahora estaré de acuerdo con usted en que hay una línea que se trazará en alguna parte. ¿Revisas 4 iteraciones del mismo cambio de UI? ¿O pasas por 4 iteraciones de eso, y cada una de ellas hace que el código sea menos mantenible? 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 desarrolladores examinan cada pieza de código, por lo que dos desarrolladores saben cuál fue el cambio y qué se pretendía lograr. . Entonces, uno de ellos se enferma al día siguiente y está fuera durante una semana, el otro puede recoger cualquier trabajo urgente que estaban haciendo.
fuente
Tiendo a estar de acuerdo en que la propiedad y el emparejamiento de código colectivo junto con TDD y CI son los antídotos ágiles para las sesiones formales de revisión de código.
Incluso bajo UP / Spiral no era un gran admirador de un paso específico del proceso que era la "revisión de código" porque me pareció que los tipos de problemas que probablemente encontrarían se encontrarían más tarde de lo que podrían ser si se invirtiera la misma energía en algún momento inicial colaboración y alguna automatización simple.
Sentí que porque había: - alguna revisión compartida del diseño (generalmente expresada en UML al menos en una pizarra) significaba problemas de diseño a gran escala o un mal uso de las API, etc. antes de que se escribiera mucho código. - FxCop, CheckStyle, FindBugs (o similar) que se ejecutan junto con compilaciones de integración continua automatizada para detectar nombres, estilismo, 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 aguas abajo.
No digo que sea una pérdida de tiempo sentarse y echar un vistazo a su base de código de vez en cuando, pero hacer que la revisión del código sea un paso decisivo para llamar a hacer algo parece que crea mucho trabajo en progreso que podría haber sido evitado con una mejor inspección / colaboración aguas arriba.
fuente
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 deberían ayudar a todos a escribir un código claro que cumpla razonablemente con los buenos estándares de codificación. La mayoría de los códigos requieren mucho mantenimiento, especialmente en grandes empresas. La recuperación de la inversión para el código mantenible debe comenzar antes de que se lance el código, y continuar después.
Las revisiones de código en sí mismas nunca deberían dar lugar a cambios en el código. Si la revisión del código indica que se requieren cambios, la implementación del cambio dará como resultado un cambio en el código.
El estado del código puede cambiar como resultado de la revisión, pero eso debería ser irrelevante para los problemas que menciona.
Si la revisión del código resulta en múltiples cambios de código, entonces algo se rompe en su proceso de desarrollo. Dado el número de probadores que tiene, puede lanzarlo por la pared y dejar que los probadores encuentren la mentalidad del problema.
Las cosas deberían ir a los probadores en estado completo. Se debe automatizar la mayor parte de las pruebas posibles, de modo que los evaluadores no vuelvan a realizar las mismas pruebas una y otra vez.
UI / UX requiere algo de tiempo de prueba, pero contar con expertos en diseño / desarrollo en el front end debería reducir eso. También requiere una cara delante de la pantalla. Sin embargo, en todas las aplicaciones con las que he trabajado, era una porción relativamente pequeña del código.
El costo de implementar cambios (incluidas las correcciones de errores) generalmente aumenta en cada etapa que atraviesa. Encontrar errores en el desarrollo es generalmente más barato que corregirlos después de probarlos.
fuente