¿Cómo se mantiene productivo cuando trata con un código extremadamente mal escrito?

Lamento decírtelo, pero no todos los trabajos están llenos de sol y glamour. La mayoría de las tareas de desarrollo implican un trabajo pesado como este. Triste pero cierto.

Se le ha asignado un trabajo importante, incluso si es aburrido hasta el punto de ver cómo se seca la pintura. Es importante por dos razones: 1. Agrega un registro muy necesario a un sistema grande para que cuando algo salga mal, tengas una herramienta que te ayude a encontrarlo. y 2. Le permite familiarizarse con el código base para que, en caso de que algo salga mal, pueda saltar y solucionarlo.

Básicamente estás creando tu propia red de seguridad aquí. ¡Glamores, no, pero sí importante!

Entonces, una vez dicho esto, ¿cómo debería motivarse? Cuando tengo una tarea de adormecimiento mental en el trabajo, me fijo metas. Terminar de hacer la tarea x al final de la semana. Si hago mi objetivo, me recompensaré. Nuevo restaurante que quiero probar? Ve el viernes por la noche si termino. Nueva película acaba de salir? Véalo el fin de semana si termino.

Encuentro hablar con mi supervisor y hacerle saber a él / ella dónde estoy y cómo estoy progresando me mantiene responsable. Si les digo que lo haré el viernes, me siento más inclinado a hacerlo el viernes b / c. Les dije que lo haría.

Tenga fe en que una vez que complete esta tarea y la haga bien, a tiempo y dentro del presupuesto que la gente notará y cuando llegue ese brillante nuevo proyecto, su nombre podría ser sugerido como el que lo recibe. :)

Mantenga un archivo de fragmentos de código de candidato para enviarlos a thedailywtf.com. Incluso si realmente no tiene la intención de enviarlos, le da un lado positivo al encontrar un código que es incluso peor que el promedio.

Estaba en una situación similar, encargada de limpiar un gran cuerpo de código mal escrito, copiado y pegado de forma masiva.

Para mantener mi motivación y mi cordura, escribí un script llamado current_score que contaba el LOC en el proyecto (que disminuía constantemente, ya que eliminé la duplicación y cambié a mejores algoritmos) y lo comparé con el LOC cuando empecé . Cada vez que me desanimaba o me frustraba con la montaña de códigos que enfrentaba, ejecutar current_score me daría una sensación de progreso tangible y me recordaría cuánto había logrado. Y fue divertido ver cuán alto de puntaje podría acumular al abordar una sección de código particularmente mala.

Buscaría métricas similares que podrías escribir fácilmente para darte una sensación de progreso y convertirlo en un juego de todo tipo. Líneas de código (solo ejecute wc -l ), complejidad ciclomática (que debería disminuir a medida que se limpia) esos "ifs" anidados desagradables), líneas de código que ha tocado usted en lugar de su predecesor (creo que FishEye puedo decirle esto por $ 10), etc. Incluso podría escribir una secuencia de comandos Perl sin muchos problemas para contar la cantidad de bloques de código que aún no tienen declaraciones de registro.

He visto este libro recomendado: Trabajando con eficacia con el código heredado , pero afortunadamente no he tenido un Necesito leerlo.

Al igual que lo está haciendo, refactorice lo que necesita para que pueda entender el código y solo recuerde que está reanimando un sistema, que se verá recompensado cuando lo mantenga.
Esperemos que eso ponga un paso en tu paso en el camino a casa.

Intenta dividir el proyecto en partes. Cada día aprende cómo funciona un trozo específico. Tratar de entenderlo todo a la vez es probablemente lo que te estresa.

Enorgullecerse de mejorar el proyecto. ¿Hay otros programadores con los que puedas hablar? Es útil pararse alrededor del enfriador de agua discutiendo / riéndose de la última lógica que encontró. Intento hacer esto para mantener una atmósfera jovial en el trabajo.

Tome notas extensas para organizar sus preguntas, pensamientos y comprensión del sistema. Esto me ha funcionado de maravilla al tratar con grandes sistemas heredados. Ayuda a cristalizar su comprensión, ayuda a poner las preguntas abiertas en palabras y, dado que sus pensamientos ya están juntos, hace que sea más fácil comunicarse espontáneamente con los demás sobre problemas / preguntas / ideas / etc.

Como ejemplo, mientras reviso un fragmento del código, me tomaré notas constantemente. Esta es mi conversación conmigo misma. El mero acto de escribir ayuda a que surjan más pensamientos y me ayuda a entender mejor las cosas. Después de un tiempo, es posible que tenga un Eureka y necesito dibujar un pequeño diagrama con la "imagen más grande" en un papel para ilustrar lo que acabo de pensar o las piezas que acabo de juntar. Siempre hago esto solo en papel, eliminando todas las distracciones de la computadora. Esto me permite ser más metódico y reflexivo sobre lo que estoy haciendo.

Esta es básicamente una forma conveniente de tener una conversación perpetua con un experto en dominios :)

Sé que puede sentirse improductivo porque lo ve desde la perspectiva de 'solo estoy agregando el registro' cuando, de hecho, está agregando el registro y haciendo mucha refactorización. Su supervisor probablemente esté al tanto de la situación del código. Es posible que no todos lo aprecien ahora, pero cuando recibas una solicitud para agregar una característica realmente interesante y desafiante, te alegrarás de haber limpiado el código.

En estos casos, tiendo a reescribir una sección de código. Para hacer que un área chupe menos y luego simplemente agregue el registro en otro lugar. Luego limpia un poco más de código. El código malo solo es malo si lo dejas ahí.

Gamifica tu trabajo. Por ejemplo, concédase 5 puntos cada vez que haga una buena pregunta sobre el código y 10 puntos cada vez que responda. Dése una insignia cada vez que refactorice un método o agregue una nueva característica. Una vez que acumulas suficientes puntos, obtienes privilegios como coffee breaks o galletas. Una vez que complete todo el proyecto, tendrá el privilegio de disfrutar de algo que realmente desea.

El truco para no aburrirte o enfadarte para mantenerte productivo es aceptar que el código está mal diseñado. Aceptar su posición para tener que entender y actualizar el código le permitirá no seguir comentando "qué estúpido es eso" y, en su lugar, aceptarlo y seguir adelante.

Otro truco es tener una buena vida doméstica que esperar al final del día. Novia, amigos, juegos, cualquier cosa funcionará, para darte un objetivo para pasar el día y hacer que valga la pena el código malicioso.

"Trabajar eficazmente con el código heredado" por Michael Feathers puede ayudar.

Si está preocupado por romper cosas cuando las cambia, escriba algunas pruebas primero, asegúrese de que pasen antes y después de hacer los cambios. Escribir la prueba debería ayudarlo a resumir y comprender lo que hace una pieza de código determinada y le permitirá editar con confianza.