refactoring - refactory - ¿Cómo justificas el trabajo de Refactorización para tu jefe que pellizca penique?
refactorizar sinonimo (18)
Acabas de escribir una pila de código para entregar alguna característica importante bajo presión. Ha cortado algunas esquinas, ha purgado un poco de código en algunas clases sobrecargadas con nombres como SerialIndirectionShutoffManager.
Le dices a tu jefe que vas a necesitar una semana para limpiar todo esto.
"¿Limpiar qué?"
"Mi código - ¡es una porqueriza!"
"¿Quieres decir que hay algo más para arreglar errores?"
"No realmente, es más como ..."
"¿Vas a hacer que funcione más rápido?"
"Tal vez, pero eso no es ..."
"Entonces deberías haberlo escrito correctamente cuando tuviste la oportunidad. Ahora me alegro de que estés aquí, sí, voy a tener que ir y pedirte que vengas este fin de semana ..."
He leído el libro de Matin Fowler, pero no estoy seguro de estar de acuerdo con su consejo sobre este asunto:
- Aliente las revisiones regulares de los códigos, por lo que se recomienda el trabajo de refactorización como parte natural del proceso de desarrollo.
- Simplemente no lo diga, usted es el desarrollador y es parte de su deber.
Ambos métodos se salen de la necesidad de comunicarse con su gerente.
¿Qué le dices a tu jefe?
A veces, es el momento de obtener un nuevo trabajo. Hay personas certeros que solo quieren que "lo hagas". Si alguna vez estás en una de esas situaciones, y he estado allí, entonces simplemente vete.
Pero sí, todo lo demás sobre los costos futuros y demás es una buena idea. Simplemente creo que la mayoría de los jefes se mienten a sí mismos porque quieren lo que quieren cuando lo quieren y simplemente no pueden ver lo que sucederá en el futuro.
Entonces, buena suerte con tu jefe. Hpefully él o ella es razonable.
Ahora tengo menos dinero para refactorizar ...
o más dinero más tarde para arreglar lo que vaya mal y para que yo refactorice.
Creo que deberías empezar a trabajar en él sin decírselo a tu jefe. Esta es realmente la forma en que hice mi mejor trabajo. Simplemente no le digo a mi jefe lo que estoy haciendo y poco a poco reemplazo el código malo / heredado cuando tengo tiempo.
Me ha salvado el culo en más de una ocasión.
Dígale que el 80% de los costos asociados con un proyecto de software viene en la fase de mantenimiento del ciclo de vida. Cualquier refactorización que se haga ahora para aliviar problemas futuros y tenga algunos ejemplos generará sustanciales beneficios de costos más adelante cuando surja la necesidad de mantener ese código.
Esto supone que estás refacturando por una razón y no por la vanidad del programador.
El jefe debe confiar en el desarrollador para tomar decisiones técnicas correctas (incluso cuándo refactorizar).
Establezca esa confianza o reemplace al jefe o reemplace al desarrollador.
En uno de los libros recientes de Robert Glass (tendré que buscar la referencia) mencionó un estudio sobre el costo del código bien mantenido. Lo que encontraron es que el código bien mantenido fue editado con más frecuencia que el código mal mantenido. Eso suena contra intuitivo, pero cuando cavaron más profundo descubrieron la razón:
El código bien mantenido tiene más características añadidas a él en el mismo marco de tiempo que el código mal mantenido.
¿Tu jefe tiene características? Claro, todos lo hacen. Si mejora el mantenimiento del código, más funciones podrá ofrecer con ese presupuesto limitado.
Es importante incluir el tiempo de refactorización en sus estimaciones originales. Dirigirse a su jefe después de haber entregado el producto y luego decirle que en realidad no lo hizo, es mentir sobre haberlo hecho. En realidad, no llegó a la fecha límite del entregable. Es como un cirujano que hace una cirugía y luego no se asegura de que vuelva a colocar todo como se suponía.
Es importante incluir todas las partes del desarrollo (por ejemplo, refactorización, investigación de usabilidad, pruebas, control de calidad, revisiones) en sus programaciones originales. En última instancia, esto no es tanto un problema de gestión como un problema de programador.
Si, sin embargo, has heredado un desastre, entonces tendrás que explicarle al jefe que el último grupo de programadores apurados por sacar el proyecto de la puerta cortó las esquinas y que ha estado cojeando. Puedes vencer el problema por un tiempo (como probablemente lo hicieron), pero cada tirita retrasa el problema y finalmente hace que el problema sea mucho más costoso de arreglar.
Sea honesto con su jefe y entienda que un proyecto no está terminado hasta que esté listo.
Es raro encontrar un jefe que le dé tiempo para refactorizar ... solo hágalo a medida que avanza.
Habla en un idioma que pueda entender.
Refactorizar es pagar deuda de diseño.
Pregúntele a su jefe por qué paga la factura de la tarjeta de crédito de la empresa todos los meses y no paga hasta que haya un aviso de cobranza. Dígale que la refacturación es como hacer su pago mensual.
Me gusta la respuesta dada en "Refactoring" por Martin Fowler. Dígale a su jefe que va a desarrollar software de la manera más rápida que sepa cómo hacerlo. Sucede que en la mayoría de los casos, la manera más rápida de desarrollar software es refactorizar sobre la marcha.
La otra cosa para decirle a su jefe es que está reduciendo el costo para hacer mejoras futuras.
Mentira. Dile que es una investigación sobre una nueva tecnología. Luego dígale que decidió que el costo no justificaba los beneficios. Él pensará que hiciste un gran trabajo.
lol @ people modding / marcado ofensivo.
En realidad, si se trata de un jefe que pellizca penique, que no entiende un buen software de software barato, lo que no sabe finalmente lo hará más feliz. si fuera yo, me iría de la compañía e iría a un lugar donde respetaran la capacidad de sus desarrolladores para escribir un buen código. Pero, de nuevo, esta es la razón por la cual estoy en una posición superior.
No ... solo consigue un nuevo trabajo en un lugar que esté más sincronizado contigo.
Refactorizar debe hacer todo el tiempo ... por lo que no debería tener que justificarlo.
La limpieza de grandes problemas / Rediseño puede incluir refactorización para controlarla, pero no es "Refactorización"
Refactorizar debería ser una cuestión de momentos ... o si no tiene soporte de herramientas, minutos.
Si su jefe no entiende la necesidad de refactorizar o limpiar el código, entonces debe preguntarse si tiene suficiente conocimiento de ingeniería para ser un gerente de ingeniería.
Solo hazlo y programalo en tu proceso normal. Estime el tiempo de refactorización para comenzar un nuevo cambio o terminar un cambio (ideal). Siempre refactorizo cuando inicialmente estoy explorando un nuevo código (métodos de extracción, etc.).
En mi opinión, el caso más simple para refactorizar es la fijación de código demasiado complejo. Mida la complejidad ciclomática de McCabe del código fuente en cuestión (Source Monitor es una excelente herramienta para tal problema). El código fuente con alta complejidad ciclomática tiene fuertes defectos de correlación y malas soluciones. Lo que esto significa en términos simples es que el código complejo es más difícil de corregir y más propenso a tener malas soluciones. Lo que esto significa para un gerente es que la calidad del producto probablemente será peor y los errores más difíciles de solucionar, y el cronograma del proyecto empeorará. Sin embargo, al refactorizar la complejidad, está mejorando la transparencia del código, reduciendo la probabilidad de errores oscuros / difíciles y facilitando su mantenimiento (por ejemplo, un programador de mantenimiento puede tener un alcance de mantenimiento mayor debido a esto).
Además, puede argumentar (si no se trata de un producto muerto en el ciclo de mantenimiento) que la disminución de la complejidad hace que la aplicación sea más fácil de ampliar cuando se agregan nuevos requisitos al proyecto.
Otra buena analogía es el mantenimiento de un sitio de construcción ordenado. La única pega aquí es que un programador no representa a un trabajador de la construcción, y un gerente no representa a un capataz. Si ese fuera el caso, su contador de "hacerlo bien a la primera" se seguiría aplicando, ya que un trabajador de la construcción competente y consciente es responsable de mantener el buen orden en su espacio de trabajo a medida que avanzan.
Realmente el código mismo representa a los trabajadores, y el proceso de desarrollo es el capataz. El desorden es generado por varios comercios que se mueven entre sí (es decir, por diferentes características de código que interactúan, donde cada característica hace bien su trabajo, pero las costuras entre ellos están desorganizadas) y es limpiado por el capataz que toma una mano firme y vigilando dónde se está instalando el desorden y actuando para limpiarlo (es decir, el proceso de software que exige la refactorización).
Lo que acabo de hacer recientemente es explicarle a mi contraparte de negocios que el proceso de reingeniería ayuda a desarrollar nuevas características más rápidamente y disminuye la probabilidad de nuevos errores porque el código tiene un mejor orden y estructura, e incluso es posible hacer algunas mejoras de velocidad porque puedes inspeccionar el código más fácilmente que antes.
Cuando los chicos de negocios lo entiendan, si son inteligentes, lo alentarán a hacer un proceso de reconstrucción constante.
Puedes explicar eso con una metáfora de construcción. Si no haces refacción, terminarás con un edificio horrible con un núcleo malo, por lo que tendrás problemas con las tuberías, ventanas y puertas.