¿Es normal que no pueda tener en mi cabeza más de tres errores asignados a mí, ni puedo entender mil líneas de código de espagueti?

Estoy trabajando en una antigua base de código que ... no es perfecta , en un entorno que tampoco lo es. No es la peor base de código que he visto en mi vida, pero todavía hay muchos problemas: pruebas de unidad cero; métodos con más de mil líneas de código; malentendido de principios básicos orientados a objetos; etc.

Duele mantener el código.

1. Cada vez que tengo que depurar mil líneas de un método mal escrito con variables reutilizadas por todas partes, estoy totalmente perdido.
2. Algunas modificaciones o refactorizaciones que he realizado introdujeron errores en otros lugares de la aplicación.
3. Al carecer de documentación, pruebas o una arquitectura observable y combinado con métodos mal nombrados, siento que lleno toda mi memoria de trabajo disponible. No me queda espacio para todas las otras cosas que tengo que recordar para comprender el código que debo modificar.
4. Las interrupciones constantes en el lugar de trabajo me molestan y me retrasan.
5. No puedo recordar más de dos o tres tareas a la vez sin un sistema de seguimiento de errores, y las olvido todas durante el fin de semana.

Mis colegas no parecen tener problemas similares.

1. Se las arreglan para depurar métodos mal escritos mucho más rápido que yo.
2. Presentan menos errores que yo al cambiar la base de código.
3. Parecen recordar muy bien todo lo que necesitan para cambiar el código, incluso cuando se requiere leer miles de líneas de código en veinte archivos diferentes.
4. Parece que no les molestan los correos electrónicos, los teléfonos que suenan, las personas que hablan por todas partes y otras personas que les hacen preguntas.
5. No quieren usar el sistema de seguimiento de errores que ya tenemos desde que usamos TFS. Prefieren recordar cada tarea que deberían hacer.

¿Por qué pasó esto? ¿Es una habilidad particular que los desarrolladores adquieren cuando trabajan con código mal escrito durante mucho tiempo? ¿Mi relativa falta de experiencia con código incorrecto contribuye a estos problemas / sentimientos? ¿Tengo problemas con mi memoria?

Sí, es normal que las personas estructuradas se vean afectadas por códigos / entornos no estructurados. Sus colegas probablemente estén filtrando mejor todo el ruido de fondo. Como paciente de migraña, sé que mi capacidad para filtrar mi entorno disminuye considerablemente cuando se produce una migraña. Las personas varían

Lo mismo es cierto para el código, sus colegas probablemente han aprendido a filtrar el "ruido de código" que proviene de múltiples niveles de abstracción en un solo método y se han vuelto expertos en "fragmentar" el código en áreas más amplias de funcionalidad.

Simplemente lleva tiempo adaptarse a una base de código como la que usted describe. Sus colegas probablemente hayan tenido mucho más tiempo para crecer y posiblemente hayan aprendido convenciones, patrones y construcciones que no se saltan a los "principiantes de código base". Puede haber más estructura del caos de lo que puedas imaginar. Hable con sus colegas, pídales que se emparejen con usted algún tiempo y escojan sus cerebros sobre cómo se acercan a resolver uno de los errores que se le asignaron. Cuando le pidan que abra la unidad X, Y o Z, pregúnteles por qué esa, qué les dice que puede ser relevante, etc.

Perderse en un método de mil líneas es normal. Atáquelo con un buen editor de plegado y agregue comentarios para dividir las diversas partes en funciones y / o procedimientos sin hacerlo realmente. Imprimir las cosas y usar un marcador antiguo también puede ayudar.

Refactorizar sin la red de seguridad de las pruebas unitarias es dispararse en el pie. No lo hagas Solo no lo hagas.

Nadie te exige que guardes todo en la memoria. Si sus colegas no quieren o necesitan un sistema de errores, simplemente escriba la tarea que se le asignó en su propia lista de tareas pendientes y escriba notas cuando / después de hablar con alguien sobre los detalles de sus tareas.

Hay 3 puntos principales que veo:

los puntos 1, 2 y 3 se derivan del hecho de que sus colegas simplemente tienen más experiencia con la base de código, lo que significa que conocen sus peculiaridades. Esto significa que usan su memoria a largo plazo para el proceso de depuración y pueden recordar que doXYZ realmente hace UVW pero nunca cambió su nombre por razones históricas. sin embargo, si alguna vez tardan unos meses en codificarlo, comenzarán a sentir su dolor.

para el punto 4 resista las interrupciones, no permita que negocios no urgentes lo saquen de la zona , lleva mucho tiempo volver a entrar después de una interrupción; configure el IM de la empresa como ocupado, intente programar en bloques largos (tardes completas) de solo codificación

para el punto 5 segundos, cree una hoja de Excel con los errores en los que está trabajando actualmente como su lista de tareas personal (o use las capacidades de administración de tareas en su IDE), estoy dispuesto a apostar que algunos de sus colegas están haciendo lo mismo

No me parecen problemas de memoria. Parece que sus hábitos / tendencias laborales no encajan bien con lo que está encontrando, y está pensando demasiado en sus colegas y no en usted mismo.

1. Método de mil líneas: todos se perderán en eso a menos que simplemente trabajen en ello. Pueden ser más rápidos para recogerlo o recuperarlo. No puedes cambiar eso excepto a través de la experiencia, y tal vez ni siquiera entonces.

2. Refactorizar la introducción de errores, bueno, eso siempre es un riesgo. Puede intentar desarrollar una prueba unitaria para cubrir lo que está cambiando antes de hacerlo, pero es posible que la administración no lo permita (probablemente no, o ya estaría hecho). Y las pruebas unitarias no son mágicas, todavía pueden perder cosas, aún puedes introducir errores. Lo más probable es que simplemente no estén refactorizando. Esto se remonta a (1), probablemente intentan enfocarse en lo que necesita ser arreglado, lo que significa que llegan al punto más rápido, pero pierden la imagen más grande y les tomará más tiempo arreglar lo siguiente en ese desorden de mil líneas.

3. Crea lo que necesitas para hacer el trabajo. Si eso significa crear un diagrama de flujo u otra documentación, entonces hágalo. Si lo necesitan o no, y si lo usan o no después de que lo haya creado, es irrelevante.

4. Las interrupciones retrasan a todos. Centrarse en eso solo lo retrasará más. Acéptelo e intente volver al ritmo lo más rápido posible.

5. Tener en cuenta dos o tres errores no es malo, tres o cuatro serían mejores, pero en lugar de tratar de mejorar eso, ríndete y escríbelo. Papel, pizarra, tfs, excel, word o bloc de notas, solo escríbalo. Apuesto a que eso es lo que están haciendo tus colegas. O eso o arreglar las cosas al azar.

La programación no se trata de una memoria perfecta, y no se trata de ser capaz de ignorar las distracciones; centrarse en esto son solo distracciones que está creando.

PRUEBA / ACTUALIZACIÓN: Después de leer la respuesta a continuación, sentí que podría ser demasiado duro. No es mi intención, el entorno que describe es terrible y afectaría a la mayoría de las personas (probablemente incluso los mejores programadores lo sufren, pero son "mejores" en comparación con otros en el mismo entorno). Mi respuesta es solo una reflexión punto por punto en sus preguntas, suponiendo que el entorno no cambiará (incluso si debería).

Respuesta totalmente opinable:

1) Eso depende de la experiencia en la tecnología, en el mantenimiento de la aplicación (más si está mal diseñada) e incluso en partes específicas de la aplicación. También depende de tus problemas de concentración (número 4)

2) Es lo mismo que el número 1, pero con una métrica diferente. La misma respuesta

3) bloc de notas y bolígrafo. O un documento de Word / Excel. No es tan difícil de resolver.

4) ese es un tema personal de concentración. Sin embargo, no estoy seguro de si es viable mejorarlo usted mismo.

5) el uso de un sistema de tickets o no no debe ser decidido por los programadores sino por el gerente del proyecto. Pídale su opinión / presente sus puntos. Si él está en contra, vuelva a tomar nota y vuelva a escribir.

He pasado por una situación así antes y, en base a esa experiencia, puedo decir que su problema no está relacionado con la memoria y que hay algo en su mente (ciertamente no relacionado con el trabajo) que lo estresa y evita que se concentre 100 % en la tarea en cuestión.

Entonces, el primer paso es despejar tu mente de esas cosas cuando estás en tu escritorio.

Ese estrés también puede aumentar porque sientes que te estás quedando atrás en términos de productividad, así que trata de hablar con tus compañeros de trabajo y pídeles consejos sobre sus enfoques para la refactorización.

Finalmente, no se sienta avergonzado si tiene que escribir los problemas que ha resuelto y / o está trabajando en este momento (no tiene que ser un sistema sofisticado de seguimiento de errores), es mejor estar seguro de algo porque lo leyó sus notas que decirlo desde la parte superior de su cabeza sin estar 100% seguro de ello