Revisión de código realizada por un ingeniero que codifica en un idioma diferente. ¿Es constructivo?

Question

Soy un ingeniero de soporte técnico que descubrió recientemente lo divertida que puede ser la programación. Mi jefe se dio cuenta de este interés y sugirió que aprendiera Ruby como primer idioma ya que la empresa puede beneficiarse de él, tiene una sintaxis muy elegante y no necesitamos más programadores Java/C/C++.

Bien, he escrito mi primer script Ruby bastante grande que es esencialmente un cliente de front-end automatizado para nuestro producto de aplicación web. El script funciona ... Pero como es mi primera aplicación completa, estoy seguro de que hay muchos errores (que estoy aplastando lentamente), y estoy seguro de que no lo escribí de la mejor manera posible.

Ahora mi jefe quiere hacer una revisión del código: es un programador de Java y no conoce ningún Ruby en absoluto. Él admite que siempre odió las revisiones de código, pero es un mal necesario.

Mi pregunta es:

Puede un programador que escribe en un idioma realizar con eficacia una revisión de código útiles/constructiva de otro idioma que no tienen conocimiento de?

La última reseña que tuvimos fue horrible, tuve que salir del edificio, porque sus críticas realmente no me guiaron en ninguna dirección debido al hecho de que no podía sugerir formas específicas/mejores de hacer las cosas en el apropiado "Ruby way".

Answer 1

Creo que no, por exactamente las razones que insinúa al final de su pregunta. Alguien que no programa Ruby no podrá darte consejos sobre la codificación en el estilo Ruby adecuado. Acabarás escribiendo Java en Ruby.

Es posible que pueda darle buenos consejos generales sobre ingeniería de software, pero no creo que eso sea realmente para lo que es código.

Answer 2

Creo que puede ser eficaz, pero creo que para lograr la mayor efectividad de esto, debe hacer una revisión del código desde un enfoque más independiente del idioma. Tu jefe no puede pensar en la "forma de Java" mientras piensas en la "forma Ruby" cuando haces la revisión. Ambos deben pensar en más términos de pseudocódigo. Tu última declaración sobre que tienes que salir del edificio sugiere que tal vez tu jefe debería aprender ruby, especialmente porque sugirió que aprendieras Ruby. ¡Buena suerte!

Answer 3

¿Puede un programador que escribe en un idioma realizar efectivamente una revisión útil/constructiva del código de otro idioma del que no tiene conocimiento?

Supongo que sí, pero supongo que depende del programador.

Él puede hace preguntas como:

• ¿Qué funcionalidad que han implementado?
• ¿Qué partes de este software implementan qué partes de la funcionalidad?
• ¿Cómo ha probado esto?

Parte de un motivo para una revisión del código puede ser ayudar al revisor, por ejemplo, si no está disponible y necesita mantener/ser responsable del código; así que a veces la dirección de la transferencia de conocimiento es de ti hacia él, y no solo de él hacia ti.

Sin embargo, si "siempre odió las revisiones de código", es un síntoma de que está/no está haciendo lo correcto: y tal vez debería averiguar más acerca de cómo hacer que una revisión de código sea más exitosa.

Answer 4

Bueno, hay varios "olores de código" que un programador experimentado puede notar directamente incluso sin conocimiento previo en el idioma. Cosas relacionadas con la ingeniería de software en general. Pero cuando se trata de Ruby, sospecho que puede dar una útil revisión de sintaxis si nunca antes hizo programación funcional o al menos hizo algún código en lenguajes modernos como Ruby like: Groovy, Scala o Python.

Answer 5

Pueden serlo, pero el tuyo no va a ser así porque el tipo Java no suena como un gran programador. Hay algunas cosas que son comunes en muchos idiomas (por ejemplo, declarar variables en el ámbito más pequeño posible, las funciones deben hacer 1 cosa, vinculación flexible y acoplamiento cerrado, abstracción adecuada, etc.)

Answer 6

Discutiré esto como código La revisión es sinónimo de inspección de código: el desarrollador y el (los) crítico (es) se sientan en la sala revisando el código. Ignora los bits que no son relevantes para tu situación.

Trate de no pensar en una revisión de código como una crítica de su código. Si se convierte en eso, lo están haciendo mal.

La estrategia debe ser hacer que caminen a través del código, explicando lo que lo ven hacer. Si no se comprende bien, puede detenerse o explicar. Cualquier problema o problema detectado puede ser discutido brevemente, y puede ser anotado como un error, comentario del código (no ordenado, llaves sugeridas, etc.) o acción, algo para investigar.

Tenga en cuenta que ninguno de estos son críticas. Todos trabajan para la misma compañía. Su código se convierte en su código y viceversa (si escriben código). El objetivo es a) producir un código sólido, sostenible y correcto, yb) aprender de ello. Se sorprenderá de lo mucho que aprende a revisar el código de los demás y de que revisen su código. Sí, la idea de leer el código es DOLORosa, pero en la práctica es una gran experiencia educativa, y te da ideas sobre qué buscar en el futuro.

NOTA: Si los problemas que identifican no son útiles - "esto es estúpido", "esto podría ser mucho mejor", versus más útil - "si refactoriza esto y desenrolla ese aspecto puede cambiarlo de Ordene O (n^2) a la orden O (n) "- luego asegúrese de abordar esto - quizás haga un acuerdo al principio para no atacar al escritor o al código, sino para ayudar a mejorar. Esto incluso puede ser una sorpresa para ellos, es posible que no se hayan dado cuenta de que estaban siendo confrontativos en sus críticas.

Para la cuestión de la revisión entre idiomas, seguro. La sintaxis del código de un idioma a otro puede diferir, pero muchos de los trucos aprendidos, algoritmos, progresiones lógicas, errores comunes y más se aprenden independientemente del idioma, y ​​se pueden aplicar como experiencia a futuras revisiones o codificación.

Answer 7

Si la revisión se mantiene en un nivel relativamente alto, puede ser muy constructivo. Siempre y cuando él esté haciendo preguntas arquitectónicas como por qué has usado un cierto patrón o algoritmo, entonces esto debería ser muy útil. Los nuevos programadores típicamente necesitan orientación sobre cómo estructurar sus aplicaciones en un nivel superior y creo que esto puede ser proporcionado por cualquier buen desarrollador de software.

Si le preocupan por completo el estilo de codificación (carcasa, incrustaciones, etc.), esto será menos útil. aunque puede ser capaz de señalar dónde eres inconsistente.

Answer 8

Un codificador que conoce otro idioma podría encontrar errores, pero Java y Ruby son tan diferentes estilísticamente que no estoy seguro de que proporcione puntos de estilo útiles.Además, si el otro programador solo conoce Java, puede que ni siquiera sea capaz de leer Ruby lo suficientemente bien como para encontrar errores (los bloques son muy extraños para un programador Java).

Answer 9

Una revisión de código de un no ruby-ist podría ser útil. Como se describe a sí mismo como un principiante, es probable que haya algunos principios generales de diseño de software independientes del idioma que le resultarán útiles ("código huele"). Algunas cosas fuera de mi cabeza:

• ¿Estás duplicando el código?
• ¿Está escribiendo código que será difícil de entender para los demás? (por ejemplo, nombres incorrectos, operaciones múltiples mezcladas juntas)
• ¿Estás haciendo demasiado con el estado global?
• ¿son sus funciones demasiado largas? ¿Están haciendo 1 cosa, o 10 cosas?
• ¿está mezclando el objeto y el estado de la instancia (el tipo de cosas que nota a mayores cargas, a medida que los errores de concurrencia empiezan a ser más notorios)?

Estos son todos tipos de cosas de "práctica general", pero probablemente sean más importantes que la sintaxis específica del lenguaje a largo plazo.

Hay, por supuesto, cosas que no se traducirán tan bien, p. debido a mixins habrá muchas cosas que harás de manera diferente en términos de herencia. Un programador de Java probablemente también se sentirá incómodo con las diferencias en tipeo.

Answer 10

yo diría que sí que veo un par de opciones diferentes de cómo podría funcionar:

1. El jefe lee el código por su cuenta y hace algo de jugar un rato para ver cómo las cosas en general, trabajar y luego regresa para guiarlo a través de varias partes que podrían modificarse para mejorar partes de la aplicación.

2. El jefe dirige una reseña en términos de decir: "Quiero centrarme en esta pieza", y en la que no entiende algo, lo explica para que entienda lo que hizo y también piensa en varios ideas de los "errores" que son posiblemente universales, por ejemplo entrada de basura, registro y manejo de excepciones.

En ambos casos, hay algo que decir acerca de la identificación de buenas piezas, partes malas, y qué se puede hacer para corregir las partes malas. Darle críticas constructivas, así como lo que se debe hacer a continuación y en qué plazo son puntos clave de esto. Decir: "Esto es una porquería, rehacer todo ahora", no es exactamente útil.

Answer 11

Quizás pueda separar una revisión de diseño de la revisión de código.

Un desarrollador experimentado debe ser capaz de participar de manera efectiva y agregar valor a una revisión de diseño de cualquier aplicación.

La diferencia sería que no necesitaría discutir o revisar el código real, o la sintaxis de esta o aquella característica, pero mire desde un nivel superior de qué algoritmos se usan, cómo ha establecido el clases y áreas de responsabilidad, etc.

Answer 12

¿Puede un programador que escribe en un idioma efectivamente realizar una revisión útil/constructiva del código de otro idioma del que no tiene conocimiento?

se le puede hacer un poco de una generalización precipitada aquí acerca de los colaboradores de código, es decir, que si un programador escribe con soltura en un idioma que él o ella realizará útiles constructiva revisión de código pecado/ese idioma. Eso a menudo no es el caso.

Para proporcionar una revisión de código útil/constructivo en cualquier idioma, debe ser un buen profesor, además de tener un buen conocimiento de programación (en algunos idiomas). Un porcentaje muy alto de comentarios de revisión de código (los más útiles, de todos modos) no son específicos de la sintaxis de un idioma determinado, sino que tratan con conceptos de alto nivel. Por lo tanto, un revisor eficaz generalmente tendrá un buen conocimiento de "olores de código" y técnicas de refactorización comunes.

Por lo que la respuesta breve a su pregunta es "Sí". Pero también tienen que ser buenos maestros.

La última revisión que teníamos era horrible, tenía que caminar fuera del edificio - porque sus críticas no muy me guía en cualquier dirección ...

comentarios Review no debe tomarse como una crítica (y tampoco deberían ser tratados de esa manera). La revisión es una oportunidad para que tanto el autor como el revisor aprendan algo. Las mejores revisiones de códigos tienen más de un revisor en el que una discusión grupal puede llevar a todos a la mejor respuesta. El código en sí es casi secundario a la revisión. La revisión es un éxito no cuando el código se soluciona, sino cuando los participantes aprenden una mejor forma de codificar que pueden aplicar a esfuerzos futuros.

Answer 13

"pero es un mal necesario" ya es un indicio de que usted, su jefe y la organización tienen algunos problemas.

Dudo que se beneficie de las revisiones de código, no porque las revisiones de los códigos sean malas o porque las personas que no dominan el idioma están revisando el código, sino porque su cultura simplemente no lo permite.

Todos ustedes necesitan aprender algunos buenos métodos para realizar revisiones. Deseche todas sus nociones de lo que son y consiga ayuda con ellos o lea algún material bueno.

Comience con muy poco impacto, comentarios informales.

buena suerte

Answer 14

¿Eh, usted tiene una opción? Pensé que era tu jefe?

(en otros mundos, complacerlo - es muy probable que de todos modos :))

Pensándolo bien creo que se debe tener en cuenta el hecho de que sus programas de Ruby debe ser legible y fácil de mantener, incluso para un programador no Rubí. Creo que es justo, para que su jefe vea que puede escribir ese código. El código debe ser "propiedad" de todos en el equipo de programación.

Answer 15

Una de las cosas que he encontrado útiles en una revisión de código sin importar el nivel de habilidad del revisor es la oportunidad de explicar lo que estaba haciendo en palabras. A veces, simplemente poner lo que hiciste en una explicación puede hacerte ver a ti (no al crítico) algo incompleto o abordarlo de otra manera.

Lo más importante acerca de la revisión de un código es la actitud: su actitud. Si entras con la esperanza de que no valga nada, entonces será. Si entras con la esperanza de ser insultado, entonces lo serás. Si lo hace con la mente abierta y la voluntad de utilizarlo como una experiencia de aprendizaje o la posibilidad de encontrar errores o problemas antes de que comiencen a producir y se conviertan en PROBLEMAS, eso es lo que encontrará.

El código de nadie es perfecto, hay múltiples formas de hacer todo. Algunas veces otras personas tienen un enfoque en el que no pensabas pero que podría ser un mejor enfoque que el que tomaste. Incluso si decidió no cambiar a ese enfoque esta vez debido a limitaciones de tiempo, ahora se considerará en su conjunto de herramientas potenciales como un enfoque.

Incluso si tiene que explicar por qué Ruby hace las cosas de una manera diferente a Java, sospecho que aprenderá más sobre Ruby (para defender sus opciones de codificación) y algo sobre Java (basado en las cosas que parecen extrañas el programador de Java.) Yo llamo a eso una victoria.

Y sí, un codificador experimentado normalmente puede encontrar cosas que señalar en una revisión del código, incluso si no es su lenguaje habitual.

Answer 16

Realmente depende de cómo se enmarca. Hay muchas malas maneras de enmarcarlo, de tal manera que terminas siendo abusado.

Puede ser útil, pero no tan eficiente como tener a alguien que sepa el idioma. Así como el hecho de que un programador junior de rubí revise el código podría tener algún beneficio, contar con una persona con más experiencia lo ayudará más.

El otro aspecto de esto es enmarcarlo para que la gente de Java pueda aprender algo de Ruby. Las revisiones pueden ir en ambos sentidos. También obtendrá una buena experiencia presentando su trabajo.

Como otros dicen, no parece que tengas muchas opciones, y realmente puede ser útil.

• presentar su trabajo con confianza
• tienen metas claras para el meeting-- crear preguntas específicas para los revisores para responder
• tener a alguien en especial tareas de mantener las cosas en el tema
• escuchar, reconocer lo que dice la gente , pero trate de evitar que se le asigne ningún elemento de acción; parece que la reunión puede ser demasiado desordenada para dar los próximos pasos correctos.
• tomar todo con un grano de sal

Answer 17

Todo el tiempo que se pasa a mí:

• tengo que explicar todos los elementos básicos a la crítica que, obviamente, no se preocupa por el aprendizaje de al menos el mínimo necesario
• el revisor sólo se agarra pocas partes de la lógica a menos que sea un archivo muy simple
• tengo que discutir sobre trivialidades
• me pongo algunos útiles comentarios de vez en cuando como si pudiera hacer que sea una constante aquí

Ruby es más fácil que Java, por lo que podría no lastimar demasiado, pero el tipo de Java se verá tentado a aplicar los conceptos que son inusual en ruby.

En mi opinión, es casi inútil tener su código revisado por:

• Una guía que en realidad no escribir código
• Un tipo que no lo hace el programa de forma regular en el idioma que está utilizando
• Un gerente o cualquier tipo no técnico que cree que conoce la tecnología, simplemente porque lee el artículo.
• Una mujer, que puede perder esa :-). Sí, sé lo que algunos van a decir, pero aún ... :-) No hay muchas mujeres haciendo programación por razones obvias :-)