Вот ужасная история об унаследованном коде, которая, вероятно, звучит как минимум знакомо.

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

Форма информации о клиенте поддерживается чем-то, написанным почти десять лет назад давно ушедшим разработчиком. Для переноса этих данных из базы данных в форму используется класс из 60 000 строк, который называется DataRepositoryManagerHelper, а также используется гигантский XML-файл с нечетным интервалом и без схемы. Попытка добавить поле в эту форму делает вас Одиссеем, плывущим между Сциллой и Харибдой. На самом деле, вы почти уверены, что автор устаревшего кода вынудил назначенного разработчика отрезать и пожертвовать пальцем, чтобы заставить его работать.

Осознавая все это, вы смотрите на своего менеджера со смесью недоверия и ужаса, говоря ей, что вам понадобится как минимум 6 недель, чтобы сделать это. В вашей голове уже крутится дилемма между стратегическим рефакторингом там, где это возможно, и выполнением исчерпывающего ручного тестирования для каждого символа исходного кода и XML, которые вы изменяете. Теперь ее очередь недоверчиво выглядеть и говорит: «Я просто прошу добавить новое поле в одну форму». Вы уже говорили ей об этом раньше, и она явно забыла. Вы расстроены, но можете ли вы действительно винить ее? В конце концов, это звучит немного безумно.

Работа с устаревшим кодом

В прошлом я говорил об унаследованном коде как о коде, к которому разработчики боятся прикасаться (что я тесно соотношу с определением Майкла Фезерса как код без тестов). Если вы принимаете это определение как аксиоматическое, здесь есть важный вывод: унаследованный код создает разрыв между разработчиками и всеми остальными.

Как «все остальные» вы видите форму, которая нуждается в концептуально простой настройке. Как разработчик, вы видите мифологического монстра, который угрожает вырвать ваши пальцы из вашего тела; вы видите что-то, что внушает страх. И хотя телесный страх, о котором я говорю, — это преувеличение, внутренний страх перед неизвестным и отсутствием понимания — нет. Руководство просит вас сделать что-то, что оно считает простым, и ваша голова забита огромным количеством вариантов того, как все может пойти не так. И, что хуже всего, действительно сложно объяснить это так, чтобы это не прозвучало так, будто вы оправдываетесь, ленитесь или драматизируете.

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

Будьте чуткими

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

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

"Новенький!? Я позвал тебя сюда только для того, чтобы снова зажечь пилотную лампу!

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

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

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

Выйди перед этим

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

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

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

Теперь руководство может видеть проблемы в будущем. Это служит двум целям: (1) они не будут удивлены и (2) они могут начать думать о стратегиях восстановления.

Исправить

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

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

Первоначально опубликовано на сайте blog.ndepend.com 24 марта 2016 г.