@skobkin не. Нужно рефакторить много десятков тысяч строк тупого говнокода на пхп с файлами по полторы-три тыщи строк. Настоящий мешок топленых сникерсов, к которым никто прикасаться не хочет даже, в том числе и я. Надо вырвать php из html-тегов (а потом желательно и жаваскрипт тоже сепарировать оттуда), и я знаю, что четвертый жопате это может.
@drq эм-м, боюсь, жпт тут не поможет. Результат же ещё надо будет проверять на работоспособность и эквивалентность. А жпт очень уж склонен выдумывать "правдоподобное по мотивам", но совершенно не работающее – это тупо следствие его устройства. Иногда промпта хватает и он не отклоняется, но иногда нет. И делает он это внезапно – что надо заметить и отреагировать.
Если тестовое покрытие хорошее есть (функциональное, не прибитое гвоздями к структуре кода), то ещё на что-то можно рассчитывать. Но я подозреваю, что здесь его нет. И работы выйдет даже больше, чем просто вдумчивого рефакторинга в костюме химзащиты.
К сожалению, если компания уже рассталась с теми, кто процессы дизайнил, теперь это делать некому, а документации по имеющимся не осталось, то компания уже загнала себя в глубочайшую задницу, из которой без найма (предметных экспертов или инженеров, в зависимости от метода) уже вряд ли выйдет. А на найм у неё может не быть денег.
Если так, то компания буквально хочет чуда. А чудес, к сожалению, не бывает. Даже в жпт.
@dside@drq
> а документации по имеющимся не осталось
Вот для этого, кстати, можно использовать GPT. Генерится документация, а потом продуктовые менеджеры или аналитики проверяют то ли что нужно это.
> Если так, то компания буквально хочет чуда. А чудес, к сожалению, не бывает
В целом да.
Просто растащив по разным файлам можно только чуть улучшить читаемость. Но запас временной прочности (сколько это ещё будет работать с обновлениями того же PHP) не увеличится.
Переписывание - оно ведь не только убирает ненужные куски и учитывает ошибки первичной проектировки - оно ещё обычно и берёт обновлённый стек, который будет лучше отвечать требованиям сегодняшнего и завтрашнего дня.
Убираются депрекейты, начинают использоваться новые возможности вроде строгой типизации и прочего, которые выявляют ошибки ещё на стадии стат. анализа, а не уже где-то в проде.
Это немного противоречащие друг другу вещи если компания хочет чтобы оно РАБОТАЛО и оно для компании ВАЖНО.
Штука может быть написана на коленке если она небольшая и её контекст не особо сложно охватить своим вниманием. Поэтому, например, микросервисы могут быть иногда написаны жопой - их легко переписать нормально без боли.
Но если там начались простыни - это значит, что вы НЕ МОЖЕТЕ ЭТО ПОДДЕРЖИВАТЬ.
Потому что там не разделены ответственности, разработчик не может охватить своим вниманием нужный ему контекст потому, что он размазан по всей простыне.
И получается, что либо разработчик тратит бесконечное количество времени на доработки/фиксы, либо он делает это быстро, но допускает ошибки или просто ещё сильнее ухудшает работу системы другим образом.
В итоге это просто раскидывание граблей, на которые компания наступит в критический момент.
> Слишком умные слова
Я это к чему. Умные слова как раз и появляются потому, что если их не применять, при разрастании код становится не поддерживаемым, не обновляемым.
Вот у тебя же сейчас там ПИЗДЕЦ, верно? Пиздец потому, что кода ДОХУЯ, а в осязаемое время его нельзя заставить делать то, что нужно: работать чуть по-другому как стало нужно только что, работать на новой версии языка, заиметь новую функцию. Нужное подчеркнуть.
Это нужно доносить до руководства компании если это говно выполняет важную роль в её работе. Иначе в один день они проснутся от того, что работа стоит, а как это исправить - непонятно.
Ну вот например сидите вы на древней версии PHP 5.3.X из-за необновляемого кода.
А тут раз - вышла уязвимость уровня heartbleed, где любой желающий через обращение к вашему коду может память сервера читать и дампить ваши базы потихоньку.
Вам нужно срочно обновляться на версию, которая мейнтейнится, а код на ней не запускается.
И у вас получается выбор между тем чтобы сидеть в луже выделений или схлопнуться.'
Если компания полагается на IT-продукты в своей работе, то она должна за ними вменяемо следить.
@skobkin Там не "начались" простыни. Они там были всегда, года с 99-го. И надо это как-то срочно исправлять.
Я про то, что там много, но очень тупо, и каких-то сложносочиненных конструкций, стеков и фреймворков и прочего нет - оно все плоское как блин. А это уже шанс того, что это можно разобрать с небольшой помощью автоматизации. Налажает слегка - ничего страшного, потом подгоним.
@drq@dside
А что если посмотреть на это со другой стороны?
Составить с помощью GPT документацию/требования.
Написать нормально с учётом сегодняшнего дня с использованием тех самых фреймворков
Просто я не понимаю, какого результата хочешь добиться ты. Да, у тебя сейчас там одна простыня, где PHP, HTML и SQL.
В итоге, я так понимаю, ты хочешь получить три простыни, где PHP, HTML и SQL, но отдельно.
Это типа чуть-чуть полущ, конечно, но это всё равно будет тяжело поддерживать.
А если вы в итоге начнёте это натягивать на современный подход - вы всё равно будете всё переписывать. Уже второй раз.
@skobkin Да, я хочу получить три файла, из которых один - это шаблон html, другой - php и теми четырьмя с половиной функциями, которые были размазаны по всей простыне тонким слоем без какой-либо паковки, третий - js.
Поверь, одно лишь это - в 100500 раз улучшит положение. Так можно уже будет хотя бы начать искать закономерности и повторяющиеся функции, чтобы потом их вынести в библиотеку.
@drq@dside
Ниже сказанное - оно не относительно тебя, а чисто жизненное наблюдение.
Ценный сотрудник - это не только тот, который когда надо пойдёт и без вопросов горы свернёт, разгребёт любое говно и во всём разберётся, но ещё и тот, кто вовремя может сказать, что в текущем положении правильнее будет принять более сложное, но правильное решение чтобы потом не было очень больно.
Само собой, это должно быть в пределах здравого смысла - иначе появляются ребята, которые вчера написанное на PHP идут переписывать на Go, а через неделю - на Rust.
Но судя по твоему описанию, у вас там прямо запущенный случай, когда может быть разумнее сесть, подумать и сделать как надо.
@skobkin Я на это сложное, но правильное решение его упрашиваю уже года три, наверное. Мол, выкинь ты хуйню эту свою, составь список требований, найми нормальных разрабов и пусть они тебе за пару месяцев напишут.
Нет, боится.
А инъекции от кучи голого SQL-а в рандомных местах ловить, видимо, не боится.
> Мол, выкинь ты хуйню эту свою, составь список требований, найми нормальных разрабов и пусть они тебе за пару месяцев напишут. Нет, боится.
"Боится"... Жаба душит скорее. Это если отдавать разработку в аутсорс серьёзной компании с договором и всеми делами. Ну а если тупо нанимать фрилансеров (а скорей всего под "нанять разрабов" он подумал именно это) и самому пытаться руководить разработкой, то есть чего бояться конечно ))
@drq
единственное, есть сложности с vpn, многие vps и известные провайдеры vpn не будут с ним работать.
я так понимаю, таким образом борются с теми "сервисами", ссылки на которые уже давали. @rf
Add comment