Как вы остаетесь продуктивным, когда имеете дело с крайне плохо написанным кодом?

У меня нет большого опыта работы в индустрии программного обеспечения, самоучки и участия в открытом исходном коде, прежде чем я решил устроиться на работу. Теперь, когда я работаю за деньги, мне также приходится иметь дело с некоторыми неприятными вещами, что, конечно, нормально.

Недавно мне было поручено добавить ведение журнала в большой проект SharePoint, который написан каким-то программистом, который, очевидно, учился программировать на работе. После 2 лет совместной работы клиент перешел в нашу компанию, но ущерб был нанесен, и теперь мне как-то нужно поддерживать этот код.

Не то чтобы код был слишком сложным для чтения. Несмотря на проблемы - у каждого проекта есть один класс с несколькими скопированными методами, огромными ifвложениями, венгерскими системами, неразмещенными соединениями - он все еще читабелен.

Однако я оказался совершенно непродуктивным, несмотря на то, что работал над чем-то таким простым, как добавление журналов. По сути, мне просто нужно пройтись по коду шаг за шагом и добавить несколько вызовов трассировки. Однако идиотизм кода настолько раздражает, что я устаю через 10 минут после запуска . Вначале я использовал для добавления usingконструкций, уменьшения вложенности путем обращения ifк ним, переименования переменных в удобочитаемые имена, но проект большой, и в итоге я сдался. Я знаю, что это не та задача, которую я должен выполнять, но, по крайней мере, уменьшение беспорядка дало мне какое-то психологическое вознаграждение, чтобы я мог продолжать. Теперь трюк перестал работать, и у меня осталось 60% работы.

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

Это не просто одна большая напыщенная речь, потому что у меня действительно есть актуальный вопрос:

Есть ли способ оставаться продуктивным и не бороться с ветряными мельницами?

Есть ли какое - то психологический трюк , чтобы оставаться сосредоточенными на задаче, вместо того чтобы думать : «Как глупо это что ?» Каждый раз , когда я вижу еще один хитрый трюк предыдущего программиста? Проблема с добавлением журналов заключается в том, что я действительно должен понимать, что делает код, и это причиняет мне неприятный мозг.

Извините, что говорю вам, но не все работы полны солнечного света и гламура. Большинство задач по разработке включает в себя работу с другами, подобную этой. Грустно, но верно.

Перед вами стоит важная работа, даже если вам скучно смотреть, как краска высыхает. Это важно по двум причинам: 1. Он добавляет очень необходимую регистрацию в большую систему, так что, когда что-то пойдет не так, у вас будет инструмент, который поможет вам его найти. и 2. Он знакомит вас с базой кода, так что если и когда что-то пойдет не так, вы можете подключиться и исправить это.

Вы в основном создаете свою собственную сеть безопасности здесь. Гламур нет, но важно да!

Итак, как говорится, как вы должны мотивировать себя? Когда на работе у меня возникает оцепенение, я ставлю перед собой цели. Завершите выполнение задачи x к концу недели. Если я делаю свою цель, я вознаграждаю себя. Новый ресторан, который я хочу попробовать? Иди в пятницу вечером, если я закончу. Новый фильм только вышел? Посмотри на выходные, если я закончу.

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

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

Сохраните файл фрагментов кода кандидата для отправки на thedailywtf.com. Даже если вы на самом деле не собираетесь их отправлять, это дает вам хорошую возможность найти код, который даже хуже среднего.

Я был в подобной ситуации, когда мне было поручено очистить большой объем плохо написанного, скопированного и вставленного кода.

Чтобы поддержать мою мотивацию и здравомыслие, я написал скрипт под названием current_scoreLOC в проекте (который постоянно уменьшался, поскольку я устранял дублирование и переключался на более совершенные алгоритмы) и сравнивал его с LOC при запуске. Всякий раз, когда я разочаровывался или расстраивался из-за огромного количества кода, с которым столкнулся, бег current_scoreдавал мне ощущение ощутимого прогресса и напоминал мне о том, чего я уже достиг. И было забавно видеть, как высоко я смог набрать очки, когда занялся особенно плохим фрагментом кода.

Я бы искал похожие метрики, которые вы могли бы легко написать, чтобы дать себе ощущение прогресса и превратить его в своего рода игру. Строки кода (только что запущенный wc -l), цикломатическая сложность (которая должна уменьшаться при очистке этих мерзких вложенных «если»), строки кода, которые были затронуты вами вместо вашего предшественника (я думаю, что FishEye может сказать вам это за $ 10) и т. Д. Вы можете даже написать скрипт на Perl без особых проблем, чтобы подсчитать количество блоков кода, в которых еще нет операторов логирования.

Я видел эту книгу, рекомендованную: эффективно работать с устаревшим кодом , но, к счастью, не было необходимости ее читать.

Как вы делаете, рефакторинг того, что вам нужно, чтобы вы могли понять код и просто помнить, что вы реанимируете систему, которая окупится, когда вы будете поддерживать ее.
Надеюсь, это должно подстегнуть ваш путь на пути домой.

Попробуйте разбить проект на куски. Каждый день узнайте, как работает конкретный блок. Попытка понять все сразу - это, вероятно, то, что вас напрягает.

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

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

Например, когда я прохожу фрагмент кода, я буду постоянно делать заметки для себя. Это мой разговор с собой. Простой акт написания помогает больше мыслей выходить и помогает мне лучше понимать вещи. Через некоторое время у меня может появиться Эврика, и мне нужно будет нарисовать небольшую диаграмму с «увеличенной картинкой» на бумаге, чтобы проиллюстрировать, что я только что подумал или какие части я просто собрал. Я всегда делаю это только на бумаге, избавляясь от всех отвлекающих факторов компьютера. Это позволяет мне быть более методичным и вдумчивым в том, что я делаю.

Это в основном удобный способ иметь постоянный разговор с экспертом в области :)

Я знаю, что вы можете чувствовать себя непродуктивно, потому что вы смотрите на это с точки зрения «я только добавляю логи», когда на самом деле вы добавляете логи и делаете много рефакторинга. Ваш руководитель, вероятно, знает о ситуации с кодом. Каждый может не оценить это сейчас, но когда вы получите запрос на добавление действительно интересной и сложной функции, вы будете рады, что вы очистили код.

В этих случаях я стараюсь переписать часть кода. Чтобы одна область была меньше отстойной, а затем я просто добавляю записи в другие. Затем очистите еще немного кода. Плохой код плох, только если вы оставите его там.

Gamify вашей работы. Например, дайте себе 5 баллов каждый раз, когда вы задаете хороший вопрос о коде, и 10 баллов каждый раз, когда вы отвечаете на него. Каждый раз, когда вы реорганизуете метод или добавляете новую функцию, присваивайте себе значок. Как только вы наберете достаточно очков, вы получите такие привилегии, как кофе-брейки или печенье. После того, как вы завершите весь проект, вы получите возможность побаловать себя чем-то, что вам действительно нужно.

Хитрость в том, чтобы не скучать и не злиться, чтобы оставаться продуктивным, заключается в том, чтобы признать, что код плохо спроектирован. Принятие вашей позиции необходимости понимать и обновлять код позволит вам не комментировать «насколько это глупо», а вместо этого спокойно принять его и двигаться дальше.

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

«Эффективная работа с устаревшим кодом» Майкла Фезерса может помочь.

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