Главное — не переписывать код

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

Понимание

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

Стоит ответить на несколько вопросов и только после этого что-либо предпринимать:

  • Можно ли безопасно пренебречь плохим кодом?
  • Хорошо ли я разобрался в вопросе, понимаю ли я этот код?
  • Я могу написать лучше?
  • Есть ли риск, что свежий код создаст ошибки и другие проблемы? Подобное часто бывает с непокрытым тестами кодом. Готов ли я нести ответственность за возможные последствия?
  • На каком этапе проект? Важно оценить трудоемкость процесса и понять сколько времени он займет. К этому желательно отнестись как можно серьезнее, ведь можно просчитаться не на дни, а на месяцы.

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

Если же перед вами стоит вопрос серьезной доработки, а система не предусматривает возможность надстройки или устарела, необходим разговор с заказчиком. Важно просто и понятно объяснить почему расширение текущей системы станет долгим/дорогим занятием. Нередко заказчики не готовы к переписыванию уже работающей системы, поэтому от вас будут ждать убедительного обоснования. Расскажите, как именно низкое качество кода выльется в сложности с поддержкой и расширением системы. Что в зависимости от тяжкости ситуации, последнее может выглядеть как приматывание мощной турбины к ржавому велосипеду без колеса. Уточните насколько важно сохранить код в текущем состоянии. Если критически, то заказчик должен понимать, что:

  • проекты, основанные на анти-паттернах по типу God Object и Magic numbers, в которых математическая магия перемежается с бесконечными отсылками к двум переменным, потребуют несколько дней работы, вместо часа, для предельно простой смены одного условия;
  • bus factor — проектах с некачественным кодом фактор автобуса зачастую непростительно низок: никто не сможет совладать с кодом, когда ответственный за него заболеет, уволится или попадет под автобус. Жестко, но заказчику, в этом случае, придется заново нести абсолютно все убытки, которые он уже покрыл, когда передавал проект более компетентной команде.

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

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

Возможно, не все так плохо

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

К относительно легким проблемам можно отнести отсутствие комментариев. Да, возможно, вам придется долго разбираться в особо заковыристых местах, но если ваш предшественник все структурировал, расписал и не забил код повторениями и другим мусором, вам останется просто написать комментарии вместо него — опять же, неприятно, но терпимо. Почему вам нужно их писать, если вы и так смогли разобраться? Чтобы ускорить разработку в дальнейшем — как для себя, так и для коллег.

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

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

Не стоит забывать, что вышеописанные проблемы могут ходить парами или объединяться в «огромного робота», почти как отдельные юниты в Могучих Рейнджерах, только не во имя добра и справедливости. Думаем, вы уже догадались, что это не очень приятно.

Legacy code — устаревший не всегда плохой

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

Заметили ошибку? Выделите ее и нажмите Ctrl+Enter, чтобы сообщить нам.

27.12.2018
121
Автор: Ася Яскер

Сообщить об опечатке

Текст, который будет отправлен нашему автору:

Ваш комментарий (необязательно):