Кому интересно. Опыт использования Django в довольно крупном проекте
(скажу - сочтёте за рекламу? =)).
Минусов у джанги вагон. Плюсы, впрочем, тоже есть. Поехали.
Минусы:
1. Идиотский темплейтный движок. Как жаль, ох как жаль, что не
догадались сразу прикрутить Jinja2. Используем Jinja2 в других
проектах с джангой - просто писаемся от восторга.
2. 90% фич не нужны. Ибо они просто ЧУДОВИЩНО медленные на больших
production базах. К примеру, тот же select_related. Ну есть у меня
10000 каких-то записей, у каждой из которых ForeignKey поле ссылается
лишь на 1 запись в другой таблице. И что мне теперь эту ещё одну
запись вытягивать 10000 раз?
3. Приложения не являются полноценными модулями для построения
модульной структуры. Можно конечно извращаться и использовать сигналы
как точки выхода, и какое нибудь api.py как точки входа - но.. сигналы
вызываются как попало, попытаться их вызывать "вот это после этого и
никак иначе" можно, но уже геморрой
4. Идиотский ORM. Хотя лучше - нету. Провоцирует использование хаков
на сложных запросов (типа pk__in=FakeSubquery()).
5. Нереально жуткие формы. Основной их минус - если поля зависят от
самих данных, то благополучно встаешь в тупик. Решается, заменив Form
на свой и используя его для наследования.
6. Упор на "ай одну строчку написал и все фурычит" вместо "написал и
работает эффективно" почти во всем.
7. Выполнения запроса в темплейтах. Да и вообще где попало "сам не
знаю где". Довольно быстро запросы без контроля могут превратится в
большую кашу. Конечно в темплейтах типа можно делать {% if %} и
выполнять кверисет, который приготовила вьюшка когда конкретно нужно.
Но именно это и превращает всё в кашу. Тем более - таким if-ам не
должно быть места в темплейтах. Зелёные разработчики прям так и не
могут удержаться от этого никак. В приложениях где каждый запрос надо
продумывать перед тем как писать - польза от такого ORM минимальна,
перед написанием filter(abc=d) все равно делаешь print queryset,
изучаешь чертов запрос, думаешь "да йопрст, ну что за идиотизм ты тут
собираешься делать, почему не просто ...". Как результат - тратишь
УЙМУ времени, да запрос руками быстрее можно было бы написать. Конечно
можно и писать руками, но как ловко сделать модельки из запроса, чтобы
save() работал? А через жопу - выбрать список ID своим "суперским"
запросом, а потом выбрать модельки через id__in=[pks]. Глупо? Очень.
Впрочем, все минусы которые были для нас очень существенны - мы
переписали нахрен в самой джанге (несколько патчей попало и в транк
=)), либо жестко регламентировали между собой (напрмимер, "никаких
запросов в теплейтах!"). В Debug режиме даже проверяется откуда пришёл
"пинок" на выполнение запроса и в тестах это проверяется.
Плюсы.. orm хоть и тупой, но он действительно работает. В тех случаях
когда речь не идёт о сложных и важных запросах - проще ничего нет.
Плюс абсолютное молчание и аккуратная обработка потери соединения,
маппинга к текущему потоку и проч вещах (чего в werkzeug очень
хромает, пока не потратишь уйму времени чтобы реализовать как в
джанге). Больше для меня плюсов в джанге нет. Извращение с
settings.py, думаю, все переписывают. У нас так вообще настройки
берутся из yaml, потом из global_settings, потом из local_settings и
ещё нескольких мест, где все можно оверрайдить. Равно как и пропатчена
джанга, чтобы позволять структуру вида app.web.webapp.models,
app.tools.toolsapp.models и тп
Вообще, я несколько разочарован в ней. Но не в джанге как фреймворку,
а в джанге как в фреймворке для серьёзных бизнес-приложений. Там ей
совсем не место.
Тесты.. эм.. это было первое что мы переписали почти целиком =)
Поэтому даже не в курсе как там в джанге сейчас. У нас есть даже
forked test runner для быстрых тестов в sqlite3 + memory на
многопроцессорных машинах. А вот для тестов mysql/postgresql изрядно
бесит то время которое требуется для создания всего что нужно в бд
перед каждым тестом. У нас это 0.5сек при более 100 таблицах.
Провоцирует на написание больших тестов, которые тестят весь блок
целиком, вместо горки маленьких.
Werkzeug.. были попытки. В чем то намного круче джанги, но надо всё
реализовать самому. SQLAlchemy по стабильности на мой взгляд
проигрывает джанге всё-таки.
Если я займусь новым проектом, то это явно будет свой фреймворк.
Обязательно нужно адекватные программные модули с точками входа/выхода
и прочей инфраструктурой. И независимые от имен модулей питона. Чтобы
можно было взять просто модуль скопировать в папку где модули и чтобы
все заработало сразу (к нему присобачились бы модули которые могут с
ним работать, а он соответственно к тем, с кем умеет). Модульность
должна быть абсолютной -- даже сам факт веб-приложения должен быть
модулем (типа поддержка модулей, которые могут рендерить страницы). В
таком случае может конечно получиться ещё одна жопа (Zope которая),
но, думаю, может и не получится. Основной упор делать на эффективность
получаемых приложений. Как касательно работы с бд так и всего
остального. В джанге кеш темплейтов появился-то совсем недавно только!
Сделать нормальный тестраннер, который блин сможет запускать тесты
которым не нужна бд параллельно и не создавая этой самой бд для них. В
базовой поставке - только ядро. Всё остальное - модули - хочешь качай,
хочешь не качай. Только так ядро может развиваться быстрее (ибо
например, есть v1 и потом делают ядро v2 и пофиг что GIS пока работает
только на v1. Как обновят - так заработает, но это не мешает релизу
самого ядра). Надо ПРОВОЦИРОВАТЬ людей писать эффективные программы.
Предупреждать автоматически если у тебя на странице 100 одинаковых
запросов оказывается, ну или близких по духу, которые можно зашвырнуть
в 1. Надо запрещать творить что попало в темплейтах ну или хотя бы не
советовать этого. Python язык не со строгой типизацией, но блин
использовать это во вред умеет по-моему уже каждый второй. Хотя бы
функции-универсалы do_it(something), когда something - хоть строка,
хоть массив, хоть яблоко, хоть тумбочка. Это круто для pprint. Но это
уродство для filter(field_value=).
Резюмируя скажу - джанга для корпоративных сайтов и мелких порталов.
Не более. Если захочется использовать её в большом проекте - то, так
же как и мы, перепишете половину ядра джанги под свои нужды =). И
постоянно будете зажаты в рамки, которые в общем-то нафиг не нужны.
--
Regards,
Vadim Fint aka MockSoul,
IPI Tech Team,
St.Petersburg, Ru.
2010/5/15 Stanislav Panasik <spana...@gmail.com>:
> Привет, Максим !
>> Я здесь не рассматриваю варианты быстрого "наколенного" написания
>> сайтиков в одиночку.
>> Хотя да, для этого Джанга со своим набором тулзов подходит хорошо,
>> потому и стала так популярна.
> Я тоже не рассматриваю такие варианты :-)
>>> Если говорить о сторонних плагинах, то их, как правило, просматривают
>>> сотни
>>> пар глаз, там и код и документация соотв. качества.
>>> Да, я считаю, что "своего" кода должно быть минимум.
>> С этим понятно, см выше.
>> Я просто стараюсь работать не над сайтиками-из-конструктора,
>> а над проектами, где приходится решать разные нестандартные задачи.
> Выше ничего нет.
> Нестандартные задачи, как правило, нестандартны только в какой-то маленькой
> частности, всё остальное должно реализовываться стандартными средствами.
> К тому же, как я понял, когда Вам нужна была очередь, Вы сами что-то
> написали, хотя были и другие варианты. Кстати, celery не рассматривали ?
> Очень толковая вещь, большое комьюнити, работает надёжно.
>> Пример про ПХП был в качестве иллюстрации
>> "легко найти кого-то, кто что-то понимает в этом".
> Ну, тут иллюстрация не получилась, потому что пхп настолько всеобъемлющ, что
> даже тот же parser - это тоже php, но вот разберётесь ли Вы в нём за 5 минут
> - кое-как и кое-в чём, я не то что сомневаюсь, а уверен, что нет. Хотя
> казалось бы, php. В общем-то, всё можно свести к двоичному коду, не так ведь
> ? :-)
> Я считаю, что тут мы не найдём общего языка, просто это разные школы,
> что-ли. Есть школа, которая говорит - вперёд, рой землю, и всё получится. А
> есть другая школа, которая говорит - подумай, перед тем, как делать, иногда
> 1 строчка на баше стоит 10 тысяч строк на С. Я стараюсь следовать принципам
> второй. Готов на эту тему дискутировать, но без голословных утверждений, что
> чей-то путь заведомо уныл.
>>> Просто если Вы используете фреймворк, значит
>>> это осознанный выбор, и надо держаться в формате его возможностей, либо
>>> расширять его функции согласно стандартам фреймворка.
>> Очень интересный вопрос - кому надо?
> Надо тому, кто выбрал фреймворк. Это очевидно.
>> И кто возьмется определять ту грань, когда следовать неким "стандартам
>> фреймворка"
>> становится нерентабельно?
> Ну, дорогой мой человек, тут Вы уже в высокие сферы нырнули.
> Нет человека, который не совершает ошибок, просто мы в силу своей природы
> таковы.
> Писали-писали, и тут оказалось, что выбрали не тот фреймворк. Бывает. Очень
> часто бывает. Есть два варианта дальнейшего развития событий:
> 1) порвать с фреймворком, писать свой, под задачу (параллельно как-то
> поддерживая рабочий код)
> 2) добавлять свою функциональность в фреймворк патчами. Не принимает в
> основную ветку сообщество - сидеть на своём форке до тех пор, пока
> заинтересованные люди, у которых аналогичные вашим проблемы, не доведут
> градус накала до принятия. Или просто сидеть на своём форке.
> Рентабельность тут определяется лёгкостью введения нового разработчика
> среднего класса продвинутости в дело. Сколько ему потребуется времени, чтобы
> вникнуть в вашу петрушку ? В случае, когда всё в рамках парадигмы
> фреймворка, любой разработчик, владеющий фреймворком, войдёт в дело
> достаточно быстро. Вот где проявляется эффективность подхода, которому
> следую я.
>> Я акцентирую внимание!
>> Имеется страница работающего кода (одна страница!), который делает
>> всё, что нужно.
>> Главный момент здесь вовсе не описание самого демона и протокола работы с
>> ним,
>> основное это как и для чего всё это используется в приложении.
>> В данном случае код - лучшая документация.
> Позволю себе не согласиться с Вами. Не в том, что код - плохая документация,
> нет, с этим я согласен, пожалуй, на 1100%.
> Несогласие в том, что мы же с вами не в вакууме работаем. У кого-то PIL под
> фрёй не собирается, у кого-то ещё что-то. Не бывает чистых вещей, всегда
> всплывают какие-то детали. И тут, сюрприз, как раз проявляется важность
> сообщества, которое юзает Ваш код и так и эдак, и у любого, кто взялся его
> юзать в своём проекте, неожиданно всплывает куча информации именно под его
> случай. Вот ведь в чём дело.
> Я считаю, что умный человек должен учитывать, что его мысль будут читать
> десятки глупых. Что разработчик, владеющий тонкостями платформы (в данном
> случае я имею в виду скорее Python), должен учитывать, что его код будут
> сопровождать люди, гораздо менее квалифицированные, чем он. Не больше, не
> меньше. Это моя мысль.
> Если вы (имеется в виду обращение к сообществу, а не к персоне, поэтому с
> маленькой буквы) настолько умны, что можете сделать всё - не делайте этого,
> сделайте то, что будет понятно большинству, не забывайте, что максимум
> кривой IQ располагается в районе 100 единиц, а не там где значение, которым
> вы гордитесь. Это полезнее для всего сообщества, а не только для утверждения
> ЧСВ.
> Надеюсь, я понятно изложил свою позицию. Вообще, что касается наших родных
> пенатов, скажу односложно - неконструктивно. Нет юзабилити в общении. Вот
> сами посмотрите и убедитесь -
> http://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%B9%D0%BB:IQ_curve.svg
> Это жизнь, друзья мои, а не теория про когерентность кешей в SMP системе.
> Рабочий код только тот, который понятен большинству, а на него отдельные
> члены нашего сообщества не ориентируются, увы (как я понял).
> =========================================================================== ====
> Оффтопик - предлагаю замутить конференцию django-russian-talks для
> разговоров на около-джанговые темы, типа флейма и т.п. Потому что засорять
> таким контентом основную конфу, имхо, нет смысла. А для подписчиков, которым
> интересны и флеймы, это будет весьма интересно.
> С уважением, Стас
