¿Existe una función de "grupo de refactorización / mantenimiento" en las empresas de software?

Entonces, trabajo en una empresa que realiza desarrollo de software integrado, otros grupos se centran en el desarrollo central del software de diferentes productos y mi departamento (que se encuentra en otra ubicación geográfica) que se encuentra en la fábrica también tiene que ocuparse del desarrollo de software , pero en todos los productos, para que también podamos arreglar las cosas más rápido cuando las líneas caen debido a problemas de software con el producto.

En otras palabras, somos generalistas, mientras que otros grupos se especializan en cada producto.

La cuestión es que es un poco difícil involucrarse en el desarrollo central cuando se distribuye geográficamente (bueno, sé que realmente no es tan difícil, pero puede haber barreras culturales / políticas involuntarias cuando se trata de la disciplina de colaborar remotamente )

Así que pensé que, dado que actualmente solo estamos apagando incendios y de alguna manera estamos inactivos / subutilizados (a pesar de que somos un departamento nuevo, o tal vez esa es la razón), pensé que un buen papel para nosotros podría ser detectar áreas de oportunidad de refactorizar y volver a armar el código y todas las demás implementaciones que podrían tener que ver con la administración de la capacidad de mantenimiento y la modularidad. Otros grupos no están enfocados en esto porque no tienen el tiempo y tienen plazos agresivos, lo que daña la calidad del código (historia eterna de proyectos de software)

La cuestión es que quiero que mi grupo / departamento sea reconocido por la gerencia y otros grupos con este rol oficialmente, y estoy teniendo problemas para encontrar una buena definición / identidad de nuestro grupo para este asunto.

Entonces mi pregunta es: ¿es este papel algo que ya existe ?, ¿o soy el primero en inventar algo como esto?

Editar : Lo que quiero decir es que un grupo impulsa iniciativas de refactorización, no realiza todo el trabajo de refactorización. Al igual que una comunidad de código abierto a un producto de código abierto, ahora que lo pienso.

Nunca he oído hablar de tal cosa en ninguna compañía para la que he trabajado o entrevistado. Normalmente, las empresas solo desean pagar por nuevas funciones o cambios que tengan mejoras cuantificables para los usuarios finales (como las mejoras de rendimiento). Refactorizar el código no hace esto de una manera directamente medible.

Lo que he presenciado en compañías que sí entienden y se preocupan por la calidad del código es que se alienta a los desarrolladores a refactorizar el código a medida que trabajan. Si de todos modos va a hacer un cambio en un archivo, es mejor que lo limpie mientras está allí. Agregue pruebas unitarias, refactorice, ejecute una herramienta de análisis estático, etc.

Esto tiene dos propósitos. Primero, el código se mejora activamente con el tiempo sin delegar esa tarea exclusivamente a ningún desarrollador. En segundo lugar, solo se dedica tiempo a mejorar el código que de todos modos necesitaba ser cambiado. Si tiene módulos de código que nunca volverán a ser tocados, no tiene mucho sentido perder tiempo en mantenerlos. No lo van a necesitar. Es mejor pasar menos tiempo refactorizando solo los módulos que tienen más probabilidades de cambiar en el futuro.

Si un programador sabe que alguien más refactorizará su código, NUNCA se molestará en refactorizar su propio trabajo. Configurar un equipo separado para refactorizar es como justificar el código de baja calidad existente en primer lugar. Es como reconocer que habrá problemas y luego modificar la estructura organizativa de su empresa para atenderla. Admiro tu pasión por el código de calidad, pero tal vez en este caso es mejor decir "no es mi trabajo". La refactorización debe ser realizada por el programador que escribe el código, no por un tercero que no lo escribió.

Señor no, no hagas esto. piensa en estar en la otra posición: escribes código, lo confirmas, haces otro trabajo, luego se te pide que hagas algunas correcciones de errores en tu código, para que notes que se ha actualizado, échale un vistazo y comprueba que lleva sin semejanza con lo que escribiste originalmente.

También pierde mucha trazabilidad en el SCM: todos esos métodos movidos y renombrados significan que el código con el que termina no tiene rastro directo al original, a menudo parece demasiado cambiado para usar los diferenciales.

así que todo lo que estás haciendo es cabrear a la gente para que abras y hagas clic en algunas herramientas de refactorización en tu IDE, y luego les digas a los otros codificadores que lo has mejorado para ellos. Algo así como Slashdot donde ocasionalmente obtienes personas que responden respuestas sarcásticas a tu publicación con "ahí, lo arreglaste por ti". Podría estar bien si es chistoso en /., No lo sería si lo hicieras con mi código; te diría que es tuyo y que puedes realizar el mantenimiento en él.

Ahora, si está haciendo un trabajo real en el código, eso es diferente, pero refactorizar por sí mismo, incluso bajo la guía de "mantenimiento", va a molestar a todos los demás, y eso es doble para el "quiero mi grupo / departamento ser reconocido oficialmente por la gerencia y otros grupos con este rol ", ¿puede decir" maniobras políticas "? ¿Te imaginas lo que dirán los otros departamentos cuando su código falla en el sitio del cliente? "Estuvo bien cuando lo tocamos por última vez, debe haber sido el departamento de refactorización quien lo rompió, lo tocaron por última vez".

Lo que podría intentar es convencer a la gerencia de que varias partes del software necesitan más atención, mostrar las partes pobres y ver si dedicarán tiempo a mejorarlo. Mientras esto sucede, puede sugerirle que agregue algunas de las cargas de trabajo de otros grupos principales para agregar características al producto principal. Dudo que llegue a tratar de volver a implementar la funcionalidad principal para ellos, pero aumentará la capacidad de sus departamentos para agregar características que se puedan insertar nuevamente en el grupo central, y luego tendrá más responsabilidad de desarrollo.

Depende de lo que realmente quiere decir con refactorización y mantenibilidad, tanto en teoría como en la práctica.

Solíamos tener un grupo dedicado a la limpieza de código y corrección de errores. No funcionó tan bien porque, como era de esperar, los buenos desarrolladores no quieren pasar todo su tiempo haciendo limpieza de código y corrección de errores.

Algunas organizaciones optan por tener un equipo dedicado de "ingeniería de software" que tenderá a pasar una buena cantidad de tiempo en la revisión del código y asesorará a los desarrolladores menos experimentados sobre las buenas prácticas. Sin embargo, este no es un verdadero grupo de ingeniería a menos que esté muy involucrado en los planes del proyecto, la arquitectura, los planes de prueba, el proceso de lanzamiento, etc. Es crítico tener este enfoque holístico, y preferiblemente cierta cantidad de capacitación en software u otra ingeniería, de lo contrario, tiende a convertirse en la "limpieza" anterior.

En pocas palabras, los desarrolladores no son buenos conserjes a largo plazo. E incluso si tiene un verdadero grupo de ingeniería, ese enfoque tiende a funcionar mejor con equipos multifuncionales, de lo contrario, otros equipos pueden comenzar a ignorar o incluso resentir el esfuerzo, viéndolo como una torre de marfil.

No tenga una sala llena de desarrolladores que no hagan nada más que refactorizar y volver a armar. No terminará bien.

Por lo general, cuando las personas refactorizan, todos lo hacen con refactorización oportunista . Así que no creo que encuentres un nombre común para una práctica tan poco común.

Pero en su situación inusual, aunque tener a todos refactorizando probablemente sería lo ideal, parece que tendría sentido intentarlo.

Sin embargo, los mismos problemas políticos que actualmente impiden que las personas refactoricen su propio código probablemente también lo derribarán (lo que probablemente sea parte de por qué no hay un nombre para lo que está pensando). ¿Otros equipos estarán de acuerdo con que "mejore" su código? ¿Qué sucede la primera vez que introduces un error al hacer algo que la administración no percibe como tan valiosa en primer lugar? ¿Qué sucede cuando a otro equipo no le gusta tu nuevo diseño?

No puede garantizar que nunca le costará a otro equipo algún tiempo. Y casi cualquier argumento de que tendrá un efecto positivo neto también podría aplicarse para permitirles refactorizar ellos mismos.

Es posible que lo que está proponiendo sea aceptable, pero dejar que todos los demás refactoricen no lo será, pero la única forma en que puedo imaginar que esto suceda es si básicamente todos están de acuerdo en que refactorizar es algo bueno que ahorra tiempo a largo plazo pero toma tiempo en a corto plazo, y que su equipo es el único con suficiente tiempo libre a corto plazo. Y si otros equipos confían en usted para hacer las refactorizaciones y están dispuestos a lidiar con cualquier problema que les cause.

Tener un grupo que se centre únicamente en la refactorización y la mantenibilidad e implementarlo a expensas de otros grupos de desarrollo es peligroso para su organización. Es necesario que exista un compromiso por parte de la alta gerencia, los probadores y todos los grupos de desarrollo para mejorar la calidad del código mediante la refactorización para mejorar la capacidad de mantenimiento y minimizar los errores. Debería ser responsabilidad de todos mejorar el código. Cuando se necesita refactorizar, se debe incluir en el programa de lanzamiento junto con las nuevas funciones. Los gerentes deben ser educados y comprender que tomarse el tiempo para mejorar el código valdrá la pena a largo plazo, porque la deuda técnica es lo que hará que un producto se detenga si no se paga como parte del proceso de desarrollo en curso. Si todo lo que está haciendo es combatir constantemente los incendios debido a la constante corrección de errores,

Su grupo suena más como si fuera un grupo de personal de arquitectura / software dedicado al desarrollo de la arquitectura de la próxima generación que será más fácil de mantener. Su grupo probablemente debería centrarse en cómo demostrar que la refactorización vale la pena para los tipos de "cabello puntiagudo", alentar a los desarrolladores con nuevos métodos y procesos, y educar a las partes interesadas clave en la administración para que adopten una mejor calidad de código y los lleven a "comprar" al proceso Cree un plan para migrar productos a una mejor arquitectura, si acaso, estableciendo primero una base simple. Tome las dolorosas lecciones que todos han estado aprendiendo al apoyar sus productos y elabore un plan para mitigar ese dolor en el futuro.

Es bastante común. He trabajado en una empresa de software donde esta era la norma. Tenías equipos dedicados a implementar nuevas funcionalidades. Luego hubo un equipo de mantenimiento que corrigió errores que causaban problemas a los clientes. El equipo de mantenimiento cayó bajo la rama de consultoría / soporte de la organización.

En ese caso, hubo beneficios para los desarrolladores, es decir, trabajaron más estrechamente con los clientes, incluso pasando tiempo en el sitio. Los equipos de productos que realizan nuevos desarrollos no interactuaron con los clientes en absoluto (una situación odiosa en mi opinión).

Parece más común en compañías de software y proveedores externos que para la provisión interna. Estoy en finanzas y solo puedo pensar en un banco que haya usado esta estructura en el pasado. Dicho esto, es común que los equipos tácticos puedan abordar ese tipo de problemas como parte de su cometido. No es exactamente lo mismo, pero similar.

Si su equipo está siendo subutilizado, debe tener un poco de cuidado. La infrautilización puede traducirse en "costo innecesario" con bastante facilidad, por lo que su equipo de X puede convertirse en un equipo de X-1 con bastante rapidez.

Un enfoque preferible podría ser dedicar un poco más de tiempo a las correcciones e incorporar un tiempo de refactorización no escrito en el tiempo de corrección de errores.

Sin embargo, depende de cómo funcione su empresa. Lo interesante es que realmente no lo sabes, así que si tienes un equipo líder, valdría la pena discutirlo con ellos. Si no lo saben, pídales que hablen con la siguiente persona en la cadena (participe en eso, no lo entregue). Si no saben si eso encajaría con lo que la gerencia espera, podría caer más en la categoría de costos en lugar de la categoría de activos.