Что не так с "магией"?
Я пытаюсь решить, использовать ли Rails или Django гуру для создания веб-приложения для меня. Мне рекомендовали использовать Django, потому что он использует меньше "магии". Однако, с моей точки зрения, "магия" Rails кажется хорошей вещью, поскольку она может сделать разработку более краткой для моего подрядчика, что приведет к меньшему количеству оплачиваемых часов за мой счет. Я понимаю, что преимущество Django может заключаться в большем детализированном контроле, но как я узнаю, нужен ли мне этот контроль? Есть ли врожденная проблема с "магией"?
9 ответов
Хорошо, рассмотрим пару кусочков Rails "волшебство": когда вы пишете класс контроллера, его методы имеют доступ к определенным переменным и некоторым другим классам. Но эти переменные и классы не были ни определены, ни импортированы ничем в файле кода Ruby, который вы просматриваете; Rails проделал большую работу за кулисами, чтобы гарантировать, что они просто будут там автоматически. И когда вы возвращаете что-то из метода контроллера, Rails удостоверяется, что результат передается в соответствующий шаблон; вам не нужно писать какой-либо код, чтобы сообщить ему, какой шаблон использовать, где его найти и т. д. и т. д.
Другими словами, как будто эти вещи происходят "магией"; вам не нужно поднимать палец, они просто случаются для вас.
Напротив, когда вы пишете представление Django, вы должны импортировать или определять все, что вы планируете использовать, и вы должны четко указать, какой шаблон использовать и какие значения должен иметь доступ к шаблону.
Разработчики Rails считают, что подобная "магия" - хорошая вещь, потому что она позволяет быстро получить что-то работающее, и не утомляет вас множеством деталей, если вы не хотите получить доступ и начать переопределять вещи.
Разработчики Django считают, что подобная "магия" - плохая вещь, потому что на самом деле не экономит столько времени (несколько import операторы не имеют большого значения в общей схеме вещей) и имеют эффект сокрытия того, что на самом деле происходит, усложняют работу по переопределению вещей или усложняют отладку, если что-то идет не так.
Обе эти позиции, разумеется, являются обоснованными, и в целом кажется, что люди просто естественно тяготеют к одному или другому; те, кто любит "магию", собираются вокруг Rails или фреймворков, которые пытаются подражать ему, те, кто не собирается вокруг Django или фреймворков, которые пытаются подражать ему (и, в более широком смысле, эти позиции несколько стереотипны для Ruby и Python разработчики; разработчики Ruby предпочитают делать что-то одно, разработчики Python любят делать что-то другое).
В конечном счете, это, вероятно, не имеет большого значения для фактора, который, как вы говорите, вас интересует, - оплачиваемых часов, - поэтому пусть ваш разработчик выберет то, с чем ему или ей больше всего удобно, так как это с большей вероятностью получит полезные результаты для вас.
Основная проблема возникает, когда вы не понимаете магию. Это может привести к чему угодно - от приложений, которые плохо кастрированы, до случайных, фатальных сбоев.
Магия велика, пока что-то не сломается. Затем вы должны выяснить, как работают все эти трюки.
Для получения дополнительной информации, прочитайте закон Джоэла Спольски о негерметичных абстракциях
Волшебство запутывает функциональность. Он создает поведение неявно, а не явно, так что программисту не нужно понимать, как работает поведение, и, что более важно, как они могут изменить его.
Когда кодер имеет полное представление о кодовой базе, с которой он работает, "магия" может значительно повысить производительность. Но при работе со сторонней системой, такой как веб-фреймворк, которая имеет высокую степень сложности, может потребоваться гораздо больше времени для получения такого уровня знаний.
Теперь, что касается того, кого вы должны нанять, чтобы выполнять работу: если вы беспокоитесь о долгосрочной способности других программистов понимать код ваших подрядчиков, возможно, имеет смысл использовать Django (это, безусловно, мое предпочтение). Тем не менее, существует множество экспертов Rails, которые могут поддерживать ваш сайт в будущем.
Выбор должен исходить из того, кого из подрядчиков вы оцениваете, а) иметь проверенный послужной список и б) вы доверяете. Хороший разработчик преуспеет на Rails или Django.
При использовании магии... для обеспечения понимания одной части системы вы должны понимать все целиком. Поскольку трудно определить, не влияет ли магия на предмет, который вы исследуете.
Это похоже на чтение истории и на то, чтобы автор не использовал соответствующие сюжетные повороты, потому что они повторяются.
Shazam
Проблема с "магией" заключается в том, что она скрывает от вас многое, и IMO усложняет отслеживание проблем или знает, что делать / оптимизировать, когда вы начинаете мыслить "нестандартно" и в конечном итоге становитесь "мертвым". Волшебная зона "(то есть часть, где магия вам не помогает).
IMO, это главная проблема с Ruby on Rails (и не поймите меня неправильно, мне действительно нравится Ruby on Rails); слишком легко начать работу с ним, а потом, как только вы столкнетесь с трудностями, когда Rails не сделает всю работу за вас, или когда соглашения Rails не подходят... вы в значительной степени облажались, если не " Вы гуру из Ruby, потому что вы больше не можете полагаться на магию, и потому что она абстрагировалась от вас, вы понятия не имеете, как сделать это "трудным путем"
Магия часто означает "использование встроенных допущений для оптимизации производительности или синтаксиса". Конечно, в хорошо документированном коде эти предположения упоминаются как явные ограничения.
Иногда магия прекрасна, так как она действительно сокращает объем написанного или резко повышает скорость. Но вы можете нарушать эти предположения бесчисленными способами и либо сталкиваться с неожиданными ошибками, либо, что еще хуже, иметь незаметные ошибки.
Как отметил Голианг Цао, всегда есть какая-то "магия", на которую вы полагаетесь, начиная с того, что операционная система "волшебным образом" берет ввод с клавиатуры и отображает его на экране в нужном месте. Каждый веб-фреймворк анализирует параметры, опубликованные на веб-странице, и помещает их в структуру данных для легкого доступа. Rails гораздо более агрессивен в отношении того, что можно сделать волшебным образом, поскольку его создатель (с которым я склонен согласиться) имеет очень твердые мнения о том, как следует разрабатывать веб-приложения. Таким образом, вопрос должен заключаться в том, "сколько магии" уместно, а не в том, есть ли в этом проблема.
Говоря о магии, я верю, что Rails, Django и большинство, если не все фреймворки делают какую-то магию. То, как они абстрагируют вещи, оборачивают низкоуровневые сервисы в API, интегрируют маршруты, контроллеры и т. Д., Являются своего рода волшебством для людей, которые мало что знают. Я признаю, что в Rails больше магии, и люди могут иногда заблудиться. Однако мы не должны увольнять Rails только из-за этого. Как я уже сказал, дело не в том, что магия очень плоха, и только Rails делает магию, большинство делает. Мы должны видеть, что Rails развивается очень быстро, его качество кода улучшается, и он становится все более модульным. Ресурсы вокруг Rails огромны. Это тоже нужно учитывать.