30 July 2015, 1:21
tanner.of.kha
|
Решил всё же серьёзно написать. Я не согласен почти со всем, что есть в этом видео. :)
-
a) централизованный диспетчер запросов или декораторы в духе Flask − это вопрос вкуса. Мне тоже больше нравится urls.py-подход, но вполне могу понять тех, кому он не нравится.
б) мне самому тоже не хватает академического образования, чтобы использовать на всю катушку регекспы. Если честно, я вообще стараюсь их избегать. Но я не горжусь этим, и тем более не стал бы критиковать тех, кто их использует. Тем более, что вполне возможно обойтись несколькими типовыми, разжёванными в мануале примерами в диспетчере даже очень большого проекта.
в) «строки вместо функций» − это смешная претензия. Очевидно же, что функцию перед использованием нужно импортировать, это занимает время, а из всех функций в итоге будет вызвана только одна, так зачем импортировать их все? К тому же использование строк решает вопросы перекрёстного импорта. Неужели человек 9 лет пишет на Python и не понимает, что это проблема/особенность языка, а не фреймворка? А если понимает, то почему даже не намекнул на правильное с его точки зрения решение?
-
Да, говорят, Jinja2 быстрее джанговского шаблонизатора, но зато сложнее в освоении, и джинджу сложнее расширять, что бы там Олександр не говорил про непонятно откуда берущиеся теги в джанговских шаблонах. Но в конце концов, вопрос по большей части сводится к тому, насколько язык шаблонизатора должен быть похож на язык программирования. Если мы уделяем слишком много внимания доступу к структурам данных, вызовам функций, пространствам имён и т. п. в шаблонах, то мы, скорее всего, тащим в презентационный слой слишком много логики. Логику по идеологии MVC/MVP/MTV надо оставить во вьюхах.
-
Аргументация против Django ORM сводится, как обычно, к тому, что разработчик, не знакомый с SQL, может написать ужасные вещи. Причём я заметил, что Олександр часто говорит о том, какие ужасные вещи он видел в чужих проектах. Я думаю, нельзя ставить в вину фреймворку ужасный код, написанный на нём, если в то же время в Сети есть огромное количество хорошего кода, и разработчику ничего не стоило с ним познакомиться, прежде чем костылить и велосипедить. А задавать параметры через «точечку» или «__» − опять же вопрос вкуса.
-
Шелл-команды − это классы. Мне это тоже не очень нравится, это самый затасканный в Python антипаттерн, но это же не ужас.
-
CBW − это вообще глобальный OOP-misconception. Тут виноват не Django и не Python, а особого рода когнитивное искажение.
Кажется, что если достижение одного и того же результата способом A требует написания N строк кода, а способом B − 2N строк кода, то способ A в 2 раза проще способа B. Это интуитивное правило не работает в случае с CBW, как и во многих других случаях, когда много неочевидных вещей остаётся «под капотом». Но это не значит, что искать и применять способы, требующие написания меньшего количества кода − ерунда и не нужно.
Иными словами, процедурные вьюхи в Django − отличный способ сразу ухватить суть и начать кодить реальные приложения. При этом кодер копипастит из проекта в проект одни и те же вещи, вроде if request.method == 'POST'. Разработчики Django сказали: «Хватит копипасты! Даёшь новый уровень абстракции!» «Нет, я хочу ещё копипасты! Уберите CBW!» − говорит Олександр. На самом деле все они по-своему правы. Я, например, тоже продолжаю копипастить процедурный код. Если копипаста даёт понимание кода здесь и сейчас, я за копипасту. Но я также и за право других кодеров применять другие подходы, и в этом случае для понимания чужого кода очень здорово, что такие вещи, как CBW, придуманы и применяются mainline-разработчиками, а не сторонними. Иначе…
-
Мидлвари. Думаю, Олександру надо покурить PEP333 и PEP3333.
-
В Django HTML-формы являются database-aware. Это уже поднимает Django на недостижимую высоту над WTForms. То, что во Flask/WTForms/SQLAlchemy всё делается проще и меньшим количеством кода − это просто гон какой-то. На самом деле всё наоборот, я пробовал.
-
Что за странными проектами докладчик занимается? Задачи пользователя именно что на 90% сводятся к редактированию таблицы в БД. Да все CMS и CMF построены на этом! Flask-admin построен на этом. Для оставшихся 10% никто не мешает добавить в админку произвольную вьюху.
-
а) Если Олександру не нравятся императивные конфиги, они легко превращаются в декларативные. Импортировать в settings.py ConfigParser и скормить ему ini-файл, всего и делов-то! Другое дело, что императивные конфиги тем и хороши, что этим их возможности не ограничиваются. Использовать возможности или нет − дело кодера. Хуже было бы, если б этих возможностей не было.
б) если честно, не понял эту претензию с эксепшнами.
в) миграции − это в ту же кучу, что и императивный конфиг, и регекспы в урлах, и все прочие возможности, которые Олександр не использует, и ему не даёт покоя тот факт, что кто-то другой их использует. По мне, так инициализировать БД с помощью кода, да ещё и автогенерируемого − это отличная идея (я в курсе, что она не оригинальная). Не говоря уже о джанговских аппах как о самодостаточных и переносимых частях проекта.
Updated 30 July 2015, 1:25 by tanner.of.kha.
|
