64 votos

Es grosero refactorizar / mejorar código miembros del equipo?

Cuando se trabaja en un proyecto único con un pequeño equipo de, digamos, tres de los desarrolladores, es común que nos preguntarse unos a otros:

"Oh, ¿cómo esta clase de trabajo?" o "¿Qué propiedad se establecen en el presente para hacer que esto suceda?" como la base de código, crece, y por supuesto, debemos hacer uso de las APIs disponibles, clases, controles, et al. que tenemos que construir.

Sin embargo, a veces estoy insatisfecho con algunas implementaciones, pero no quiero "decir" a los demás lo que deben hacer.

A veces es algo tan pequeño como "lugar de cambiar dos propiedades para hacer que algo suceda, ¿por qué no llamar a un método con dos parámetros?" Ese tipo de cosas.

Otras veces, se trata de algo un poco más grande, como toda forma de cuadros de diálogo se han implementado a lo largo de la aplicación.

En estos casos, a veces me encuentro solo va allí una vez que todo ha sido revisado, y cambiar el código, y luego comunicar que he cambiado esto o aquello, y por qué.

Es que descortés? De ninguna manera estoy diciendo que yo siempre saben mejor, es puramente un caso-por-caso de la cosa.

Mi sensación es que me gustaría trabajar en entornos donde los demás se sienten libres para mejorar en lo que he hecho, siempre que se comunique conmigo después. No, porque yo "propio" en el código, sino porque me gustaría aprender.

Yay o nay?

ACTUALIZACIÓN

Gracias por todos los aportes. Quiero abordar algunas respuestas específicas cuando tengo algo de tiempo.

Mientras tanto, el principal sentimiento que yo voy es que, como equipo, debemos establecer algunas expectativas en cuanto a cómo tratamos a cada trabajo de otros. Ya sea a través de las revisiones de código, o que acabamos de decir, "mira, es un libre para todos!". No es que nos gustaría hacer eso, pero al menos las expectativas establecidas.

37voto

Tom Anderson Puntos 323

La verdadera respuesta a su pregunta es que tal vez. Debe ajustarse a las prácticas de su equipo, y cada equipo es diferente. He refactorizado la parte superior de las respuestas a generar algunos de los pros y los contras de este tema, y se abrió esta respuesta como un wiki de la comunidad.

PROs

El código está subordinado a los objetivos de

  1. Usted puede cambiar el código de los demás. Usted tiene la actitud correcta. Nadie posee el código.
  2. Es descortés (y con el tiempo, incluso peligroso) para permitir que los problemas de diapositiva sin cambiar ellos.
  3. Depende de los resultados. Si el nuevo código es notablemente mejor (más rápido, menos recursos, menos fallos, más legible), entonces la gente sería tonto objeto. He tenido mi código mejorado por los más conocedores de los co-trabajadores y agradecido.

Cambiar si hay una razón de peso

  1. No cambiar algo que no existe una razón convincente para hacerlo. Pero si es que la hay, yo rara vez discutir.
  2. Esté preparado para explicar los cambios. Si el otro programador no está de acuerdo con ellos, él se queda con su versión, o duque a cabo con el equipo de plomo.

Trabajo en equipo

  1. Si se puede cambiar el código, es un signo de la fuerza del equipo.
  2. Esto sólo funcionará si el equipo es realmente cuajó como un equipo.
  3. Aprender a hacer esto con la humildad puede realmente ayudar a un equipo de gel.
  4. En el equipo de trabajo, no es descortés. Nos práctica colectiva del código de la propiedad -- así que si alguien encuentra algo que debe ser mejorado, ellos tienen el poder para arreglarlo.

Estandarizar las prácticas de codificación

  1. Promover buenas prácticas de codificación por compartirlos. Comunicarse con sus colegas para entender por qué algo fue hecho de una cierta manera, en lugar de simplemente cambiando. A veces hay una razón por la que algo se hace de una manera subóptima.
  2. Si los cambios son menores o triviales, solucionarlo en el acto. Si es un cambio importante (a gran escala refactorizar/cambio de diseño), mejor es hablar primero con la persona que aplicó el código de/plomo antes de excavar en hacer los cambios.

Los contras

Ten cuidado: los Cambios no están garantizados para estar libres de error

  1. Es importante saber si estás en lo correcto acerca de las mejoras. Si usted hace este tipo de cosas (incluso si están en lo correcto) sin ningún tipo de consulta del equipo, es potencialmente un problema en el equipo.
  2. A veces, después de mejorar en algo, se cambia de nuevo más tarde. Este es un signo de que no todo el mundo en el equipo tiene un entendimiento común de la situación del código en cuestión. En este caso, la acción apropiada es tener una conversación y construir un entendimiento común (que puede no coincidir con su opinión inicial) y luego decidir qué hacer.

Que toma mucho tiempo

  1. Se tarda demasiado tiempo para discutir los cambios, pero si haces un cambio proporcionan comentarios para explicar el cambio. O estar preparado para discutir el cambio si la gente pregunta acerca de esto más tarde.
  2. Si hay falta de transparencia y la imposibilidad de llegar a un acuerdo por consenso sobre un tema de diseño, esto será difícil y potencialmente destructiva.
  3. Si no tienen nada más urgente que hacer en el momento, a continuación, la refactorización es bueno. Si usted tiene un montón de trabajo que hacer y salirse de su trayectoria la refactorización del código, que no es relevante para su tarea actual, entonces usted podría estar perdiendo el tiempo.

Egos

  1. Que tipo de cosa que sinceramente me molesta y estoy seguro de que podría molestar a los demás en el equipo, si me lo estaban haciendo. Es por eso que hacemos revisiones de código y ofrecer sugerencias para cada uno de los otros. Yo creo que haciendo algo así como que después de que el hecho puede conducir a la mala sangre entre los miembros del equipo.
  2. Cuando se trata con los egos en la oficina, probablemente sería mejor servido preguntando la misma pregunta. Si había implementado algo, podría sentir que era descortés para alguien más en el equipo de re-escribirlo sin dejar que usted sabe?
  3. En el extremo sería el de alguien que está descuidando su propio equipo de trabajo/lista de fallos, y comienza la inserción de errores en los demás pueblos de código, mientras que pensar que se ha mejorado. Que tipo de truco conseguirá que los desprecien, y esperemos que disparó.

22voto

Robert Harvey Puntos 103562

Usted tiene la actitud correcta. Nadie posee el código. Sin embargo, debe estar preparado para explicar los cambios. Si el otro programador no está de acuerdo con ellos, o bien se queda con su versión, o que duque a cabo con el liderato del equipo.

Generalmente no cambio algo a menos que haya una razón de peso para hacerlo. Pero si hay uno, yo rara vez hablar de ello. Yo no tengo el tiempo para discutir cada pequeño cambio que hago al código. Sin embargo, yo proporciono comentarios que explican el cambio.

18voto

Sean Reilly Puntos 9869

En el equipo de trabajo, no es descortés. Nos práctica colectiva del código de la propiedad -- así que si alguien encuentra algo que debe ser mejorado, ellos tienen el poder para arreglarlo.

A veces usted puede encontrar que después mejoró algo, cambia de nuevo más tarde. Este es un signo de que no todo el mundo en el equipo tiene un entendimiento común de la situación del código en cuestión. En este caso, la acción apropiada es tener una conversación y construir un entendimiento común (que puede no coincidir con su opinión inicial) y luego decidir qué hacer.

9voto

Cade Roux Puntos 53870

Esto sólo funcionará si el equipo es realmente cuajó como un equipo.

Si hay falta de transparencia y la imposibilidad de llegar a un acuerdo por consenso sobre un tema de diseño, esto será difícil y potencialmente destructiva.

Yo tomaría si usted puede hacer esto como un signo de la fuerza del equipo.

También es importante saber si su sentencia es correcta en su razonamiento acerca de las mejoras. Independientemente, si haces cosas como esta (incluso si están en lo correcto) sin ningún tipo de consulta del equipo, es potencialmente un problema en el equipo.

8voto

Sai Ganesh Puntos 291

Un campo denominado Ingeniería de Software se puede aplicar de manera muy eficaz en su caso. ¿Qué hay de la introducción de una revisión del diseño y revisión de código en el proceso de desarrollo?

Y leer este documento técnico para revisiones de código: http://smartbear.com/SmartBear/media/pdfs/WP-CC-11-Best-Practices-of-Peer-Code-Review.pdf

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X