Legacy PHP code

Хотелось бы услышать советы тех, кто сталкивался с ОЧЕНЬ старым и убитым кодом (PHP). Гуглил совестно, нашел много полезного, но все равно обращаюсь к вам.

На данный момент поддерживаю груду старых php скриптов с вкраплениями perl.
Все писалось г@внокодерами молодыми разработчиками на протяжении 10-15 лет методом копипасты и занимает около 500 тыс. строк (это без сторонних библиотек).
Всю жизнь скрипты писались и правились на боевом сервере по FTP без средств контроля версий.

Все написано в стиле:

mysql_connect(хардкорно, прописаннные, параметры соединения) or die("err!«)

Возможно ли хотя бы частично перенести разработку на локальную машину? О полном разделении dev/prod речь не идет, так как скрипты взаимодействуют со специфическим ПО под FreeBSD.

Скрипты, базы данных имеют разные кодировки (KOI8-U, KOI8-R, UTF-8, WINDOWS-1251), поэтому в IDE (PHPStorm) массовый поиск и замена вызывают сильную попоболь. Может, кто-то знает как с этим бороться?

Идея «переписать все с нуля» руководству не нравится, да и у одного разработчика на это уйдет вечность. Работаем с тем, что есть.

Кто сталкивался с таким? Как налаживали процесс разработки?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Тут еще такой момент — нужно понимать, как соотносится то, что код делает с тем, что должен / не должен. Никакой же документации там при таких раскладах быть просто не может. Вопрос в том, есть ли доступный эксперт в том, как оно должно работать. Если нет, то труба сразу. Т.е. ты смотришь на код — видишь баг. А потом не знаешь — а вдруг это и не баг вовсе, а фича. И все. Или видишь код какой-то, он вроде не нужен вообще, можно его и не рефакторить, а просто выкинуть — а как решиться, вдруг зачем-то еще нужно? Надо у кого-то спросить и получить ответ.

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

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

Это просто захватывающе:

$leased[$year[$key]][$value][$c] = $leased[$year[$key]][$value][$c-1]+$leased[$year[$key]][$value][$c];
$dialup[$year[$key]][$value][$c] = $dialup[$year[$key]][$value][$c-1]+$dialup[$year[$key]][$value][$c];
$domain[$year[$key]][$value][$c] = $domain[$year[$key]][$value][$c-1]+$domain[$year[$key]][$value][$c];
$web[$year[$key]][$value][$c] = $web[$year[$key]][$value][$c-1]+$web[$year[$key]][$value][$c];
$sum[$year[$key]][$value][$c] = $leased[$year[$key]][$value][$c]+$dialup[$year[$key]][$value][$c]+$domain[$year[$key]][$value][$c]+$web[$year[$key]][$value][$c];

не так страшно, как бывает:)
переменные могли бы быть названы по-короче, или того хуже ну венгерском

зато такой код рефакторить легко. Заумный бывает вреднее.

Сталкивался с подобными гoвнокодо-монстрами пару раз. В обоих случаях, рефакторинг происходил в несколько проходов, начиная с локализации кучек говна в классах\модулях\шаблонах\js\css. Параллельно шла очистка БД и директорий проекта от ненужных таблиц и файлов. Когда все помои были распиханы по вёдрам, пошёл второй этап переноса, с использованием уже определённой архитектуры, маппинга базы, нормализации кодировок и прочего, избавления от антипаттернов. Оба проекта и поныне успешно развиваются, девелоперы вздохнули свободно.

Подумалось: интересно, способны ли на такое индусы?... Не технически, а практически.

Индусы подобны богам: только создают и потом созидают :)

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

тогда капец. это как жестокая бойня, на которую отправили курсанта.

Еще для развертывания тестовых сред можно посмотреть в сторону виртуализации / автоматизации инсталляции. А ля VirtualBox, Vagrant, Puppet, Chef. Но может быть это для вас оверкил, если в облака не ходите и часто разворачиваться не нужно. Но все равно может быть полезно чтобы workstations не закаживать.

Не слушайте тех, кто советует уходить. Опыт по приведению в порядок бардака идет за 5 green field development. Если не 10. Ну конечно еще зависит от того насколько адекватна команда и менеджмент. Если последние уже поняли что иногда стоит инвестировать время на подчистку кода, то может вполне все получится. Главное, как правильно советуют коллеги, не стараться починить все и сразу, рефакторить осиливаемыми кусками. А со временем прийдет лучшее понимание системы и еще большее доверие заказчика.

Опыт по приведению в порядок бардака идет за 5 green field development.
только если за это платят хотя бы 2х
только если за это платят хотя бы 2х
*чисто гипотетически* ну, если «каждые полтора года нормально менять работу» и «на новом месте предлагают на 30% больше», то за это заплатят даже больше, чем вдвое больше — после джуниора через год уже спокойно пройдешь собеседование на интермида.

Пока что за это платят 0,5 зарплаты среднестатистического джурниора :(

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

В городе только одна открытая вакансия.
Ладно, если не пройду собеседование. А если пройду, а там не срастется?
Стремно. Но я все равно об этом думаю.

что за город-то такой чудный?
тогда только переезжать. и лучше — пораньше, пока не прирос

Ага, Кировоград настолько суров, что там нормально платят только за связку Qt&&С+&&С++

Ну тут или переучиваться, или валить (второе, кстати, не так уж страшно)

как альтернатива — всякие одески и лансы.

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

Нельзя работать в городе, где на выбор только 1-2 вакансии. То есть как бы можно, конечно, но уныло.
Наберётесь опыта минимально достаточного — устраивайтесь в Киеве/Днепре/Одессе. Будете нормально жить и забудете этот кошмар, описанный в посте.

Опыт по приведению в порядок бардака идет за 5 green field development. Если не 10.
А я считаю, что это наоборот — застревание в болоте без современных технологий и без изучения нормальной архитектуры. Это потеря сил и времени, переходящая в потерю интересных возможностей.
И если такого человека потом посадить делать что-то с нуля, то он растеряется в полностью непривычной ситуации, что скажется на качестве его работы.

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

И если такого человека потом посадить делать что-то с нуля, то он растеряется в полностью непривычной ситуации
А вот это гон и неправда.
если получится отрефакторить

Если.

А вот если нет, если не получится — тогда конечно на 100% соглашусь с советом валить при первой нормальной возможности.

Может, кто-то знает как с этим бороться?
— начинать искать новую работу
— если поиск и замена только английских букв, то они во всех кодировках одинаковые. sed/grep в помощь. (в гит есть свой поиск — пошустрее стандартного грепа — git help grep )
— переписывать с нуля не нужно. а вот рефакторить по кускам имеет смысл, хотя всеравно выйдет plain php с ооп . чуть получше каши, но всеравно
— алтернатива — поставить рядом какой нить фреймворк и новые (исправляемые) куски по частям «втягивать»

перед рефакторингом желательно хоть минимально сделать тесты, ну не знаю , хоть просто через wget скачивать куски перед изменением, потом чет менять и потом опять же wget и сравнивать

В простых случаях для рекурсивного поиска и замены хорошо показал себя Sublime — есть Save All, при сохранении в неопознанной кодировке ничего не ломает.
Рядом поставил Codeigniter — сервере PHP 5.2 да и еще без PDO, новый функционал пилю уже там. Уже легче, но очень интересные схемы БД все равно дают о себе знать.
А так да — ну его все в пень :)

Попросите себе PDO на сервер, думаю это не большая проблема

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

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

Опять же: пока проект нельзя перенести на локальную машину, нужно работать с git прямо на production-сервере? Такое бывает?

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

бывает и не такое. Обычно с кодом как минимум работать удобно локально для рефакторингов. Потом перепроверил визуально изменения и пуш на продакшн.

Не мучайтесь — уходите.

Это только первое место работы. Боюсь что будет в других конторах :)

тогда не удивительно, что вопрос волнует :)
надеюсь только, волнует не только вас

Тогда я бы начал с разговора с начальством. Но я так понимаю они лучше сами знают, раз это 10-15 лет так писалось и поддерживалось. И вас они не послушают скорее всего (ожидаемо).

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

делать ноги, на Вас просто повесили то что всем впадлу. Писать наново это никто не будет и сайты ети если за 15 лет не пропали то так и не пропадут. И что тогда? всю жизнь такое суппортить =))))?

Рефакторинг кода в бодишопе самое неблагодарное дело, которое только может быть.

рефакторинг в одиночестве при полном неодобрении начальства и вставлении палок в колеса — кошмар, не зависящий от формата конторы

Даже если получится получить одобрение начальства и заказчика — все равно ну его нафиг..

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

чем рефакторинг в бодишопе отличается от рефакторинга в продуктовой конторе?
В коммерческих проектах ничем. В некоммерческих, своих проектах и т.п. — совсем другое дело.
чем рефакторинг хуже реализации новой супер-пупер никому нафиг не нужной функциональности?
Спросите у заказчика
чем рефакторинг хуже багфиксинга «методом костыля»?
В том то и дело что ничем, только это мы с вами понимаем, а руководство и заказчики нет! Каждый раз, когда я входил в новый проект, я предлагал провести рефакторинг, т.к. не мог смириться и привыкнуть к имеющимся костылям, не говоря уже о новых фичах, которые доставляли неимоверную головную боль.. Я приводил конкретные примеры той или иной проблемы, подробно рассказывал о всех плюсах которые мы получим в будущем после рефакторинга и все было хорошо до тех пор, пока не доходило до выделения часов на это дело... Стандартный ответ «ну 2х дней тебе (вам) хватит» или «четверть спринта достаточно?»
Сказать заказчику, что нам необходим к примеру месяц на качественный рефакторинг — все равно что сказать что твой проект г-но, его писали либо д*илы либо люди не придерживаясь никаких норм, лепили как попало по-быстрее. А он то думает что все ок, ведь все работает, а тут пришел невесть кто и начал выделываться, да и результат будет виден не сразу и т.д.
Лично мне один раз удалось выбить на это время, только потому, что я пообещал, что система будет работать в 2 раза быстрее. Оказалось на деле в 50 раз, ну это ничего, единичный случай. Если у вас по другому и начальство вместе с заказчиком идет вам на встречу, то вам повезло ) Хотя може это мне не везет )

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

Хуже не будет.

Возможно ли хотя бы частично перенести разработку на локальную машину? О полном разделении dev/prod речь не идет, так как скрипты взаимодействуют со специфическим ПО под FreeBSD.
очевидно, что все зависит от того, что ж это за «специфичное ПО». можно ли его эмулировать? можно ли его использовать удаленно? безопасно ли к нему обращаться из тестовой среды(к примеру, сервис по перекодированию видео относительно безопасен — по крайней мере, не затронет реальные данные, только тормозами чреват; а вот хитрая БД — уже желательно своя, с тестовыми данными)?

Сетевое ПО (файервол, VPN-сервер, RADIUS-сервер) для сервера доступа (NAS).
Любая осечка, ошибка в конфиге — и все клиенты отвалятся :(

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

замокать было бы очень хорошо. В идеале, если внешняя система/ы предоставляют интерфейс, который вам легко реализовать (ну там REST или WS* всякие) — то можно просто реализовать свою моковую имплементацию, которую подставлять на staging/development. Если же ситуация более сложная — можно подумать выделить свою компоненту для общения с этим специфическим ПО, определить для нее простой интерфес и далее см. шаг 1. Минус — некоторое усложнение инфраструктурное, также скорее всего прийдется порефакторить некрасивый код с замазанными по самое нутро низкоуровневыми деталями коммуникации. Но плюсов тоже много, в виде возможно большей прозрачности, разделения ответственностей компонент.
Можно еще мокать внутри кода, типа если (environment != production) то вместо классов говорящих с внешними системами запускать свои моки/заглушки, но это намного менее полезно.

с РНР не сталкивался, но мнение имею(имею опыт в разгребании подобного на джаваскрипте) :D
а) сводим до кучи кодировки скриптов — в противном случае, не сможем использовать кучу инструментов статического анализа кода, которые должны существенно упростить процесс
б) в IDE(тем более, phpStorm) ищем дубликаты и ненормальные конструкции(inspect code) — первые кандидаты на рефакторинг
в) решить вопрос с тестированием: регрессии будет дофигища в процессе раскопок
г) потихоньку анализировать, проводить декомпозицию самых запутанных мест, разбивая простыни-скрипты на функции, простыни-функции на композиции из функций.
д) желательно на время рефакторинга не трогать соответствующие компоненты: мерджить фиксы в старой версии кода и отрефакторенный код — адский ад почище любого рефакторинга самого по себе

в своё время столкнувшись с похожей хренью просто переписал всё с нуля на zf — повезло
здесь остаётся только посочуствовать
наверное нужно сразу рефакторить при разработке и по чуть-чуть избавляться от копипасты

можно попробовать написать скриптик, который пройдётся по коду и сделает более умный поиск и замену

Підписатись на коментарі