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

No tengo mucha experiencia en trabajar en la industria del software, ser autodidacta y haber participado en código abierto antes de decidir tomar un trabajo. Ahora que trabajo por dinero, también tengo que lidiar con algunas cosas desagradables, lo cual es normal, por supuesto.

Recientemente me asignaron agregar el registro a un gran proyecto de SharePoint que fue escrito por un programador que obviamente estaba aprendiendo a codificar en el trabajo. Después de 2 años de colaboración, el cliente cambió a nuestra empresa, pero el daño ya estaba hecho y ahora de alguna manera necesito mantener este código.

No es que el código fuera demasiado difícil de leer. A pesar de los problemas, cada proyecto tiene una clase con varios métodos pegados, enormes ifanidamientos, sistemas húngaros, conexiones no expuestas, todavía es legible.

Sin embargo, me encontré absolutamente improductivo a pesar de trabajar en algo tan simple como agregar registros. Básicamente, solo necesito revisar el código paso a paso y agregar algunas llamadas de rastreo. Sin embargo, la idiotez del código es tan molesta que me canso a los 10 minutos de comenzar . Al principio, solía agregar usingconstrucciones, reducir el anidamiento invirtiendo if, cambiar el nombre de las variables a nombres legibles, pero el proyecto es grande y finalmente me di por vencido. Sé que esta no es la tarea que debería estar haciendo, pero al menos reducir el desorden me dio algún tipo de recompensa psicológica para poder seguir adelante. Ahora el truco dejó de funcionar y todavía tengo el 60% de mi trabajo por hacer.

Comencé a tener dolores de cabeza después del trabajo, y ya no tengo la sensación de satisfacción que solía tener, lo que generalmente me permitía codificar durante 10 horas seguidas y aún sentirme fresco.

Esta no es solo una gran queja, porque realmente tengo una pregunta real:

¿Hay alguna manera de mantenerse productivo y no luchar contra los molinos de viento?

¿Hay algún tipo de truco psicológico para mantenerse enfocado en la tarea, en lugar de pensar “¿Qué tan estúpido es eso ?” Cada vez que veo otro ingenioso truco del programador anterior? El problema al agregar el registro es que realmente tengo que entender lo que hace el código, y hacerlo lastima mi cerebro de una manera desagradable.

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

Tiene la tarea de un trabajo importante, incluso si es aburrido hasta el punto de ver la pintura seca. Es importante por dos razones: 1. Agrega un registro muy necesario a un sistema grande para que cuando algo salga mal, tenga una herramienta que lo ayude a encontrarlo. y 2. Te familiariza con la base del código para que, si algo sale mal, puedas saltar y arreglarlo.

Básicamente, está creando su propia red de seguridad aquí. Glamour, no, pero importante sí!

Entonces, dicho esto, ¿cómo deberías motivarte? Cuando tengo una tarea de adormecimiento mental en el trabajo, me propongo objetivos. Termina de hacer la tarea x al final de la semana. Si hago mi meta, 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 que hablar con mi supervisor y hacerle saber dónde estoy y cómo estoy progresando me hace responsable. Si les digo que terminaré antes del viernes, me siento más inclinado a hacerlo antes del viernes b / c. Les dije que lo haría.

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

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

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

Para mantener mi motivación y mi cordura, escribí un script llamado current_scoreque contaba el LOC en el proyecto (que disminuyó constantemente, ya que eliminé la duplicación y cambié a mejores algoritmos) y lo comparé con el LOC cuando comencé. Cada vez que me desanimaba o me frustraba con la montaña de código que enfrentaba, correr current_scoreme daría una sensación de progreso tangible y me recordaría cuánto había logrado. Y fue divertido ver cuán alto 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 tipo de juego. Líneas de código (simplemente ejecutadas wc -l), complejidad ciclomática (que debería disminuir a medida que limpia esos "si" desagradables anidados), líneas de código que ha tocado usted en lugar de su predecesor (creo que FishEye puede decirle esto para $ 10), etc. Incluso podría escribir un script de 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: trabajar eficazmente con código heredado , pero afortunadamente no he tenido la necesidad de leerlo.

Como lo está haciendo, refactorice lo que necesita para que pueda comprender el código y solo recuerde que está resucitando un sistema, que dará sus frutos cuando lo esté manteniendo.
Con suerte, eso debería poner un resorte en tu paso en el camino a casa.

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

Enorgullecerse de mejorar el proyecto. ¿Hay otros codificadores con los que puedas hablar? Ayuda a pararse alrededor del refrigerador 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 ha funcionado de maravilla para mí cuando se trata de grandes sistemas heredados. Ayuda a cristalizar su comprensión, ayuda a expresar las preguntas abiertas en palabras, y debido a que sus pensamientos ya están juntos, facilita la comunicación espontánea con otros sobre problemas / preguntas / ideas / etc.

Como ejemplo, mientras reviso un fragmento del código, me tomaré notas constantemente. Esta es mi conversación conmigo mismo. El mero acto de escribir ayuda a que surjan más pensamientos y me ayuda a comprender mejor las cosas. Después de un tiempo, puedo tener un Eureka y necesito dibujar un pequeño diagrama con la "imagen más grande" en papel para ilustrar lo que acabo de pensar o las piezas que acabo de armar. 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 está viendo desde la perspectiva de 'Solo estoy agregando registros' cuando, de hecho, está agregando registros y haciendo muchas refactorizaciones. Su supervisor probablemente esté al tanto de la situación del código. Es posible que todos no lo aprecien ahora, pero cuando reciba una solicitud para agregar una característica realmente interesante y desafiante, se alegrará de haber limpiado el código.

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

Gamifica tu trabajo. Por ejemplo, otórguese 5 puntos cada vez que haga una buena pregunta sobre el código y 10 puntos cada vez que lo conteste. Dése una insignia cada vez que refactorice un método o agregue una nueva función. Una vez que acumulas suficientes puntos obtienes privilegios como pausas para tomar café o galletas. Una vez que complete todo el proyecto, tendrá el privilegio de disfrutar de algo que realmente desea.

El truco para no aburrirse o enojarse para mantenerse productivo es aceptar que el código está mal diseñado. Aceptar su posición de tener que entender y actualizar el código le permitirá no seguir comentando "cuán estúpido es eso" y, en cambio, aceptarlo en silencio y seguir adelante.

Otro truco es tener un buen hogar que esperar al final del día. Novia, amigos, juegos, todo funcionará, para darle una meta para pasar el día y hacer que valga la pena el mal camino aunque sea un código malo.

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

Si te preocupa romper cosas cuando las cambias, primero escribe algunas pruebas, asegúrate de que pasen antes y después de que hagas los cambios. Escribir la prueba debería ayudarlo a resumir y comprender lo que hace un fragmento de código determinado y le permitirá editar con confianza.