refactoring - software - ¿Cuándo refactorizar el código?
refactorizar js (16)
¿Lo haces cuando estás en el código haciendo otra cosa?
Cuando su gerente lo aprueba? (Parece que esto nunca pasa)
Supongo que algo de esto depende del impacto de los cambios. Si cambio el código y no afecta a nada fuera de la clase, para mí eso es de bajo impacto.
¿En qué se convierte un cambio de diseño? ¿Cuándo se efectúa X objeto o X proyectos?
Sólo tengo curiosidad de cómo otros equipos abordan esto ...
A menudo refactorizo mi código cuando hay un cambio en los requisitos del usuario o correcciones de errores. Entonces habrá una oportunidad para que la gente revise sus cambios.
De lo contrario, normalmente no toco el código viable, incluso huele.
Descubrimos que las refactorizaciones pequeñas se hacen mejor mientras estábamos trabajando en un poco de código; haga lo que se requiera, preferiblemente emparejadas.
Para cosas más grandes, teníamos una sección de Deuda Técnica en el muro: si veías algo y no teníamos tiempo para resolverlo o si iba a tomar alguna discusión para resolverlo, lo agregarías al muro y sería programado para futuras iteraciones (o cuando el tiempo libre se acumulara).
Encuentro un refactor cuando reviso el código (probablemente para agregar / extender la funcionalidad) más de 3 meses después de que fue escrito.
Si me lleva más de 2 minutos discernir qué está haciendo un trozo de código, lo separaré para hacerlo más comprensible de inmediato (o simplemente agregar algunos comentarios más).
Insuficientemente a menudo, acumulando así deuda técnica.
Triste, pero es así.
Haz lo que digo, no como el equipo en el que trabajo.
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 debido a (inserta la fealdad aquí)". Esta es una señal de que el código debe ser refactorizado justo después de que se realiza la revisión.
Nos refactorizamos tan a menudo como podemos. Tener pruebas unitarias para garantizar que todo funcione antes y después de la refactorización realmente ayuda.
Para observar a nuestra compañía, hemos decidido que la próxima versión de nuestra aplicación está dedicada principalmente a las optimizaciones de rendimiento en lugar de nuevas funcionalidades. Esto era algo que sentíamos que era necesario y también fue solicitado por algunos clientes. Por lo tanto, hemos dedicado mucho tiempo a identificar cuellos de botella en el rendimiento de nuestra aplicación, a revisar el código y a refactorizarlo para que todo funcione más rápido.
Entonces, en nuestro caso, lo hicimos porque la gerencia nos aprobó hacerlo para esta nueva versión, porque les mostramos cuánta mejora de rendimiento se podía obtener.
Parece que la mayoría de los otros carteles son resistentes a refacotring mercilessly . Por supuesto, esto no es posible si el sistema en el que está trabajando no lo admite a través de pruebas unitarias exhaustivas. Pero en general, si puedo ver una oportunidad para hacer el código más estricto sin gastar más de unos pocos minutos u horas a lo sumo, lo hago. Si no estoy seguro de en qué debería estar trabajando, busco algo para refactorizar.
Refactor cuando sea necesario:
- cuando necesita una mejor comprensión del código en el que está trabajando (el emparejamiento a menudo ayuda aquí), los ejemplos son: cambio de nombre, extracción de métodos, etc.
- cuando el diseño actual no permite un cambio ''limpio'': en este punto, puede discutir con su gerente sobre una base de valor (por ejemplo, ¿cuál es el valor de esta nueva característica para el proyecto)?
Refactorizar mientras ya está en el código es a veces más fácil, especialmente si su gerente no apoya la iniciativa, pero si solo cambia una pequeña parte, se romperá la coherencia con las partes circundantes. En estos casos, es mejor ser selectivo y, como sugirió, hacer cosas de bajo impacto. También puede ser útil refactorizar las declaraciones largas de selección / cambio en funciones y retrasar la refactorización del código interno hasta algún momento más tarde.
En un trabajo anterior, yo era el gerente, así que lo reformulé cuando quise. En mi trabajo actual, soy un analista, por lo que la mayoría del código no es directamente mi responsabilidad. Cuando escribo código, evito impactar cualquier cosa que no esté escribiendo. Tengo un proyecto que está totalmente bajo mi control y lo refactorizo cada vez que aprendo una mejor manera de hacer algo.
Refactorizo cuando estoy corrigiendo un error o agregando una característica y el proceso de refactorización hace que el código sea más fácil de leer y de mantener.
Seguir los principios de DRY vehemencia a menudo será un desencadenante para que me refactorice.
Siempre estoy haciendo pequeñas refactorizaciones en mi código. Sé que mientras tenga mis pruebas unitarias para verificar que todo sigue funcionando correctamente después, no veo ningún daño en hacerlo a medida que avanzo. De esa manera, no tendrá esa vaga sensación de "refactorización" cada vez que trabaje en ello.
Ahora, si requiere una gran refactorización, es mejor planear eso y reservar algo de tiempo.
Trabajo en un sistema grande, así que solo cambio las cosas que tengo que hacer. Es fácil tener efectos secundarios negativos a los cambios.
Refactorizaré las secciones de código que tienen un rendimiento deficiente, no funcionan correctamente o necesitan una nueva funcionalidad.
Nunca solo decido arreglar las cosas, nunca se haría. si funciona, y nadie está pidiendo cambios o quejándose de problemas, siga adelante. La vida es demasiado corta para arreglar todo.
tan pronto como todas las pruebas se ejecuten.
- Como parte del desarrollo original (rojo / verde / refactor)
- Cuando sea sugerido por un revisor de código
- Cuando hemos notado un punto de dolor de diseño.
- Al realizar otro cambio, si la refactorización es de bajo impacto, es decir, normalmente no afecta a ningún otro archivo.
Si afecta a la API pública, generalmente me gusta hacer que la refactorización sea una única confirmación de código fuente que no cambie el comportamiento (y luego genere una nueva conducta en otra confirmación). Si también afecta a otros proyectos, es necesario que exista un consenso al respecto y me gustaría obtener permiso para cambiar su código para que entren en el mismo compromiso de refactorización.