Разве это нормально, что я не могу удержать в голове более трех приписанных мне ошибок и не могу понять тысячу строк кода для спагетти?

Я работаю над старой кодовой базой, которая ... не идеальна , в среде, которая тоже не идеальна . Это не худшая кодовая база, которую я видел в своей жизни, но все еще есть много проблем: тесты с нулевым модулем; методы с тысячами + строк кода; непонимание базовых объектно-ориентированных принципов; и т.п.

Больно поддерживать код.

1. Каждый раз, когда мне приходится отлаживать тысячу строк плохо написанного метода с многократным использованием переменных, я полностью теряюсь.
2. Некоторые изменения или рефакторинг, которые я сделал, привели к появлению ошибок в других местах приложения.
3. Не имея никакой документации, тестов или наблюдаемой архитектуры и в сочетании с плохо именованными методами, я чувствую, что заполняю всю свою доступную рабочую память. Там нет места для всех других вещей, которые я должен запомнить, чтобы понять код, который я должен изменить.
4. Постоянные перебои на рабочем месте беспокоят меня и замедляют.
5. Я не могу вспомнить больше двух или трех задач одновременно без системы отслеживания ошибок, и я забываю все из них в выходные.

У моих коллег, похоже, нет подобных проблем.

1. Им удается отлаживать плохо написанные методы намного быстрее, чем я.
2. Они вносят меньше ошибок, чем я, когда меняю кодовую базу.
3. Кажется, они очень хорошо помнят все, что им нужно для изменения кода, даже если для этого требуется прочитать тысячи строк кода в двадцати различных файлах.
4. Их, кажется, не беспокоят электронные письма, звонки телефонов, люди, которые разговаривают вокруг, и другие люди, задающие им вопросы.
5. Они не хотят использовать систему отслеживания ошибок, которая у нас уже есть, так как мы используем TFS. Они предпочитают просто помнить каждую задачу, которую они должны сделать.

Почему это происходит? Это особые навыки, которые приобретают разработчики, когда долго работают с плохо написанным кодом? Способствует ли мое относительное отсутствие опыта работы с плохим кодом этим проблемам / чувствам? У меня есть проблемы с моей памятью?

Да, для неструктурированного кода / окружения это нормально для структурированных людей. Ваши коллеги, вероятно, лучше отфильтровывают весь фоновый шум. Как страдающий мигренью, я знаю, что моя способность отфильтровывать свое окружение сильно падает, когда мигрень наступает. Люди разные.

То же самое относится и к коду: ваши коллеги, вероятно, научились отфильтровывать «шум кода», который исходит от нескольких уровней абстракции в одном методе, и стали искусными в «разбивке» кода на более широкие области функциональности.

Просто требуется время, чтобы адаптироваться к базе кода, такой как описанная вами. У ваших коллег, вероятно, было гораздо больше времени, чтобы вырасти, и, возможно, они усвоили соглашения, шаблоны и конструкции, которые не выпрыгивают из "новичков в кодовой базе". В хаосе может быть больше структуры, чем вы можете себе представить. Поговорите с вашими коллегами, попросите их пообщаться с вами некоторое время и выясните, как они подходят к решению одной из заданных вам ошибок. Когда они просят вас открыть блок X, Y или Z, спросите их, почему этот, что он говорит, что это может быть актуально и т. Д.

Быть потерянным в методе из тысячи строк - это нормально. Атакуйте его с помощью хорошего редактора свертывания и добавляйте комментарии для разделения различных частей на функции и / или процедуры, фактически не делая этого. Печать материала и использование старомодного маркера также могут помочь.

Рефакторинг без защитной сетки юнит-тестов - это выстрел в себя. Не. Просто не надо.

Никто не требует от вас хранить все в памяти. Если ваши коллеги не хотят или нуждаются в системе ошибок, просто напишите назначенную вам задачу в своем собственном списке задач и пишите заметки, когда / после разговора с кем-либо о деталях ваших задач.

Есть 3 основных момента, которые я вижу:

пункты 1, 2 и 3 проистекают из того факта, что ваши коллеги просто более опытны с базой кода, что означает, что они знают ее причуды. Это означает, что они используют свою долговременную память для процесса отладки и могут помнить, что doXYZ на самом деле делает UVW, но никогда не переименовывался по историческим причинам. однако если им когда-нибудь понадобится несколько месяцев от написания кода, они начнут чувствовать вашу боль.

для пункта 4 не поддавайтесь перебоям, не позволяйте несрочным бизнесам вывести вас из зоны , потребуется много времени, чтобы вернуться в нее после перерыва; установите IM компании занятым, попробуйте планировать в длинных блоках (полдня) только кодирования

на 5 секунд создайте таблицу Excel с ошибками, над которыми вы сейчас работаете, в качестве личного списка задач (или используйте возможности управления задачами в вашей IDE), я готов поспорить, что некоторые из ваших коллег делают то же самое

Не похоже на проблемы с памятью для меня. Похоже, что ваши рабочие привычки / склонности плохо подходят для того, с чем вы сталкиваетесь, и вы слишком много думаете о своих коллегах, а не о себе.

1. Метод с тысячной линией - все будут потеряны на этом, если только они не будут работать над этим. Они могут быстрее поднять его или получить обратно. Вы не можете изменить это, кроме как через опыт, а может быть, даже тогда.

2. Рефакторинг внесения ошибок, ну, это всегда риск. Вы можете попытаться разработать модульный тест, чтобы охватить то, что вы меняете, прежде чем это сделать, но это может быть недопустимо руководством (возможно, нет, или это уже будет сделано). И юнит-тесты не волшебство, они все еще могут пропустить вещи, вы все равно можете вводить ошибки. Скорее всего, они просто не рефакторинг. Это восходит к (1), они, вероятно, пытаются сосредоточиться только на том, что нужно исправить, то есть они быстрее добираются до точки, но упускают более широкую картину, и потребуется больше времени, чтобы исправить следующую вещь в этом беспорядке из тысячи строк.

3. Создайте то, что вам нужно, чтобы сделать работу. Если это означает создание блок-схемы или другой документации, то сделайте это. Нужно это им или нет, и используют ли они его или нет после того, как вы его создали, не имеет значения.

4. Перебои замедляют всех. Сосредоточение на этом только замедлит вас больше. Примите это и постарайтесь как можно быстрее вернуться в канавку.

5. Имея в виду две или три ошибки, неплохо, три или четыре были бы лучше, но вместо того, чтобы пытаться улучшить это, сдавайтесь и записывайте это. Кусок бумаги, доска, TFS, Excel, слово или блокнот - просто запишите это. Могу поспорить, что это то, что делают ваши коллеги. Либо это, либо чинить вещи наугад.

Программирование не об идеальной памяти, и не о способности игнорировать отвлекающие факторы - сосредоточение на этом - это просто отвлекающие факторы, которые вы создаете.

ПРОСМОТР / ОБНОВЛЕНИЕ: Прочитав приведенный ниже ответ, я почувствовал, что это может показаться слишком резким. Не мое намерение, среда, которую вы описываете, ужасна, и это затронет большинство людей (возможно, даже лучшие программисты страдают от этого, но они "лучше" по сравнению с другими в той же среде). Мой ответ - это просто точечная рефлексия в ваших вопросах, если предположить, что среда не изменится (даже если она должна).

Полностью ревностный ответ:

1) Это зависит от опыта работы с технологией, поддержки приложения (особенно если оно плохо спроектировано) и даже в отдельных частях приложения. Также зависит от ваших проблем с концентрацией (номер 4)

2) Это то же самое, что и число 1, но с использованием другой метрики. Тот же ответ.

3) блокнот и ручка. Или документ Word / Excel. Не так сложно решить.

4) это личная проблема концентрации. Однако не уверен, что это можно улучшить самостоятельно.

5) использование системы тикетов или нет должно решаться не программистами, а руководителем проекта. Спросите его мнение / представить свои очки. Если он против, блокнот и ручку снова.

Я уже сталкивался с подобной ситуацией и, основываясь на этом опыте, могу сказать, что ваша проблема не связана с памятью и что у вас есть что-то на уме (скорее всего, не связанное с работой), что вызывает у вас стресс и удерживает вас от концентрации % на поставленную задачу.

Итак, первый шаг - очистить свой разум от всего этого, когда вы находитесь за столом.

Это напряжение может также увеличиться, потому что вы чувствуете, что отставали в плане производительности, поэтому попробуйте поговорить со своими коллегами и попросите их дать советы по их подходам к рефакторингу.

Наконец, не смущайтесь, если вам нужно записать проблемы, которые вы решили и / или работаете сейчас (это не обязательно должна быть сложная система отслеживания ошибок), лучше быть уверенным в чем-то, потому что вы читаете это из ваши заметки, чем констатировать это на макушке, не будучи на 100% уверенным в этом