Refactorización y control de fuente: ¿cómo?

Estoy completamente de acuerdo con las ideas detrás de TDD, Refactoring y Patterns, pero parece que hay un gran vacío en estas ideas, principalmente que son geniales para los equipos de desarrollo de 1, pero cuando comienzas a refactorizar el código, 10 personas están Al trabajar en ti, comienzas a fusionar conflictos por todos lados y la mayoría de los progtwigs de diff / merge no pueden decir que reescribiste una function en su propia class.

¿Cómo se limpia el código, mediante refactorización, sin causar dolores de cabeza importantes para todos en su equipo?

Pequeños cambios cometidos a menudo.

En cuanto a su ejemplo, usted comenzaría creando la class, comprometiendo ese cambio. Luego agregue una function similar en la class como la anterior y comprometa ese cambio. Luego cambie todas las references de la function anterior a la nueva function de class, confirme eso. A continuación, elimine la function anterior y confirme ese cambio.

Por supuesto, nadie dijo que iba a ser fácil.

Bueno, en la práctica, rara vez es un problema. Por lo general, los diferentes miembros del equipo están trabajando en diferentes áreas del código, por lo que no hay conflicto. Además, la mayor parte de la refactorización entrará cuando estés haciendo tu TDD (que incluso podría ser antes de que compruebes tu código, pero definitivamente antes de que otros comiencen a usarlo y modificarlo).

Si considera que tiene muchas contradicciones debido a refactorizaciones, intente verificar más a menudo, o haga saber a la gente quién podría estar trabajando en el mismo código que está a punto de realizar una nueva revisión importante. La comunicación siempre ayuda.

Ingreso frecuente ins. Los miembros del equipo deben verificar sus cambios y volver a sincronizar sus areneros al less una vez al día. Con un check in más frecuente, los conflictos de fusión se producirán con less frecuencia y serán más fáciles de gestionar cuando ocurran.

Creo que su equipo tiene que estar a bordo con sus cambios. Si está haciendo grandes refactorizaciones, realizando grandes cambios en su base de código y jerarquía de objects, querrá analizar los cambios como un equipo.

Creo que debería hacer algunas preguntas para saber por qué la refacturación podría perjudicar el control de la fuente.

  • ¿Por qué 10 personas cambian el mismo código al mismo time?
  • Hay mejores herramientas para ayudarlo a realizar refactorizaciones / fusiones (¿quizás control de versiones distribuidas )?

Para la primera pregunta, tal vez no tenga una buena separación de preocupaciones y el código esté estrechamente relacionado. O tal vez los equipos no se comunican bien cuando asignan tareas. Para la segunda pregunta, bueno, pruebe algunos buenos DVD ( git , mercurial , bazaar ) y vea si alguno puede ayudarlo.

Saludos cordiales

Cuando creo que una refactorización será difícil de fusionar, hago esto:

  1. Advierta a mi equipo de que el cambio se aproxima y compruebe si hay algún cambio pendiente que sea difícil fusionar.
  2. Asegúrate de entender el cambio que voy a hacer, para poder hacerlo rápidamente. Mejore la cobertura de testing ahora, si es necesario.
  3. Sincronice mi máquina con la última fuente.
  4. Refactor, testing y commit.
  5. Notifique a mi equipo para que se sincronicen con mis cambios.

Tenga en count que estoy haciendo que mi refactorización cambie por separado de los cambios de funcionalidad.

Comunicación.

Las herramientas no pueden resolver esto por usted, a less que la herramienta específica sea su correo electrónico o cliente de postría instantánea.

Es lo mismo que si estuvieras haciendo otro cambio importante en un proyecto compartido: necesitas poder decirle a tus compañeros de trabajo / queueboradores "hey, manos libres por un par de horas, tengo un gran cambio en el module de FooBar que viene en".

Alternativamente, si va a realizar un cambio tan importante que tenga el potencial de causar enormes conflictos de fusión con el trabajo de otras 10 personas, ejecute el cambio de antemano. Tener una revisión del código. Pida información arquitectónica. Luego, cuando esté lo más cerca posible del consenso, tome ese locking virtual en la sección del repository que necesita, verifique sus cambios y envíe un post de confirmación.

No es una solución perfecta, pero es lo más cercano que obtendrás. Muchos sistemas de control de fuente admiten lockings explícitos en secciones de la base de origen, pero nunca los he visto conducir a buenos resultados en estas áreas. Es un problema social, y solo necesita recurrir a soluciones técnicas si no puede confiar en las personas con las que está trabajando.

En mi experiencia, los conflictos de fusión rara vez son un problema cuando se realizan refactorizaciones de pequeña y mediana escala en proyectos ágiles. Los grandes esfuerzos de refactorización pueden introducir cierto dolor de fusión, pero si se realiza en trozos de tamaño de mordida, el dolor puede networkingucirse significativamente. El dolor de fusión también se puede networkingucir utilizando Subversion como su SCM, ya que SVN fusionará automáticamente los cambios no conflictivos.

Esta estrategia ha funcionado bien para los equipos en los que participé, y la mayoría de esos equipos tienen más de 4 pares de desarrolladores.

Tienes que empezar lento y pequeño. Tome una parte del código y observe todas las interfaces externas. Tienes que asegurarte absolutamente de que no cambien. Ahora que ha definido ese comienzo, mire la estructura interna del mismo y lentamente lo cambie. Tendrá que trabajar en pequeños pasos y registrarse con frecuencia para evitar conflictos masivos de fusión, que es uno de los mayores problemas que tendrá que trabajar en contra. En un equipo de ese tamaño nunca podrás verificar todo y mágicamente mejorarlo para ellos. Es posible que desee que la gente sepa con anticipación qué va a hacer. (que siempre debe planificar lo que hace antes de hacerlo de todos modos). Si otras personas están trabajando en ello, avíseles qué va a cambiar y cómo afectará la class, etc.

Lo más importante que tendrá que averiguar antes de comenzar a tratar es si la gente está a bordo con usted. Si no, podría ser una causa perdida y causará conflictos. En este caso, un código incorrecto y un equipo en funcionamiento que comprenda el desorder tal como está podrían ser mejores que el código refactorizado. Sé que esto es contrario a la intuición, pero un jefe en mi antiguo trabajo lo expresó de esta manera. Dijo que el código es horrible, pero funciona, y los desarrolladores aquí saben cómo funciona, y eso significa que las 1000 personas que lo usan pueden hacer su trabajo, lo que significa que podemos mantener el nuestro. Odiamos el código y queríamos cambiarlo, pero tenía razón.