¿Cómo justifica el trabajo de Refactorización para su jefe de pellizco?

Question

Acaba de escribir un montón 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 dice a su jefe que va a necesitar una semana para limpiar todo esto.

"¿Limpiar qué?"

"Mi código - ¡es una porqueriza!"

"¿Quieres decir que hay algo más para corregir errores?"

"En realidad no, es más como .."

"Vas a hacer correr más rápido?"

"Tal vez, peros eso no es .."

"Entonces usted debe haber escrito correctamente cuando tuvo la oportunidad. Ahora estoy feliz de que estés aquí, sí, voy a tener que ir adelante y pedirle que venga en este fin de semana .. "

he leído el libro de Matin Fowler, pero no estoy seguro estoy de acuerdo con su consejo sobre este asunto:

• Fomentar las revisiones de código regulares, por lo tanto, se alienta el trabajo de refactorización como parte natural del proceso de desarrollo.
• Simplemente no lo diga, usted es el desarrollador y forma parte de su deber.

Ambos métodos se salen de la necesidad de comunicarse con su gerente.

¿Qué le dices a tu jefe?

Answer 1

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 desorden, entonces tendrás que explicarle al jefe que el último grupo de programadores apurados para 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 se hace hasta que esté hecho.

Answer 2

Lie. 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 down modding/marcado ofensivo.

En realidad, si se trata de un jefe pellizco, que no entiende un buen software de software barato, lo que no sabe en última instancia, 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.

Answer 3

Refactorización debe hacer todo el tiempo ... por lo que no debería tener que justificarlo.

La limpieza de un gran desorden/Rediseño pueden incluir refactorización con el fin de ponerlo bajo control, sin embargo no es "Refactoring"

Refactoring debería ser una cuestión de momentos ... o si no tiene el apoyo de herramientas, minutos .

Answer 4

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.

Otra cosa que le dice a su jefe es que está reduciendo el costo para realizar mejoras en el futuro.

Answer 5

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 es asumiendo que está refactorizando por una razón y no por la vanidad del programador.

Answer 6

Simplemente hazlo y programalo en tu proceso normal. Estime el tiempo de refactorización para comenzar un nuevo cambio o terminar un cambio (ideal). Siempre me refactorizo ​​cuando inicialmente estoy explorando nuevos códigos (métodos de extracción, etc.).

Answer 7

Hable en un idioma que pueda entender.

Refactorización está pagando 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 frente a no pagar hasta que haya un aviso de cobranza. Dígale que la refacturación es como hacer su pago mensual.

Answer 8

Menos dinero ahora para mí ... refactorizar

o más dinero más tarde para arreglar lo que va mal y para mí refactorizar.

Answer 9

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 funciones añadidas en el mismo marco de tiempo que el código mal mantenido.

¿Su Boss tiene características similares? Claro, todos lo hacen. Si mejora el mantenimiento del código, más funciones podrá ofrecer con ese presupuesto limitado.

Answer 10

A veces, es hora de conseguir un nuevo empleo. 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 su jefe. Hpefully él o ella es razonable.

Answer 11

No ... solo consigue un nuevo trabajo en un lugar que esté más en sincronía contigo.

Answer 12

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.

Answer 13

Si su jefe no entiende la necesidad de refactorizar o limpiar el código, entonces debe preguntarse si tiene suficientes conocimientos de ingeniería para ser un gerente de ingeniería.

Answer 14

Es raro encontrar un jefe que le dé tiempo para refactorizar ... solo hágalo a medida que avance.

Answer 15

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 refacturar la complejidad, está mejorando la transparencia del código, reduciendo la probabilidad de errores desconocidos/difíciles y facilitando su mantenimiento (por ejemplo, un programador de mantenimiento puede tener un ámbito de mantenimiento más amplio debido a esto).

Además, puede hacer que el caso (si no es un producto muerto en el ciclo de mantenimiento) que la complejidad disminuye hace que la aplicación sea más fácil de ampliar cuando se agregan nuevos requisitos al proyecto.

Answer 16

El jefe tiene que confiar en el desarrollador para tomar decisiones técnicas correctas (incluso cuándo refactorizar).

Establezca esa confianza o reemplace el jefe o reemplace el dev.

Answer 17

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 sí 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).

Answer 18

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ápido y disminuir la probabilidad de nuevos errores porque el código tiene un mejor orden y estructura, e incluso es posible realice algunas mejoras de velocidad porque puede inspeccionar el código más fácilmente que antes.

Cuando los chicos de negocios entiendan eso, si son inteligentes, lo alentarán a que realice un proceso de reconstrucción constante.

Puede explicar eso con una metáfora del edificio. 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.