¿Cómo administra la refactorización con una base de código grande y muchos desarrolladores?

13

Me gustaría evitar una situación en la que dos desarrolladores refactorizan el mismo código simultáneamente sin hablar de ello primero, probablemente utilizando una herramienta de algún tipo, tal vez un complemento de Eclipse. ¿Puedes ayudar?

Tenemos 4.5 millones de líneas de código y más de 20 equipos de desarrolladores en cuatro continentes.

Idealmente, me gustaría que el segundo de los desarrolladores mencionados antes se diera cuenta de que alguien más está trabajando en el mismo código y hable con el primero antes de modificar cualquier cosa.

¿Conoces una solución?

    
pregunta Roger C S Wernersson 19.09.2011 - 10:09

7 respuestas

14

Muchos sistemas de control de origen de segunda generación funcionan con un "pago" conectado que informa al servidor que tiene la intención de modificar un archivo. Los ejemplos incluyen TFS, SourceGear Vault y muchos otros. De esta manera, puede técnicamente cumplir su requisito. Sin embargo, como señaló Adam Butler, estos tipos de herramientas vienen con sus propios problemas (sin entrar en un debate prolongado: soporte limitado para el trabajo fuera de línea y, en general, flujo de trabajo de desarrollo contraproducente).

Definitivamente sugeriría algún tipo de enfoque jerárquico para asignar el trabajo de refactorización. Los desarrolladores podrían ser agrupados lógicamente en sub-equipos, cada uno responsable de áreas específicas del código. Dependiendo de cómo desee estructurar los equipos, cada uno podría tener un rol de "líder" que sea responsable del diseño de alto nivel del área del equipo. Esta estructura debe ser bien conocida por los desarrolladores, y debe simplificar la comunicación para refactorizar. Estoy seguro de que este enfoque parece demasiado formal y al revés para algunos, pero creo que es muy preferible que más de 20 desarrolladores utilicen un enfoque "gratuito para todos" para refactorizar un sistema grande. Algunas refactorizaciones se llevarán a cabo en un nivel alto (por ejemplo, cómo se comunicará el módulo X con el módulo Y), en cuyo caso necesitará personas que puedan realizar llamadas al nivel adecuado. No todos los desarrolladores del equipo deben tomar decisiones arquitectónicas, por lo que en cualquier caso casi se impone una jerarquía, incluso si uno elige ignorarla.

Básicamente, hay herramientas para cumplir con los requisitos básicos que usted presenta, pero ninguna herramienta reemplazará las comunicaciones adecuadas y tendrá una pequeña cantidad de personas que impulsarán la arquitectura general de su proyecto.

    
respondido por el Daniel B 19.09.2011 - 11:33
7
  1. Asegúrese de que a los desarrolladores se les asignen módulos específicos.
  2. Tenga un sistema de seguimiento de errores / tareas que rastree cada cambio de refactorización. Asigna cada problema a un solo desarrollador
  3. Algunos sistemas de control de versiones tienen la capacidad de bloquear un archivo para que solo un desarrollador pueda tener derechos de actualización sobre el archivo. Nunca he usado esa función, pero si los desarrolladores están constantemente pasando el paso por encima de otros, esto es algo que deberías considerar.
  4. Realice pruebas unitarias para que incluso si los desarrolladores trabajan en el mismo archivo, saben que sus cambios no interrumpen la aplicación de ninguna manera.
  5. Todo lo anterior ayudaría si su refactorización se encuentra dentro de los módulos. Sin embargo, si alguien hace una refactorización en una cuestión transversal como el registro o la seguridad, afectará a muchos archivos por definición. Es necesario que se manejen con cuidado, especialmente si aún no se ha aprovechado de los mejores enfoques.
respondido por el Sriram 19.09.2011 - 11:37
6

Hay / eran sistemas de control de versiones que hacen que los desarrolladores comprueben el código antes de que puedan editarlo, pero estos tienen su propio conjunto de problemas. Una mejor práctica es lograr que los desarrolladores se comprometan y actualicen con frecuencia. Entonces, un desarrollador podría marcar una clase como depreciada y comprometerse si el otro desarrollador se actualiza antes de que comiencen su refactor, verán la intención.

    
respondido por el Adam Butler 19.09.2011 - 11:06
3

La tecnología no puede resolver problemas sociales. Necesitas que tus desarrolladores hablen entre sí y coordinen su trabajo. Con 20 equipos, alguna estructura y reglas serán esenciales. Querrá apoyarlos con soluciones tecnológicas, pero las personas son lo primero.

    
respondido por el quant_dev 19.09.2011 - 12:11
0

Si deja notice that someone else is working on the same piece of code and talk to the first one before modifying anything , según lo que dijo, necesita un sistema de control de versiones (CVS / SVN / GIT). Sin embargo, no estoy seguro, pero si también quieres incluir eso, necesitarás algunas cosas avanzadas (algún tipo de mecanismo de activación / quizás algo personalizado).

    
respondido por el c0da 19.09.2011 - 10:49
0

Los desarrolladores que bloquean archivos en el control de código fuente deben resolver su problema fácilmente, pero creo que podría tener problemas más grandes.

4.5 Million LOC's es un arenero masivo para jugar, por lo que, en una solución bien diseñada y diseñada, rara vez debería encontrarse en una situación en la que múltiples equipos de desarrolladores pisen los demás. El hecho de que esto suceda más que por casualidad es un indicio de algunas fallas de diseño que pueden ser investigadas.

    
respondido por el maple_shaft 19.09.2011 - 13:06
0

Algunas cosas:

  1. Módulos separados para trabajar
  2. Hablando de cambios antes de que se realicen [con todos los desarrolladores]
  3. Pruebas unitarias [para verificación y evitación para romper cosas relacionadas]
  4. Como los demás mencionaron un VCS
respondido por el monksy 19.09.2011 - 15:51

Lea otras preguntas en las etiquetas