Повторное использование, перезапись или рефакторинг?

Question

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

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

• // WHY IS THIS NOT WORKING
• // I know this is bad but were going for working stuff right now...
• // This is a PHP code outputing Javascript code outputting HTML...do not go further
• // Not userful

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

Редактировать: Спасибо всем за ваш быстрый и полезный совет!

Answer 1

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

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

Answer 2

На самом деле это зависит от размера и объема того, на что вы смотрите.

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

Рассматривая приведенный выше пример кода, можно подумать, что целесообразно отправить фрагмент кода на thedailywtf.com. ;)

Answer 3

Все время от времени наследуют плохой код.

То, что вы получили здесь, является довольно классическим примером того, что я видел в прошлом (на самом деле я видел хуже). Хотя я понимаю желание переписать (и действительно, если ВСЕ код плохой, вы должны серьезно подумать над этим вариантом) - ваш менеджер может не пойти на это или, по крайней мере, не сразу.

В любом случае, вы будете иметь дело с этим некоторое время. Я бы убрал столько, сколько ты можешь, или - если это касается клиентов - выдвинул вопросы безопасности. Если код такой плохой, как я подозреваю, из того, что вы опубликовали, он, вероятно, изобилует такими удовольствиями, как инъекция SQL, плюс немного CSRF и XSS. Таким образом, если вы используете его для чего-либо, что должно быть безопасным, вы можете найти хороший повод для его «улучшения».

Answer 4

Я не фанат рефакторинга ради переписывания / рефакторинга, так как работаю в зрелой, унаследованной среде. Более важно увидеть «что изменилось» в истории исходного кода, чем увидеть красивый код. Большинство наших изменений связаны с отчетами об ошибках или утвержденными «запросами на изменение» с формальными требованиями. Но здесь я говорю о коде, который в основном работает, а ваш - нет. Так что в вашем случае, когда вы работаете с кодом, который в настоящее время не соответствует требованиям (ЛЮБЫМ требованиям, прошлым или настоящим), я бы сказал, что нужно переписать.

Answer 5

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

Answer 6

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

Просто учитесь работать с тем, что у вас есть, и приносите как можно больше пользы. Конечно, если вы действительно оценили глубину кода и все же пришли к выводу, что вы могли бы написать его с нуля быстрее, чем исправлять его, предоставьте (запланированный) график времени своему боссу и посмотрите, куда он идет.

Answer 7

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