¿Lo haces cuando estás en el código haciendo otra cosa?¿Cuándo se refactoriza el código?
¿Cuando su gerente lo aprueba? (Parece que esto nunca sucede)
Supongo que parte de esto depende del impacto de los cambios. Si cambio el código y no afecta nada fuera de la clase, para mí eso es de bajo impacto.
¿Qué se convierte en un cambio de diseño? ¿Cuándo tiene efecto X objeto o X proyectos?
Tengo curiosidad de cómo otros equipos frente a este ...
Si afecta a la API pública, que por lo general gusta hacer la refactorización un único código fuente cometer que no cambia el comportamiento (y luego construir un nuevo comportamiento en otro commit). Si también afecta a otros proyectos, es necesario que exista un consenso al respecto y desearía obtener permiso para cambiar su código y pasar a la misma confirmación de refactorización.
¿Cuándo se revisa el código? –
antes de que se haya cometido. –
La fusión del código completo también es un factor, pero no pregunté sobre eso. – eschneider
Nos refactorizar tan a menudo como sea posible. Tener pruebas unitarias para garantizar que todo funcione antes y después de la refactorización realmente ayuda.
Los procesos de revisión de código a menudo ayudan con esto. Si toco algún código, se revisa, el revisor pregunta, "¿por qué lo hiciste de esta manera?", Le digo: "tuve que hacerlo por (inserte la fealdad aquí)". Esta es una señal de que el código debe refactorizarse justo después de que se realice la revisión.
La refacturación mientras usted ya está en el código es a veces más fácil, especialmente si su gerente no admite la iniciativa, pero si solo cambia una parte pequeña, romperá la consistencia con las partes circundantes. En estos casos, es mejor ser selectivo y, como sugirió, hacer cosas que sean de bajo impacto. También puede ser útil refactorizar las sentencias de selección/conmutación largas en funciones y retrasar la refactorización del código interno hasta algún tiempo después.
En un trabajo anterior, yo era el gerente, así que refactorizaba siempre que quería. En mi trabajo actual, soy analista, por lo que la mayoría del código no es directamente responsabilidad mía. Cuando escribo el código, evito afectar todo lo que no estoy escribiendo. Tengo un proyecto que está completamente bajo mi propio control y me refactorio cada vez que aprendo una mejor manera de hacer algo.
Encontrar soporte puede ser difícil, vender la limpieza a un gerente no desarrollador o CEO es difícil. Incluso he tenido discusiones con otros desarrolladores porque están fusionando el código. – eschneider
Trabajo en un sistema grande, así que solo cambio las cosas que tengo que hacer. Es fácil tener malos efectos secundarios a los cambios.
Voy a refactorizar secciones de código que funcionan mal, no funcionan correctamente o necesitan nuevas funcionalidades.
Nunca decido arreglar las cosas, nunca terminaré. si funciona, y nadie está pidiendo cambios o quejándose de problemas, sigue. la vida es demasiado corta para arreglar todo.
A menudo refactorizo mi código cuando hay un cambio en el requisito del usuario o correcciones de errores. Luego habrá una oportunidad para que las personas revisen sus cambios.
De lo contrario, normalmente no toco el código viable incluso huele.
a mirar nuestra empresa, hemos decidido que nuestra versión de la aplicación próxima es en su mayoría dedicada a la optimización del rendimiento en lugar de nuevas funcionalidades. Esto fue algo que sentimos que era necesario y también fue solicitado por algunos clientes. Por lo tanto, hemos dedicado mucho tiempo a identificar los cuellos de botella de rendimiento en nuestra aplicación y revisar el código y refactorizarlo para que las cosas funcionen más rápido.
Así que en nuestro caso lo hicimos porque nos aprobó la gestión haciendo por esta nueva versión, porque hemos demostrado a lo mucho la mejora del rendimiento podría obtenerse.
Refactor cuando sea necesario:
Siempre estoy haciendo pequeñas refactorizaciones en mi código. Sé que siempre y cuando tenga mis pruebas de unidad para verificar que todo sigue funcionando correctamente después, no veo ningún daño en hacerlo a medida que avanzo. De esta forma no obtendrás ese vago sentimiento de "necesidad de refactorización" cada vez que trabajas en él.
Ahora bien, si se requiere una gran refactorización, lo mejor es planear para eso y dejar de lado algún tiempo.
parece que la mayoría de otros carteles son resistentes a refacotringmercilessly. Por supuesto, esto no es posible si el sistema en el que está trabajando no es compatible con pruebas exhaustivas de la unidad. Pero, en general, si puedo ver la oportunidad de ajustar el código sin pasar más de unos minutos u horas como máximo, lo hago. Si no estoy seguro de en qué debería estar trabajando, busco algo para refactorizar.
Encontramos pequeñas refactorizaciones se realizan mejor mientras estábamos trabajando en un poco de código - hacer lo que se requiere, preferiblemente emparejados.
Para cosas más grandes, teníamos una sección de Deuda técnica en la pared: si detectaba algo y no tenía tiempo para abordarlo, o iba a necesitar un poco de discusión para resolverlo, lo agregaría a el muro y se programarían para futuras iteraciones (o cuando se produzca el tiempo libre).
que refactorizar cuando estoy corregir un fallo o la adición de una característica y el proceso de refactorización hace que el código sea más fácil de leer y fácil de mantener.
Siguiendo DRY principios vehementemente a menudo ser un disparador para mí refactorizar.
insuficientemente menudo, construyendo así la deuda técnica.
Triste, pero tan.
Haz lo que digo, no como el equipo de trabajo en sí.
encuentro que refactorizar al Revisando código (presumiblemente para añadir/ampliar la funcionalidad) más de 3 meses después de ser escrita.
Si me toma más de 2 minutos para discernir lo que es un trozo de código está haciendo, voy a romper aparte para que sea más comprensible de inmediato (o simplemente añadir más comentarios.)
Me gusta esta respuesta. Iba a sugerir cuando la cantidad de código reutilizado está por debajo de cierto nivel. 3 meses es tiempo más que suficiente. – monksy
tan pronto como sea todas las pruebas se ejecutan.
Interesante pregunta. +1 – shahkalpesh