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

Me gustaría evitar una situación en la que dos desarrolladores refactoricen el mismo código simultáneamente sin hablar primero, probablemente utilizando una herramienta de algún tipo, tal vez un complemento Eclipse. ¿Puede usted 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 desarrollador mencionado anteriormente se dé 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?

Muchos sistemas de control de fuente de segunda generación funcionan utilizando un "checkout" 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, técnicamente puede cumplir con su requisito. Sin embargo, como señaló Adam Butler, este tipo de herramientas vienen con sus propios problemas (sin entrar en un largo debate: 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 agruparse lógicamente en sub-equipos, cada uno responsable de áreas específicas del código. Dependiendo de cómo le guste estructurar los equipos, cada uno podría tener un rol de "líder" responsable del diseño de alto nivel del área del equipo. Esta estructura debería ser bien conocida por los desarrolladores, y debería simplificar la comunicación para la refactorización. Estoy seguro de que este enfoque parece demasiado formal y al revés para algunos, pero creo que es preferible que más de 20 desarrolladores utilicen un enfoque "gratuito para todos" para refactorizar un sistema grande. Algunas refactorizaciones se realizarán a un alto nivel (por ejemplo, cómo se comunicará el módulo X con el módulo Y), en cuyo caso necesitará personas que puedan hacer llamadas al nivel apropiado. No todos los desarrolladores del equipo deberían tomar decisiones arquitectónicas, por lo que casi se impone una jerarquía en cualquier caso, incluso si se elige ignorarla.

Básicamente, existen herramientas para cumplir con los requisitos básicos que usted establece, pero ninguna herramienta reemplazará las comunicaciones adecuadas y tendrá un pequeño número de personas que dirigen la arquitectura general de su proyecto.

1. Asegúrese de que los desarrolladores tengan asignados módulos específicos.
2. Tenga un sistema de seguimiento de tareas / errores que rastree cada cambio de refactorización. Asigne 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 característica, pero si los desarrolladores están constantemente pisoteándose, esto es algo que quizás desee considerar.
4. Haga pruebas unitarias para que, incluso si los desarrolladores trabajan en el mismo archivo, sepa que sus cambios no rompen la aplicación de ninguna manera.
5. Todo lo anterior ayudaría si su refactorización está contenida dentro de los módulos. Sin embargo, si alguien realiza una refactorización en una cuestión transversal, como el registro o la seguridad, afectará a muchos archivos por definición. Es necesario manejarlos con cuidado, especialmente si aún no se ha aprovechado de los enfoques aop.

Existen / fueron sistemas de control de versiones que hacen que los desarrolladores revisen el código antes de que puedan editar, pero estos tienen su propio conjunto de problemas. Una mejor práctica es hacer que los desarrolladores se comprometan y actualicen con frecuencia. Un desarrollador podría marcar una clase como depreciada y comprometerse; si el otro desarrollador actualiza antes de comenzar su refactorización, verá la intención.

La tecnología no puede resolver problemas sociales. Debe hacer que sus desarrolladores se comuniquen entre sí y coordinen su trabajo. Con 20 equipos, algunas estructuras y reglas serán esenciales. Querrá apoyarlos con soluciones tecnológicas, pero las personas son lo primero.

Si se va 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 quieres incluir eso también, necesitarás algunas cosas avanzadas (algún tipo de mecanismo de activación / algo personalizado tal vez).

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

4.5 millones de LOC es un entorno de pruebas masivo para jugar, por lo que, en una solución bien diseñada y diseñada, rara vez se encontrará con una situación en la que varios equipos de desarrolladores se pisen los pies. El hecho de que esto suceda más que por casualidad es revelador de algunos defectos de diseño potenciales serios que deberían considerarse.

Unas pocas cosas:

1. Módulos separados para trabajar
2. Hablar sobre los cambios antes de que se realicen [con todos los desarrolladores]
3. Pruebas unitarias [para verificación y evitación de romper cosas relacionadas]
4. Como los otros mencionaron un VCS