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

19

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

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

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

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

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

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

Арсений Мурзенко
источник
1
Ваши коллеги более опытны с этой конкретной кодовой базой, чем вы? Кроме того, модульные тесты / отслеживание ошибок / и т. Д. На самом деле не должны быть подходом «все или ничего». Просто начните реализовывать их в тех частях, за которые вы несете ответственность.
Грэм
1
Вот почему существует инкапсуляция .
Роберт Харви

Ответы:

26

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

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

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

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

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

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

Марьян Венема
источник
+1 за «Да, для неструктурированного кода / окружения это нормально для структурированных людей».
Г-н Махбубур Рахман
2

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

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

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

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

чокнутый урод
источник
Спасибо вам за ваши предложения. Примечание: на момент 5 у нас уже есть TFS, продукт, который включает в себя систему отслеживания ошибок. Я единственный, кто сегодня его использует. Я не знаю ни одного разработчика компании, но я точно знаю, что у некоторых нет списка ошибок, даже в Excel или в простом текстовом документе.
Арсений Мурзенко
2

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

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

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

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

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

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

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

jmoreno
источник
1

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

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

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

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

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

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

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

SJuan76
источник
Я бы сказал, что множественные прерывания - это плохая рабочая среда. Если есть какой-то громкий шум, то это следует устранить. Что касается электронной почты, научитесь не допускать их. Скажем, 10 минут, когда вы приступите к работе, после обеда и перед тем, как уйти, чтобы проверить свою электронную почту. Старайтесь не проверять их постоянно в течение дня, если только вы не знаете, что для вас что-то критично.
mgw854
@ mgw854 Я перечитал свой ответ и согласен с тем, что он может показаться немного жестче, чем я хотел. Я не имею в виду в любой момент, что проблемы - только ошибка ОП, и окружающая среда (и физическая и организационная) кажется ужасной. Я уверен, что даже для лучших программистов эти проблемы сильно повлияют на производительность. Я просто указывал пути сокращения «разрыва», который, по-видимому, чувствует OP, существующий с другими программистами в той же среде.
SJuan76
0

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

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

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

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

Хорхе Мендоса
источник