Как перенести крупное PHP приложение на Python?

Question

[Игорь Семенов]

Всем привет!

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

База данных меняться не будет (MySQL), а её структура и подавно. Поэтому будущая система должна писаться с оглядкой на уже существующие данные и базу.

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

Изначально планировали смотреть на Django. Но немного познакомившись - смутились:

1. Структура пользователей (и не только) в базе должна строго ложиться на уже существующую. Структура Django нам не подходит. Или нужно переписывать стандартную структуру и исправлять это (что мы так понимаем делать крайне не рекомендуется).
   
2. Тоже самое касается прав доступа, логов, отчасти сессий (не принципиально) и прочих плюшек которые идут в джанго "из коробки"
   
3. Админка "из коробки" не подходит по всевозможным причинам. Начиная с дизайна-юзабилити и заканчивая структурой. Из-за этого мы плачем по ночам...
   
4. ORM хорош, но есть места где придётся им пренебречь
   

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

Поэтому вопрос таков: на чем стоит разрабатывать приложение?

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

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

Возможно мы где-то пропустили важные моменты для понимая сути проблемы - пишите, обязательно дополним.

Comments

[v- smerti]

А для чего именно вы собрались переписать на питон? Если производительности хотите то ждите пхп7 + phalcon уделает любой питоновский фреймворк. Если хотите более менее понятную архитектуру то опять же на питоне вы напишете кучу не поддерживаемого говна так как не когда с ним не работали. Продолжать список почему не надо писать вам на питоне?

[beduin01]

Вы уверены, что вам Python нужен? Попробуйте vibed.org

[FanatPHP]

Очередной вопрос из серии "мы серьезная команда профессионалов. мы не знаем, что нам надо и зачем. расскажите нам пожалуйста"

[Александр Таратин]

Возможно мы где-то пропустили важные моменты для понимая сути проблемы

Зачем вообще переписывать? Надежда на повышение производительности? (если да, то плохая идея: 1. питон медленный, 2. упретесь в скорость базы, которая остается без изменений)

[Игорь Семенов]

Это не лично наша инициатива...Мы бы при желании вообще ничего не переписывали))
Я думаю тут вопрос скорее в поддерживаемости, чем в производительности

[Борис Сёмов]

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

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

Answer 1

[Сергей Протько]

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

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

Если же так считает руководство - пусть они и переписывают. Достаточно просто набросать риски на бумажке сходить к ним и сказать "это будет в 3 раза дороже" и возможно они одумаются. Ну а коль уж переписывать всеравно заставят то можно спокойно менять структуру всего и вся. Риски от этого не увеличатся сильно уже.

Я бы пытался настаивать на постепенном развязывании системы и рефакторинге с последующим переводом на Symfony2

Comments

[Игорь Семенов]

А почему именно Symfony2?

[Сергей Протько]

Игорь Семенов: потому что можно постепенно переводить на отдельные компоненты оного и затем уже полностью на фреймворк. Для средних и больших проектов единственный конкурент Symfony это Zend2, но я если честно его недолюбливаю, хотя и считаю очень даже неплохим.

[Сергей Протько]

Игорь Семенов: так же нет никаких ограничений по реализации. Минимальная связанность системы и все такое.

Answer 2

[bromzh]

Самое простое - взять Flask и SQLAlchemy. Прикрутить ОРМ джанги к готовой базе труднее, чем в SQL. Да и сам фласк не навязывает свои решения, он модульный. Нужна админка - ставь отдельно. Аутентификация тоже отдельно. ОРМ отдельно, и т.д.

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

Answer 3

[Viktor Vsk]

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

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

Не хотите даже структуру базы и работу с сессиями менять? Тогда все просто:
1. Разработчиков Джанго меньше, чем разработчиков пхп (подставьте ваш фреймворк)
2. Разработчиков перепиленного под пхп джанго еще меньше, чем просто разработчиков джанго.

Я бы может сказал, что в Rails есть некоторые возможности поизвращаться, что б поддерживать кастомные названия таблиц, структуры и т.д., но как-то не логично: использовать фреймворк (культуру, опыт и бестпрактис сообщества), что бы пойти против культуры, бестпрактис и опыта сообщества.

Comments

[Игорь Семенов]

Спасибо за развернутый ответ.

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

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

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

[Viktor Vsk]

Игорь Семенов: очертить бизнес-цели, подумать о развитии, описать требования, составить тз, написать аксептанс-тесты, переписать с нуля. Если вся проблема в базе, то в ActiveRecord в рельсах каждой модели можно задавать имя таблицы и имя ключа. Уверен, что в джанге не может не быть такой возможности.

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

[Игорь Семенов]

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

[Viktor Vsk]

Игорь Семенов: Rails в примере для того, что бы дать понять, что если там это делается одной строчкой, то в джанге явно не может быть все настолько плохо, что б его перелопачивать пришлось.

[Игорь Семенов]

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

[Viktor Vsk]

Игорь Семенов: Мне кажется вот это - https://docs.djangoproject.com/en/dev/ref/models/o... - решает все проблемы с кастомным именованием таблиц. Или что-то упускаю?

[Игорь Семенов]

Виктор Выскребенцев: там не только кастомные наименования. Там ещё связь между сессиями, правами доступа и прочим...Видимо вопрос задан некоректно, раз он настолько непонятен. Наверно нужно будет подумать как его сформулировать и задать заново.

[Viktor Vsk]

Игорь Семенов: наверное. потому что если у вас права и "связи между сессиями" разруливаются на уровне базы данных, то приложение действительно сложное.

[Игорь Семенов]

>>потому что если у вас права и "связи между сессиями" разруливаются на уровне базы
В том смысле, что в джанге есть зависимость от этих данных в их виде по умолчанию, у нас же в базе они представлены по своему и изменения кастомных названия тут не поможет.

Answer 4

[Борис Сёмов]

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

Что выбрать вы не знаете => даже если что-то выберите по советам, наступите на массу граблей при освоении выбранного... Будет может и более "модно", но весьма вероятно вероятно не лучше чем есть, а возможно и хуже.

Структура базы не меняется => кардинально не поменяются и запросы, а значит, и время их обработки не изменится. А это, обычно, куда более узкое место.

Comments

[Игорь Семенов]

Я примерно изложил суть под ответом Виктора Выскребенцева. Переписывать проект придется, только под что и на что. Руководство решило на Python. А вот как и как это сделать проще не ломая голову себе и будущим программистам? Вот в чем вопрос.

[Борис Сёмов]

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

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

[Игорь Семенов]

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

[Борис Сёмов]

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

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

[Игорь Семенов]

Спасибо, мы это понимаем, но мнение общественности перед тем как приглашать программиста не помешает)

Answer 5

[Neonailol]

1. Поднимаете rest сервер на питоне
2. over json вызываете методы этого сервера (прямо file_get_contents($url+$data)), постепенно заменяя код пхп, на вызовы по api к pythonу
3. ...
4. Profit!

Answer 6

[globuzer]

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