Nueva publicación solicitada de StackOverflow:
Estoy trabajando en un pequeño tiempo de desarrollo con un tiempo muy limitado para el desarrollo. Desarrollamos una herramienta que es importante para el resultado de nuestro trabajo, pero que no se usa a diario. Soy la única persona en el equipo que tiene experiencia como programador.
Mi problema es que he estado presionando para que se revisen los códigos antes de volver a unirme a la troncal durante más de un año. Todos estuvieron de acuerdo en esto, pero aún así solo se revisó mi código. Al regresar de unas largas vacaciones, vuelvo a un baúl con comentarios de código como "esta es una solución fea, elimine lo antes posible" y "solución rápida". Lo que también es nuevo es que un hombre ha sido nombrado responsable de la herramienta. (Un papel que primero me ofrecieron pero que rechacé debido a una razón no relacionada con el trabajo). Y él piensa que esta es una buena manera de trabajar: como tenemos un tiempo tan limitado para desarrollarnos, deberíamos cortar esquinas así.
Mi preocupación es que los otros desarrolladores escriban código feo: a menudo rompen la encapsulación, escriben clases enormes, agregan clases internas en lugares extraños, tienen pocas o ninguna prueba unitaria, y así sucesivamente. Eventualmente será imposible desarrollar más la herramienta.
¿Debo insistir en que realicemos revisiones de código antes de volver a fusionarnos a la troncal o solo soy una perra de calidad de código?
fuente
Respuestas:
He estado en situaciones similares antes y, en mi humilde opinión, depende de "tengo que mantener el código".
Si tengo que mantener el código, de lo que quiero un código de alta calidad, personalmente no necesito revisiones de código para cada confirmación (es decir, los programadores pueden decidir por sí mismos si cierto código necesita una revisión o no) pero si la legibilidad / mantenibilidad sufre más de Puede estar en orden.
Al leer esto:
Creo que su problema es mayor que solo las revisiones de código. Parece que le faltan algunas pautas y / o no se implementan. No tener / pocas pruebas unitarias puede ser una mala idea, pero depende del caso específico. Sin embargo,
breaking encapsulation, writing huge classes, ...realmente cree un código propenso a errores, de modo que definitivamente debería repararse.fuente
Creo que las revisiones de códigos y el mantenimiento de algunas pautas de codificación es una buena idea, pero creo que hacerlo para cada registro es una pérdida de tiempo. Es una buena idea establecer un equipo y con programadores jóvenes, pero los programadores experimentados pueden pensar por sí mismos y eventualmente tendrá que confiar en ellos. Dicho esto, puede hacer revisiones periódicas del código para actualizarlo, pero mirar todas y cada una de las líneas de código que ingresa a su VCS realmente lo está exagerando.
Y un pequeño comentario sobre las soluciones de su colega: algunas veces hacer una solución fea es la solución correcta . Puede ser que este código en particular no sea lo suficientemente importante como para invertir mucho tiempo, puede ser que la solución simple sea lo suficientemente buena y es mejor invertir tiempo en otras cosas. Hacer que su código sea "bonito" no es su objetivo principal como programador. Su objetivo principal es entregar y obsesionarse en cada línea de código simplemente no lo llevará allí.
Lo que intento decir es que debes elegir tus batallas. Está bien perder la batalla sobre alguna clase de utilidad insignificante para ganar la guerra de entrega (o esta guerra de subsistema REALMENTE IMPORTANTE, para el caso).
fuente
Si el programa en cuestión no es un prototipo descartable, creo que las revisiones de código deberían ser obligatorias para cada check-in.
Los desarrolladores senior podrían tener el privilegio de los registros no revisados, una vez que sean lo suficientemente conscientes como para solicitar una revisión cuando sea apropiado.
fuente
No estoy seguro de que la revisión del código sea la respuesta hasta que alguien comience a aplicar mejores estándares de codificación. Alguien escribe un código malo, lo comenta / lo admite y lo registra de todos modos. ¿De qué sirve una revisión si alguien quiere rechazar el código, pero lo retrasará?
Necesitará: establecer estándares, supervisar a los principales culpables más de cerca y recordarles que un buen código no siempre lleva más tiempo escribir. Deben dejar de usar líneas de tiempo como excusa para negarse a cambiar los malos hábitos.
fuente