¿Cómo maneja el código feo que escribió? [cerrado]

Consigue otro trabajo y deja que otras personas se encarguen de él. Muahahahhahahaa.

.....

Solo bromeando. :)

Pero con toda seriedad: relleno de estimación es tu amigo. Generalmente hago una estimación realista decente, luego la duplico. Esto puede sonar excesivo, y algunas veces lo es, pero es mejor sobreestimar un poco e incluso lucir un poco lento a veces, que dejar malas impresiones al generar un código defectuoso y siempre soplar sus estimaciones. Y, por supuesto, usted incurre en deudas técnicas al permitir que el código base se vuelva intrépido.

Otro consejo (relacionado): siempre calcule las tareas aparentemente pequeñas, sin complicaciones, en un bloque de tamaño decente. Digamos, por ejemplo, un elemento que está casi seguro de que solo será un cambio de línea de 30 segundos, dale 1 hora (o lo que sea el bloque de tiempo más bajo en tu hoja de asistencia o sistema CR, por ejemplo, 15 minutos / 0,25 horas) . Y asigne bloques de medio día o de 1 día para los artículos un poco más grandes pero aún relativamente triviales.

La razón de esto es principalmente psicológica: me parece que si tienes la costumbre de piratear pequeños cambios rápidamente, el trabajo se siente apresurado y nunca terminas recostándote, haciendo balance y refactorizando cosas que deben ser refaccionado Además, en un nivel práctico: los cambios pequeños pero no triviales a veces estallan, y no quiere sentirse constantemente como si estuviera atrasado y apagando incendios. Es parte integral de por qué las bases de código se vuelven piratas con el tiempo.

Finalmente, siempre recuerde que las personas no tienen que saber que está cumplimentando un poco sus estimaciones. Siempre que seas un desarrollador competente y estés trabajando a un ritmo decente, este relleno no se notará. es decir, no le digas al PHB "Mi estimación inicial es que tomará dos horas, pero dame medio día". Solo dile "Creo que tomará alrededor de medio día". y dejarlo ahí.

Sobreestime deliberadamente el tiempo necesario para sus próximas funciones. Usa ese tiempo extra para limpiar.

Nunca podrá justificar el mantenimiento, y el cliente lo necesita independientemente, así que deles un medicamento amargo (costos ligeramente mayores para las siguientes funciones) para que puedan mejorar.

Intente hacer un rediseño adecuado al integrar nuevas funciones. No hay más tarde. Sin el rediseño, está agregando constantemente más y más fricción para más cambios y nuevas características.

En algún momento llegará a un punto muerto donde todo parece tardar años. Es probable que la mayoría de las empresas opten por la gran reescritura en este punto, la versión 2. Tiene una economía bastante pobre y es un buen momento para que sus clientes prueben una fiesta de desarrollo diferente si se sienten inclinados.

El rediseño / refactorización adecuado puede proteger la inversión de sus clientes y mantener las cosas sostenibles. Debe integrarlo. Optimice para el cambio, viaje ligero.

Con todos los comentarios sobre la sobreestimación, creo que se está perdiendo una pequeña cantidad de puntos (bueno, oportunidad).

No se trata de estimar el tiempo que se tarda en realizar el cambio (solo) y luego agregar un poco, se trata de estimar el tiempo necesario para modificar el código (¡refactor!) para llevarlo a un punto donde el cambio se pueda realizar de manera segura y luego haga el cambio (probablemente un poco amañado). Ok, esto equivale a lo mismo ... pero no se trata de hacer movimientos bruscos, estirarse o sobreestimarse, es simplemente una cuestión de decir que para hacer esto primero debo hacer eso y este es el tiempo que tomará. en total. La clave aquí es que trabajas en aquellas partes del sistema de las que depende el cambio y no más, si hay un código horrible en otra parte ... difícil, cógelo cuando estés allí.

Volver a la pregunta original un poco, después de muchos años, se trata de un problema para mí, cuando implementa algo a menos que sepa (no crea, no espere (¿sospechoso?) , no piense, pero sepa ) que también se requieren cosas adicionales, entonces debe hacer lo que necesita para implementar ese requisito y no más en la forma más ordenada y elegante que pueda.

Cuando venga a implementar lo siguiente, algo más tarde, tome los pasos necesarios para llevar el código base (y la base de datos) al estado necesario para implementar esa funcionalidad de la manera más ordenada y elegante que pueda. puede. Esta refactorización es donde tratas el desorden que surge naturalmente a medida que un proyecto evoluciona y, con suerte, evitas crear más desorden (o al menos mantén el nivel consistente).

Una de las áreas de discusión aquí es "Deuda técnica": es como un sobregiro, usted tiene que devolverlo y, mientras más tiempo lo deje, más interés (en este caso, el tiempo requerido para corregir) acumulará. es un buen argumento para pasar parte de su tiempo minimizando la deuda técnica.

Aquí es también donde comienzan las pruebas de unidad y otras pruebas automatizadas (si pudiera hacerlo tan bien como digo que estoy bastante seguro de que sería una persona más feliz) combinada con un servidor de compilación adecuado (que puede ejecutarse al menos algunas de tus pruebas). Combinados con esos, pero de valor en sí mismos, hay patrones como la inyección de dependencia y la inversión de control (nunca estamos seguros de cuán "iguales" son esos dos) porque hacen que sea más fácil cambiar la tubería y, por lo tanto, lidiar con los cambios en aislamiento.

Por último, recuerda, si no está roto, no lo arregles. Poner en orden su código con el único fin de ponerlo en orden puede ser satisfactorio, pero también es una oportunidad para introducir errores, mientras que puede ser doloroso si no necesita cambiarlo y no lo está desarrollando. Quizás sea mejor dejar algunos bultos solos. ¡La oportunidad de reparar o reemplazar se extenderá eventualmente!

1) El control de cambio adecuado es tu amigo

Si el cliente cambia la especificación que está bien, es su derecho, sin embargo, es un cambio y debe cobrarse (o costearse de cualquier manera que sea apropiada para la estructura / relación del proyecto).

La estimación de ese cambio debe incluir el costo de la refactorización necesaria . El cliente bien puede rechazar lo que parece ser un alto costo, pero en ese momento debe explicarle que, dado que el código ya está escrito a medias, hay elementos que se deben volver a escribir para garantizar que sean sólidos y compatibles en el futuro y que si no se hace, es probable que tenga problemas en el futuro con soporte futuro o que los cambios sean aún más caros.

2) La refactorización debe hacerse de tal manera que proporcione un beneficio genuino a largo plazo para el cliente

Al considerar la refactorización, siempre debe considerar lo que realmente se necesita y lo que es importante y asegurarse de que el trabajo de refactorización proporcione un valor genuino a largo plazo para el dinero.

Después de todo, deberíamos hacer estas cosas para que el código siga siendo extensible y soportable a medio / largo plazo para garantizar que la inversión del cliente siga siendo válida en lugar de salir de cualquier impulso hacia la perfección teórica. El trabajo de refactorización (y las estimaciones correspondientes) se debe hacer con esto como el alcance, y no solo porque ahora piensas que podría haber una forma ligeramente mejor de hacerlo.

Algunos programadores sugieren que una forma de controlar ese problema con los clientes es hacer que el cliente firme y autorice la especificación inicial. ENTONCES, cuando solicitan un cambio de requisito que no está en la especificación inicial, les dice que debe revisar el calendario del contrato y del proyecto para calcular los costos adicionales y los retrasos, y luego anexar el contrato. Al parecer, hace maravillas al evitar que los clientes insistan en nuevas características (impredecibles).

Tengo el siguiente comentario en una base de código en la que estoy trabajando actualmente:

/*
 * Every time I see this function, I want to take a shower.
 */

Sé, muy bien la situación que estás describiendo. Lo que hago es intentar (mi mejor esfuerzo) esperar hasta que las cosas se calmen y cualquier tipo de "arrastramiento" haya "arrastrado" todo lo que va a hacer. Para entonces, es probable que haya liberado algo utilizable, y puede tomarse un tiempo para limpiar las cosas e implementarlas de forma un poco diferente.

No puedes correr limpiando muchos pequeños desorden repetidamente. Eso solo triplica tu trabajo, y la frustración. Espera a que se convierta en uno más grande, pero que no se mueva, y luego puedes hacer algo al respecto.

Mi preferencia es evitar esta situación en primer lugar.

Todo depende de CÓMO lea la especificación. Es fácil pensarlos como tablas de piedra, pero en realidad la mayoría de las especificaciones cambian. Cuando diseñe su código, observe la probabilidad de que cada parte de la especificación cambie. Con el tiempo, será bastante bueno para predecir esto.

Haber metido en el lío, la experiencia y el juicio es muy importante. ¿Estás escribiendo nuevos errores debido a este código de espagueti? ¿Lleva más tiempo implementarlo? Estos apuntarían a hacer un refactor táctico.

para el futuro, parece que necesita trabajar en asociación con su cliente. Al decirles, "mire este producto se está expandiendo significativamente más allá de las especificaciones originales. Si bien el diseño original era bueno para ese nivel, expandiéndolo en la dirección X y las direcciones Y necesitan una reestructuración en el diseño" manejado bien, e incluso obtendrá su cliente para pagar por ello.

Cargue por hora y si quiere cambios, diga que está bien, pero incorpore el tiempo requerido para escribir un buen código en la ecuación. Además, recuerde que escribir un código más limpio da sus frutos a largo plazo cuando tiene que mantenerlo. Ahorrar tiempo ahora podría costarte más tarde.

Creo que la escritura de software debe ir de la mano con las necesidades comerciales. Si se trata de un proyecto desechable (como un prototipo que debe construirse en una semana, con nuevas entradas que llegan todos los días), entonces no hay necesidad de preocuparse por la capacidad de mantenimiento del código y otras cosas. El tiempo es crucial y solo necesita presiona tu código fuera de la puerta tan rápido como puedas.

Pero si está escribiendo una aplicación a largo plazo, entonces tiene sentido considerar todo esto, porque hay un impacto considerable en el tiempo que lleva construir nuevas funciones, corregir errores existentes, integrarse en otras aplicaciones y otros. cosas, y esto se traduce en un impacto en el negocio (debido a que más tiempo se requiere más tarde y más costo).

Por lo tanto, es mejor sensibilizar al tomador de decisiones sobre los costos reales de no refactorizar el código siempre que sea necesario; según mi experiencia, si los costos y el impacto en el tiempo de ambas opciones se explican en términos mensurables al propietario de la decisión, entonces la decisión puede ser un pan comido No espere que la gente le diga 'sí, escriba un código hermoso, aunque tome el doble de tiempo y no me dé ningún beneficio adicional'. Simplemente no funciona de esa manera.

Hágalo parte de su proceso, lo llamo "refactorización extrema" y ¡va a ser grande! ;) Simplemente haga las cosas rápidamente y cuando se hayan agregado suficientes funciones nuevas que tengan tejido cicatricial, refactorícelo. Continuamente pregúntese "Ahora si hubiera empezado desde cero, ¿cómo lo hubiera hecho?"

Las personas que piensan que pueden diseñar y pensar en todo lo que está al frente se están engañando a sí mismos, usted (y su cliente) siempre aprenden cosas a medida que avanzan. Usa esas lecciones.

Como usted es un buen programador, podrá refactorizar con bastante rapidez y al hacerlo continuamente, el código comenzará a tomar su "forma adecuada", lo que significa que se volverá más flexible con menos dependencias.

Los clientes podrían sentirse molestos si supieran que usted estaba "perdiendo el tiempo" reelaborando las cosas, por lo que es mejor no preguntar / decir y ser muy rápido al respecto.

El código desarrollado de esta manera te ahorrará un montón de tiempo al final y hará que cada vez sea más fácil agregar nuevas funciones.

También diría que una de las razones más importantes para el código incorrecto es el temor que tienen los programadores de hacer una refactorización estructural más grande, y cuanto más espere, peor se pone.

Confíe en un poder superior

No me refiero a orar. Quiero decir, asegúrese de que haya un tipo de empresa (es decir, gerente de proyecto o equivalente) que pueda colocar como relleno entre usted y el cliente. Si el cliente está exigiendo demasiado, deje que el empresario ponga el pie abajo y esté preparado para manejar "es factible, pero no estoy seguro de si eso se ajusta al alcance de la especificación, consulte [empresario]".

En un flujo de proyecto normal, la especificación general debe congelarse antes de que tenga lugar un desarrollo serio.

Muchos clientes continuarán impulsando los cambios / mejoras / mejoras mientras los deje. Muchos abusarán de esa capacidad al máximo porque les hace sentir que están obteniendo el máximo rendimiento de su dinero (incluso si sabotea su proyecto).

Tenga una persona dedicada a perfeccionar y congelar la especificación desde el principio y hacerla cumplir más adelante.

No hay nada de malo en hacer un poco de extra por un poco de buen karma con el cliente, pero prepárate para diferir a un poder superior cuando se te salen de las manos. Si la especificación requiere una cantidad ridícula de cambios, tal vez sea hora de volver al ciclo comercial y volver a evaluar el contrato y / o agregar adiciones al contrato (con una compensación monetaria justa).

El hecho de que tenga este problema tiene poco que ver con la forma en que codifica. Es una señal de que su gerente de proyecto no está siendo utilizado en el proyecto (ya sea por su culpa, por su culpa, o por ambas cosas).

Como han dicho otros en muchas respuestas, también es necesario agregar un búfer de tiempo para contingencias en cualquier proyecto, pero debe determinarse que debe decidirse a puerta cerrada antes de que la especificación sea congelada y entregada al cliente por el PM.

El diseño correcto inicial no puede evitar el problema. Y es casi imposible (o muy difícil) considerar todos los requisitos futuros de "tal vez". Así que después de un tiempo llegará el Big Re-factoring. Y la mejor solución es volver a escribir todo.

En pocas palabras: en lugar de colocar una torreta en el Ferrari rojo, reconsidere los requisitos y construya un tanque.

Mátalo con fuego.

Aka refactor tan pronto como sea posible: por ejemplo, cuando el código feo se deriva de la prisa por un plazo límite, me gustaría refactorizarlo después de la fecha límite porque no puede (o al menos no debería) agregar más funciones hasta que el código existente esté mantenible, de lo contrario, será mucho más difícil depurar los códigos futuros.

Escriba pruebas unitarias para sus proyectos que prueban el estado actual y luego refactorice cuando tenga tiempo, de esta manera evitará romper su proyecto mientras intenta limpiarlo.

La respuesta más simple. Yo dejaría de codificar de cualquier tipo, hasta que tenga una especificación final para exactamente lo que quiere a partir de ahora.

Luego deben priorizar esa lista de características, etc., para confirmar qué elementos deben tener en este momento, y cuáles se pueden hacer más adelante ...

Usando sus experiencias para determinar cuál es el tiempo / costo de cada función, y luego dígales, si lo desean, tomará una cantidad de tiempo & dinero.

Tu trato con el gran crimen del alcance del rasgo de la característica, y seguirán agregando características sin cesar, hasta que nada se haga o se haga tan mal.

Una vez que tenga una lista final, dígales que hará modificaciones futuras, según lo prefieran, pero debe centrarse en los 15/20 principales que deben tener en este momento.

Luego, en función del tiempo de finalización, dígales que después de que se haya publicado esto, estará abierto a discutir / generar una tormenta de ideas en la próxima versión.

Una vez que se haya tomado una decisión final sobre qué se debe hacer para la versión actual, todas las discusiones / ideas / sugerencias deben detenerse al 100%.

Si recibe ideas sin cesar, dígale que las escriba en su lista de características para la próxima versión y le permitirá concentrarse en brindar las características más importantes que desean en este momento.

Si continúan perdiendo el tiempo, sigan cambiando de opinión. Luego, simplemente dejaría de trabajar en el proyecto y trabajaría en otros proyectos, hasta que hayan finalizado sus decisiones.

Es difícil de hacer, pero el alcance del rasgo de la función es tan destructivo para el tiempo, la energía, la motivación y el pensamiento claro.

Desde una perspectiva completa del proyecto:

Aprenda del código con su equipo, vea qué se puede refaccionar y reutilizar la próxima vez, luego tome una cerveza.

Desde una perspectiva en desarrollo:

Explique pacientemente por qué se ha detenido el desarrollo y explique por qué no puede continuar hasta que todas las especificaciones estén en la tabla y se comprendan. Entonces, ve a tomarte una cerveza.

Desde una perspectiva de planificación:

Solicite todas las especificaciones por adelantado y trabaje con todos para tener una comprensión clara de la ruta de desarrollo. Involucre al cliente / partes interesadas lo más cerca posible para asegurarse de que todos estén en la misma página. Más tarde esa noche, trae a todos cervezas. Mañana, comienza el proyecto.