¿Son necesarias las revisiones de código para desarrolladores junior?

He trabajado en dos compañías, cada una con una metodología diferente en lo que respecta a las revisiones de código:

En la primera compañía, los líderes del equipo llevaron a cabo una revisión del código, que fue necesaria después de completar cada módulo.

Sin embargo, en la segunda compañía, los líderes de los equipos no estaban obligados a realizar ninguna revisión de código, y solo verificaron la funcionalidad y los problemas de diseño.

Entonces estoy confundido. ¿Es realmente necesario el proceso de revisión del código? Si es así, ¿por qué? Y si no es así, ¿por qué no?

Personalmente, creo que cada código debe pasar por una revisión de código, no importa si usted es desarrollador junior o senior.

¿Por qué? Para empezar, su título no indica nada sobre cómo se desarrolla, y un desarrollador senior podría aprender algo del junior. En nuestra compañía cambiamos de lugar para que uno de los otros miembros del equipo revise su código ... en su mayoría nos unen "junior" y un senior juntos, por lo que todo lo que no se dice a diario puede ser atrapado en un seguimiento. Si al senior no le gusta el código junior, debería escuchar por qué el junior hizo lo que hizo y mirarlo y ver si esa es una solución factible que podría usarse en el futuro ... es cuestión de ser más sabio, no importa quien eres.

Una cosa importante sobre la revisión de código es no ser demasiado amable, si eres un buen tipo, solo permitirás que más y más código desordenado evolucione en el sistema. Justo como ayer comencé a reelaborar una aplicación completa que escribió un antiguo desarrollador junior empleado, y Dios mío, ese código podría haber necesitado una revisión antes de irse.

No veo por qué debería ser el líder del equipo el que solo realiza las revisiones, pero requiere una persona que no tenga miedo de elegir una "pelea" por un fragmento de código mal desarrollado, y tiene que ser una persona que se preocupe por cómo debería el código ser. No todas las empresas contratan a personas que realmente se preocupan por lo que hacen, y esos huevos malos no deberían tener en cuenta la OMI para hacer revisiones de código, ya que es probable que solo se encojan de hombros y digan "OK" al código malo.

Básicamente, la revisión del código es necesaria para todos los programadores, independientemente de su experiencia. Es el control de calidad del desarrollo de software, y una de las razones por las que Open Source puede ser de muy alta calidad.

EDITAR: la razón es que un revisor de código hoy tiene exactamente el mismo rol que un mantenedor más adelante. Si el código no tiene sentido para él hoy, tampoco tendrá sentido más tarde, haciendo que los errores sean más caros de corregir. Por lo tanto, HAZLO comprensible hoy mientras el desarrollador todavía recuerda el código. Además, el revisor puede ver errores u omisiones que el desarrollador no detectó.

Lamentablemente, muy pocos quieren hacerlo, pero visto desde el punto de vista comercial, debería ser obligatorio.

Trabajo en un lugar donde la revisión del código ahora es un requisito, pero no hace tan solo 3 años. Se ha realizado una gran mejora en nuestro código y en la capacidad de otros para mantener el código más adelante. Incluso los desarrolladores senior con mucha experiencia cometen errores que pueden repararse fácil y silenciosamente en la revisión de código antes de que el control de calidad los encuentre o peor aún antes de que el cliente los encuentre. Además, al menos una persona que no sea el desarrollador original está familiarizada con el código.

A menudo, cuando una organización intenta algo nuevo, como lo hicimos con la revisión del código, hay mucha resistencia al cambio. No he visto casi nada de eso (estábamos seguros de obtener un departamento de control de calidad formal también) con la revisión del código. Basta con una o dos revisiones para ver el valor.

Encontré nuevas técnicas que no había considerado al hacer una revisión del código del trabajo de otra persona o al revisar mi código. Hemos encontrado problemas de competencia con las nuevas contrataciones relativamente rápido al tener revisiones de código y, lo que es más importante, por cómo respondieron a la revisión de código. Hemos aprendido qué cosas que parecen perfectamente claras en este momento en el grueso de la programación de esa sección que no serán claras en el mantenimiento. Esto es invaluable. Puede ser que lo único que se necesita es un comentario sobre por qué se hizo algo. Hemos encontrado algunos malentendidos fundamentales sobre el diseño de nuestra base de datos que deben corregirse para que un informe tenga la información correcta.

A menudo, lo que he visto en una revisión de código es que, por el simple hecho de explicarle algo a otra persona, el desarrollador tendrá una bombilla encendida en su cabeza y se dará cuenta de que hay un error que el revisor no vio.

Y la revisión de código puede identificar a aquellos programadores de vaqueros que no seguirán ninguna norma o usarán herramientas obligatorias y cuyo código será casi imposible de mantener por cualquier otra persona. Y puede obligarlos a seguir con el programa o salir también.

Las personas más resistentes a la revisión de código son a menudo las personas de las que la organización más necesita deshacerse porque saben en su corazón que su código no puede pasar una revisión de código.

El tipo ágil diría: "No necesita una revisión de código, solo programe pares y escriba buenas pruebas" :)

La revisión de código es una buena forma de difundir el conocimiento y las buenas prácticas a través de un equipo. En mi experiencia, es una buena idea asegurarse de que todo el código se revise e intentar variar quién revisa qué código.

En mi equipo actual, el código de todos se revisa por igual, y tanto el programador como el revisor deben estar satisfechos con el código antes de que pueda ser lanzado. Esto se aplica tanto a los desarrolladores senior que están siendo revisados ​​por más desarrolladores junior, un desarrollador junior que revisa a otro u otros desarrolladores senior que se revisan entre sí. Si el revisor no tiene experiencia o no se siente cómodo al revisar un fragmento de código en particular, se unirá con otro desarrollador (y quizás también con el desarrollador original) para realizar la revisión en grupo.

He estado en el negocio por más de 20 años, trabajando para compañías de software y para diferentes negocios y ninguno de estos lugares tenía un proceso de revisión de código. Sin embargo, puedo entender y apreciar los beneficios de tener uno. Esencialmente, según tengo entendido, deben usarse para garantizar el cumplimiento de las normas, que deben seguirse para que otros puedan mantener más fácilmente el código en el futuro. La legibilidad del código también puede verificarse en un proceso de revisión, ya que esto también garantizará que el mantenimiento pueda funcionar eficazmente con el código.

Actualmente, trabajo en una pequeña tienda donde soy el desarrollador único. Ocasionalmente hemos traído contratistas para ayudar con el trabajo atrasado. Al menos uno o dos de esos contratistas tienen un código escrito que no necesariamente cumple con los estándares míos o de las empresas, pero funcionó bien y fue al menos algo comprensible. Cuando indiqué este problema a la gerencia, no les importó, solo querían saber si hizo lo que les pagamos por hacer. Entonces, supongo que solo depende de la compañía, y si el código deseado es fácil de mantener o no es el producto deseado, o si solo quieren algo que funcione bien por el dinero.

Obviamente, como desarrollador, y que tiene que mantener el código, me gustaría trabajar con un código limpio que siga un estándar de algún tipo, pero no siempre tengo ese lujo, así que aprovecho al máximo y trato con lo que tengo , incluso si eso significa a veces tener que volver a escribir algún código en mi propio estándar.

Las revisiones de código pueden identificar defectos antes en el ciclo de vida del software cuando los problemas son más fáciles (y más baratos) de solucionar. En SmartBear hemos desarrollado una herramienta de revisión de código de pares y también hemos investigado mucho sobre cómo hacer que las revisiones de código sean efectivas. Según los datos de nuestros clientes, los defectos encontrados en la revisión del código son 8-12 veces más baratos de encontrar y corregir que los defectos encontrados en el control de calidad. El ahorro de costos solo hace que valga la pena la revisión del código, pero hay más valor que eso. La revisión de código es una excelente manera para que todos en el equipo aprendan y mejoren como desarrolladores de software.

Hay algunas trampas que pueden hacer que las revisiones de código sean menos efectivas, y parece que su organización está atrapada en una de ellas. Haga la revisión del código sobre el código, no sobre las personas. Los títulos no significan nada en una revisión de código. Las apelaciones a la autoridad (debes hacerlo a mi manera porque soy el líder del equipo) hacen más daño que bien. Enseñar en su lugar. Los ingenieros superiores deben explicar por qué debe hacerse a su manera, no solo exigir que así sea. Si tiene dificultades para explicar un concepto, también es una experiencia de aprendizaje para usted. Ambos serán mejores desarrolladores por el esfuerzo que pusieron.

Creo que revisar el código TODO EL CÓDIGO es excesivo. La cantidad de tiempo que lleva revisar todo el código podría gastarse mejor en otro lugar. Alternativamente, creo que el código crítico y / o las piezas particularmente complejas necesitan revisión de código, pero ciertamente no todas las líneas de código.

En mi opinión, el código que va a utilizar una empresa, ya sea que haya sido escrito por un desarrollador Junior o Senior, siempre debe revisarse. ¿Por qué? Porque, ¿y si el código tuviera varios errores? ¿Y qué pasa si, durante el tiempo en que se usaba este código, el programa fallaba? Para evitar que sucedan estas cosas, se debe revisar todo el código antes de usarlo.

¿Pero qué pasa con esas compañías que no revisan el código? Probablemente sean las empresas que tienen muchos problemas tecnológicos y muchos, como les dicen a los consumidores, "accidentes" ;-).

Déjame responder todas tus preguntas:

• Sí, el proceso de revisión es necesario.
• ¿Por qué? Por las razones que dije anteriormente.

Revisión del Código : El proceso de Revisión del Código debe ser vital para todos. Explicaré quiénes reciben todos los beneficios debido a la realización de la revisión del código, así como cuáles son los beneficios que obtienen.

1. Beneficios obtenidos por la empresa debido a la realización de la revisión del código: si se realiza una revisión frecuente del código, entonces la empresa puede obtener los productos finales de una manera mucho mejor optimizada que los ayuda a obtener un nombre de marca en su mercado y también ayuda a la empresa a obtener o mejorar su nivel actual de CMMI .

2. Beneficios para el líder del equipo debido a la realización de la revisión del código: Como todos sabemos, un maestro puede identificar fácilmente los errores, porque están revisando las respuestas de sus estudiantes con más frecuencia, para que puedan tener una idea, en qué áreas pueden ser posible por cosas equivocadas. Del mismo modo, el líder del equipo también sabe cuáles son las cosas que salen mal en estas áreas. ¿Cómo podemos rectificarlos? Y también ayudar al líder del equipo a captar las ideas de noticias del desarrollador junior también.

3. Beneficios para el desarrollador junior debido a la realización de la revisión del código: el desarrollador junior puede captar fácilmente las ideas sobre el proceso de revisión del código, también puede obtener lo que es el estándar de codificación, por ejemplo: para crear API de manera adecuada, aprenderán la estandarización de la codificación que puede ayudarlos en el futuro, especialmente cuando se conviertan en un puesto de nivel superior.

Entonces, mi conclusión es que la revisión del código es un proceso muy vital para todos [incluso para el miembro del equipo también], ya que la revisión del código nos ayuda a corregir nuestros errores descuidados en nuestro código, porque todos somos seres humanos, por lo que no podemos predecir que nunca cometer errores descuidados en el código.

¿Cuál es la diferencia con interferir con sus ideas antes de registrar su código (revisión) o después debido a un error, volverse demasiado inteligente / difícil de entender o no seguir las prácticas estándar aceptadas? ¿Es tu ego?

No puede ignorar los méritos de la revisión del código o cualquier otra cosa solo porque un miembro del equipo menos calificado no lo está implementando de manera inadecuada. La revisión de código no es un proceso muy complejo que solo unos pocos súper programadores son capaces de comprender. No estoy seguro de que haya muchos programadores o escritores profesionales que sean capaces o tengan el tiempo para autoeditarse.

¿Alguna vez has regresado a una línea de código unos meses más tarde y te has preguntado qué estaba pensando? Habría una mejor oportunidad de atraparlo con una revisión de código. Lo acabas de atrapar y eres solo un poco mejor que el programador que eras hace un tiempo, espero.

OMI, una revisión de código debería ser esencial para todos los desarrolladores, pero solo cuando las personas que realizan la revisión son competentes. En el pasado, se me rechazó el código en una revisión porque, bromeo, no lo seguí SOLID, hice una inyección de dependencia y ordené el código en espacios de nombres y carpetas de acuerdo con el diseño lógico, e incluí un pequeño conjunto de pruebas unitarias para verificar el código El código fue rechazado como "demasiado complicado" y me dijeron que usara una clase que eliminara todo y eliminara las pruebas porque no era así como la compañía escribió el código.

Una revisión de código como esa no tiene valor, pero una revisión de código con un equipo competente a menudo puede iluminar algo sobre el diseño (por ejemplo, por qué debe hacer X e Y pero no Z) o indicar un defecto real (por ejemplo, hacer X hará que Y falle por razones incorrectas).

Por supuesto, no es necesaria la revisión de código . Por otra parte, tampoco lo son las pruebas, la integración continua, el control de origen, la participación del cliente, la creación de perfiles, el análisis estático, el hardware decente, las compilaciones con un solo clic, el seguimiento de errores, y la lista continúa.

Junto con las revisiones de código, las cosas que menciono anteriormente son herramientas que ayudan a garantizar la calidad del software. Con una combinación de habilidad, suerte, tiempo y determinación; usted puede entregar software de calidad sin ninguna de estas cosas, pero es más probable que no lo hará .

En su escenario, no hay nada de qué confundirse. No todas las organizaciones se entregan a todas las mejores prácticas. Pueden estar en desacuerdo con él, puede entrar en conflicto con una mejor práctica diferente que implementan, o pueden considerar que la sobrecarga de implementarlo es demasiado grande para ellos en este momento. Dependiendo de sus circunstancias, pueden ser correctos al hacerlo, o pueden estar haciendo una economía falsa. Para algunas herramientas (por ejemplo, control de fuente), la relación de recuperación / esfuerzo es tan buena que usarla es obvio; para otros es menos claro.

No hay duda de que la revisión de código es una práctica que introduce una sobrecarga significativa. Debido a esto, las organizaciones buscarán minimizar esa sobrecarga, ya sea no haciéndolo en absoluto, o solo haciéndolo en ciertas situaciones (por ejemplo, para un miembro del equipo junior o un cambio particularmente difícil). No siempre es obvio que paga más (en la detección de errores, la reducción de la deuda técnica o el intercambio de conocimientos) de lo que cuesta. La mayor parte de esa recuperación es difícil de cuantificar, mientras que es muy fácil contar la cantidad de horas hombre que su organización dedica a hacer revisiones. El bit más fácil de cuantificar (recuento reducido de errores) es fácil de atribuir a otros factores (por ejemplo, "por supuesto que tiene menos errores, es más maduro").

Hacemos un juego de fútbol en línea en Turquía. Muchos usuarios y maestros de juegos nos ayudan en la funcionalidad. También dan comentarios sobre las características necesarias. Por lo tanto, creo que si tiene muchos usuarios, se pueden realizar pruebas de funcionalidad para ayudar u obtener insignias. La colaboración de desarrolladores, maestros de juegos y usuarios con foros, equipos de soporte y entornos de prueba privados crea un proyecto social.

Es necesario revisar el código y compartir experiencias entre el equipo de desarrollo, pero si no es crítico, no tiene que forzarse.

Creo que la inspección detallada de la segunda parte depende de su ciclo de vida, ya sea que sea más ágil o más cascada en sus procesos. Creo que es razonable hacer diseños / inspecciones de alto nivel, así como inspecciones de diseño de más nivel de detalle. Creo que también es bueno involucrar a varios miembros de un equipo para inspeccionar.

Son absolutamente necesarios ya que tienen poca experiencia.