sdlc - ingles - qué significa en español
Cómo convencer a la administración para que limpie el código después de publicarlo (11)
Los argumentos contrarios tienen algún sentido ... existe un riesgo asociado con los cambios, la necesidad de que el cliente interno vuelva a realizar las pruebas de aceptación.
Estos no solo tienen sentido, son argumentos mortales. Incluso si tuviera marcos de prueba decentes, etc., siempre existe el riesgo de que rompa algo al "limpiar" el código, y hay poco o ningún beneficio que obtener.
Si no se puede hacer bien la primera vez, entonces debe esperar las siguientes solicitudes de cambio y hacer el trabajo en ese momento. Por supuesto, puede seguir adelante, pero debe esperar la próxima versión y ejecutar nuevamente el proceso de lanzamiento.
editar: para ampliar esto, si tiene una solución de error o una solicitud de cambio, también puede limpiar el código en ese momento. Pero hasta que tengas eso, solo estás perdiendo el tiempo a menos que en realidad no tengas nada más que hacer, lo que parece poco probable.
En pocas palabras, si el código no estaba limpio en la versión 1, la limpieza solo puede ser parte de la versión 2. Y si no hay una versión 2, o si aún no tiene tiempo para trabajar en ella, puede hacerlo bien, olvídalo.
En uno de mis clientes, cada vez más a menudo me encuentro con la situación de que no tenemos tiempo para "limpiar" el código después de que hayamos comenzado. ¿Cómo podemos convencer a la gerencia de que esto sería tiempo y esfuerzo bien empleado?
Algunas explicaciones más: por lo general, hay una loca lucha para hacer que las cosas funcionen correctamente a tiempo, y después de que el cliente interno ha aceptado el código, normalmente me gustaría dedicarle algo de tiempo. Por ejemplo, hay problemas de manejo y cosas internas que al cliente interno realmente no le importan, pero estoy seguro de que estas cosas pagarán con el tiempo al hacer que el código sea más legible y fácil de entender, por lo que se pueden corregir errores que puedan aparecer. con el tiempo o los cambios que se requieren serán más fáciles de hacer.
Los argumentos contrarios tienen algún sentido. Existe el riesgo asociado con los cambios, la necesidad de que el cliente interno vuelva a realizar las pruebas de aceptación, generalmente con la seguridad de que nos ocuparemos de las cosas "la próxima vez" cuando tengamos que trabajar en el código.
Es realmente difícil, realmente increíblemente difícil. Pero lo mejor que puedes hacer es obtener el código correcto para empezar. Es posible que no haya tiempo después.
La pregunta que debe hacerse es por qué esto no se está haciendo mientras el código se está escribiendo la primera vez. Lo que debe hacer es planificar el tiempo en el lanzamiento para corregir el código que se está produciendo. Si la administración no le da más tiempo, entonces los procesos que los programadores siguen necesitan ser más eficientes. Esa es realmente la clave. Cosas como escribir especificaciones de antemano, planificar lo que se va a hacer antes de hacerlo, escribir pruebas de unidad y tener revisiones de código.
Sé que es una respuesta copout, pero realmente esa es la manera de hacerlo. La respuesta de que simplemente no hay tiempo para hacerlo es una especie de falacia, ya que es realmente "No tenemos tiempo para hacerlo de la misma forma que desarrollamos el software". ¿Eso significa que necesita tiempo para refactorizar todo lo que está escrito en ese momento? No, siempre habrá cosas que cambiar y hacer más eficientes, pero el código debe escribirse bien la primera vez, por lo que se necesita una pequeña cantidad de refactorización en el futuro.
La pregunta que debería poder responder antes de sugerir cualquier cambio es: "¿Cómo nos hace esto ganar dinero?" Si no hay una buena respuesta, es posible que un cambio no tenga realmente un buen caso comercial.
Como desarrolladores, siempre queremos mejorar el código, hacerlo más elegante, etc. Pero, muy pocos de nosotros tenemos el lujo de acercarnos a la programación como un arte en lugar de una herramienta comercial.
Para los cambios que tienen casos comerciales nebulosos, a menudo puede llegar a ellos como parte de una solución más grande con valor conocido.
Lamentablemente, no sé si a la Administración le importa qué tan legible es el código, o qué tan limpio es, o qué tan escalable es. Les importa si está funcionando o no. Y en muchos casos, está ganando dinero.
Una vez, un amigo mío esperaba golpear el muro de la administración en relación con la limpieza de la postproducción, por lo que plantó algunos comandos sleep () en la aplicación para hacer que se ejecutara lentamente. Al realizar la demostración, siempre aseguraba a la gerencia que "Esto se puede mejorar con un poco de limpieza". Con mucho gusto alentaron la limpieza posterior a la producción en ese punto, porque podían VER la necesidad.
Es un poco engañoso, pero funcionó. Al final, la aplicación fue más limpia, más rápida (obviamente) y bien escrita.
Normalmente intento trabajar en la "limpieza" en el próximo sprint justo después del lanzamiento. La forma en que se lo explico a la gerencia es que tuvimos que tomar algunas libertades y atajos con el código para enviar a tiempo y ahora, para hacer crecer el producto, debemos mejorar la base.
Espero que funcione para usted.
Póngase en sus zapatos de gerente: le pagan para escribir el mejor código que conoce. Y luego escribes algo que sabes que no está bien y que necesitaría trabajo adicional. ¿Por qué le pagarían por escribir un código horrible y luego otra vez arreglar su código malicioso sabiendo que podría hacerlo mejor en primer lugar ...
Sé que hay casos en los que simplemente no hay tiempo para hacer algo 100% correcto, pero aquí están hablando de proyectos completos (por lo que yo entiendo) ...
Pida tiempo para escribir pruebas unitarias y funcionales. Atrapará más errores descubiertos, refactorizará el código y dejará algunos artefactos serios del tiempo y el esfuerzo invertidos.
Podría intentar argumentar que después de la "puesta en marcha" inicial debería haber un tiempo de mantenimiento y soporte en el que cualquier problema de producción que no haya sido detectado antes sea remendado y manejado, y este es también el momento de prepararse para futuras mejoras o correcciones de errores. Si la gerencia puede decir y acordar que "no vamos a pedir ningún cambio más, nunca", entonces no creo que haya una buena razón para volver y limpiar el código a menos que uno crea que tal reclamo no es bueno en perpituitiy o como diría el Dr. House, "La gente miente".
Una excelente metáfora que realmente capta la atención de los tipos de negocios se refiere a ella como deuda técnica . Eso les hace entender que si bien no es un problema agudo en este momento, empeorará con el tiempo si se ignora, y si no se maneja, existen ramificaciones monetarias reales.
Supongamos que está realizando un desarrollo impulsado por prueba y, por lo tanto, su proceso de desarrollo debe ser similar a este:
- Escriba una prueba para cubrir la nueva funcionalidad requerida (la prueba falla)
- Escriba el código para hacer que la nueva prueba pase (junto con todas las demás)
- Refactorizar el código
- Asegúrate de que todas las pruebas aún pasen
- Verifica tu código en el control de la fuente
Excepto que en su caso, está saltando del paso 2 al paso 5 (omitiendo los pasos 3 y 4), y ahora quiere castigar a la administración por hacer un trabajo rápido y sucio. Efectivamente, se dirige a la gerencia y dice: "Queremos reescribir toda la aplicación que el cliente ya ha aceptado y pagado, no agregue ninguna funcionalidad nueva, gaste mucho tiempo de desarrollo haciéndolo para lo cual no se le pagará, y potencialmente introducir nuevos errores solo para que podamos hacer que los programas sean más bonitos para los desarrolladores de nosotros ". Nadie va a ir por eso.
Un punto importante es que no sabes dónde necesitas hacer que el código sea más comprensible: la mayoría de las aplicaciones puede que un desarrollador nunca las vea de nuevo y continúe trabajando para siempre, por feo que sea.
Piense en esto de la misma manera que en la optimización del rendimiento: solo sintonice las áreas de código que demuestren que son lentas y necesitan un ajuste. De la misma manera, el momento de refactorizar el código (para un proyecto existente que no se ha refactorizado mientras se desarrolló) es cuando ingresas nuevamente en parte del código para corregir un error o agregar una característica y el código no es entendible. Como parte de obtener una comprensión del código, refactorizarlo y hacerlo más comprensible: si las pruebas aún se aprueban, entonces lo habrá comprendido.
Lo que hay que hacer ahora es no ir a su jefe y decir que hizo un trabajo horrible y que debe dejar de hacer un trabajo remunerado para que el código sea más bonito. El enfoque a seguir es explicar acerca de la deuda técnica y dejarle saber a su jefe que para cumplir con sus plazos de entrega usted corta algunas esquinas y para el trabajo futuro habrá un ligero aumento en la cantidad de tiempo necesario para hacer el trabajo mientras realiza el código mejor. También explique que a medida que hace esto, el tiempo necesario para las correcciones / características se reducirá, pero si no lo hace, el desarrollo tomará más tiempo cada vez que se necesite hacer algo y es probable que la base de códigos sea menos fácil de cambiar y el código la aplicación será más frágil
La refacturación del código con el que entra en contacto a medida que avanza permite que la limpieza del código se realice solo para el código que lo necesita, cuando se pagará el trabajo.