Tratando con algunos problemas de estilo de código gris

Question

Tenemos un desarrollador intermedio que es muy bueno en lo que hace, pero hay un borde áspero para este diamante. Él es muy insistente en que cada método tenga solo una entrada y un punto de salida.

El enfoque que estoy tomando es no hacer una gran cosa con el código que escribe (excepto cuando hay un problema serio de claridad). Lo que me molesta es que comienza a refactorizar el código de otros para que solo tenga una entrada y un punto de salida. Este es un código que ya ha sido probado (pero no siempre con pruebas automatizadas), por lo que existe un riesgo.

Soy un desarrollador sénior en el equipo, por lo que tengo la autoridad para definir las reglas en cuanto a la base de código. Pero, ¿cuál sería el camino correcto a seguir aquí? ¿Debo dejar que continúe refactorizando el código de otro como este? Si no, ¿cuál es la mejor forma de abordar la situación?

Answer 1

En resumen, no, a menos que tenga reglas explícitas contra eso en su estándar de codificación (tiene una, ¿no?). Cambiar el código por el simple hecho de eso es solo una cuestión de problemas (y tensiones en el equipo).

Antes que nada, discuto esto con el desarrollador, y saco ejemplos de tales cambios que causaron problemas importantes en el pasado.

Además, este es un caso en el que las revisiones de códigos probablemente sean útiles. Si ese desarrollador necesita publicar una revisión del código y hacer que este cambio sea explícito para el resto del equipo, es probable que no se moleste, o el código será rechazado por sus compañeros.

Si las revisiones de los códigos no son una posibilidad, puede optar por imponer la propiedad del código, en el sentido de que debe consultar con el desarrollador principal de un módulo si va a cambiar las cosas en la base de códigos.

Answer 2

Si usted es el hombre que define las reglas y cree que no tiene sentido, simplemente dígale que no se le paga para refactorizar el código a SU manera, sino para completar un proyecto.

Answer 3

Permitir que las personas revisen el código de otros para volver a formatear cuando el rendimiento real no es un problema es una buena manera de arruinar las relaciones del equipo. Cambie el código de otra persona solo cuando exista un motivo convincente para hacerlo, o si la dinámica del grupo es muy abierta.

Answer 4

Pregunte si permite que otros tengan una diferencia de enfoque. Si él hace esa concesión, simplemente puede señalar para cada línea que refactores alguien puede venir y revertir el código de regreso exactamente de la manera que era porque su opinión difería. ¡Asegurando así un gran bucle infinito que todos sabemos que es malo! :)

Answer 5

Dile que un mandato es mantener los cambios de código al mínimo. No debería cambiar el código que no es pertinente para la tarea en cuestión. Las principales razones son:

1. Para reducir el riesgo - "Oye, eres tú quién es responsable si se rompe nada."
2. Revisar el código será más rápido ya que permite a los revisores centrarse solo en el código que se está agregando/cambiando.

Answer 6

Haz que repase una revisión de código para todo lo que cambia y todo lo que toca. No me gusta la idea de usar la revisión de código como castigo, pero él tiene que entender la profundidad de lo que está haciendo.

Luego lo haría sentarse con QA y explicarle cómo cambió muchas más funcionalidades de las que necesitaba. Después de que terminen de golpearlo por un tiempo.Luego, llévelo al gerente del proyecto y pídale a esa persona que le explique cómo está cumpliendo con el cronograma.

Si eso no funciona, golpéelo hasta que llore.

Answer 7

Estoy un poco confundido. ¿Significa eso que pone un try {} catch (...){} (o el equivalente de su idioma) alrededor de todo el código en todos los métodos? De lo contrario, las excepciones se contarían como una ruta alternativa al método.

Y francamente, eso es lo que son diseñado para hacer. De lo contrario, un código de salida simple serviría para el mismo propósito.

Si realmente molesta a las personas, podría valer la pena anular rutinariamente cualquier cambio que realice que no tenga ningún impacto funcional. Si no le gusta el comportamiento pasivo-agresivo, póngalo en su revisión de desempeño. Puede sonar un poco difícil, pero he tenido cosas más tontas que las mías.

Answer 8

de otro código

Si usted cree en la propiedad del código comunitario, no existe tal cosa.

estilo de código gris

En ausencia de una norma de codificación de la comunidad, yo/hay que desarrollar la propia regla de codificación. No espero que otros tomen la misma decisión. Voy a refactorizar el código en el que estoy trabajando para cumplir con mi regla, si lo noto y si la refactorización es barata de realizar.

---

Hay dos costos para mi regla personal.

"Mi tiempo"

que podría estar haciendo progresos en alguna otra tarea de programación. Si no tengo otra tarea de programación, mi tiempo era libre y esto es solo un buen trabajo.

"Código de base de oscilación"

Si otros se reestructuran mis refactorizaciones, entonces hay una clara necesidad de una comunidad regla de codificación. La regla podría ser tan simple como: ambas formas son aceptadas, no refactorice este escenario. Esta declaración debe hacerse explícitamente, o no será ejecutable.

---

Este es el código que ya ha sido probado (pero no siempre con pruebas automáticas).

Aha, una tarea de programación. Esto debería ser asignado.

Answer 9

He estado en esa situación particular anteriormente, aunque creo que su programador intermedio es probablemente la excepción, en lugar de la norma, el problema es que la mayoría de los programadores no tocarán otro código a menos que sea necesario.

Lo más probable es que, si su intermediario está haciendo esto, antes le haya mordido, y él sabe que probablemente no sea la mejor idea cambiar el código por principio. Sugeriría una discusión firme pero abierta sobre por qué está haciendo esos cambios desde el principio. Lo más probable es que, si presenta sus argumentos con claridad pero sin fuerza, se dé cuenta del perjuicio que pueda causar.

De lo único que tendría cuidado es de sofocar el entusiasmo de este tipo por escribir un buen código. Obviamente lo está haciendo porque cree que mejorará tu código base. Como dije, creo que su actitud es la excepción más que la norma, y ​​es refrescante escuchar a otros que quieren mejorar proactivamente su software. (Entiendo el riesgo asociado, pero suena como algo que se puede reducir considerablemente con algunas pruebas automáticas)

Espero que ayude!

Answer 10

Como le molesta (y usted está a cargo), debe al menos hablar con él al respecto. Ya que tienes una razón sólida para molestarte (podría romper cosas), probablemente quieras decirle que no haga eso. Puntos de bonificación si puede lograr que entienda realmente por qué a otras personas no les molestan los múltiples puntos de entrada/salida, y en realidad podrían gustarles.

Answer 11

¿Quién conduce el barco en su tienda? Alguien mejor que sea. Si eres tú, entonces dispara directamente con este tipo y comunícale cómo funcionan las cosas en tu tienda. Es probable que no haya un beneficio real para lo que esencialmente equivale a un trabajo ocupado. Uno puede discutir acerca de múltiples salidas de un método versus una única salida, pero el punto es que si le permiten cambiar lo que quiere, tiene un serio problema de proceso allí.

Definitivamente un problema de "personas" que puede resolverse rápidamente diciéndole cómo funcionan las cosas. No es necesario ser desagradable, solo honesto.

Además, ¿quién tiene tiempo para meterse con el código de otras personas? Obviamente no está siendo totalmente encargado. :)

Answer 12

Es posible que desee señalarlo, pero tenga cuidado de cómo lo frasee. Cada vez que tiras el "estoy en lo correcto porque soy la persona mayor", pierdes la credibilidad y vas a matar la moral. No importa si tiene el derecho, no será percibido de esa manera.

Probablemente no debería refactorizar/formatear el código que no está siendo probado activamente, pero en el mismo momento, si lo tratas como si no pudiera hacer nada bien, entonces lo más probable es que termine renunciar Al final, lo más probable es que le cueste a la compañía mucho más que una pequeña cantidad de tiempo adicional de qa (especialmente si realmente está limpiando un código incorrecto). No digo que no debas mencionarlo, solo intenta ver si es desde su punto de vista y haz que te encuentre a mitad de camino en lo que dices.

Answer 13

He estado en situaciones similares a esto dos veces antes.

En el primer caso, tuvimos un tipo que tenía un sentido diferente del estilo de One True Brace que el resto del equipo y lo cambió cuando estaba leyendo el código. La mayoría de nosotros lo ignoró o lo devolvió. En su caso, él era demasiado bueno como para molestarlo por algo tan menor. No es un gran problema, solo molesto.

En el segundo caso, teníamos un ingeniero que trabajaba de forma remota en un huso horario diferente y que era literalmente como los elfos del zapatero. Las cosas que se implementaron a medias con un montón de FIXMEs fueron mágicamente hechas y hermosas. En su caso, mejoró notablemente las cosas y solo trabajó en las cosas que le asignaron, así que estuvo bien con nosotros.

En su caso, este no es el trabajo que está asignado para que pueda

• pedirle que no lo haga: no es su misión
• decirle que no se refactorizar código que no es su (es decir, , deje el código de otras personas igual)
• requieren que programe las tareas, incluida la creación de pruebas de unidad de línea de base para cada rutina/método que desee cambiar en los rangos de entrada sustanciales y verifique la salida en el código modificado. Puedes decirle que estás tratando de hacerlo desagradable porque el costo de corregir los errores que está introduciendo seguramente será más que el tiempo para refactorizar, y ¿no estaría trabajando en las características principales?

Answer 14

Algo como esto es inaceptable. Si no hay un estándar/estilo/diseño de codificación establecido, el programador debe imitar el código y el estilo existentes y abstenerse de refacturar cualquier cosa.

Si este programador tiene tiempo para refaccionar todo, entonces claramente necesita más trabajo asignado.