Что случилось с "волшебством"?

Я пытаюсь решить, использовать ли Rails или гуру Django для создания веб-приложения для меня. Мне рекомендовали использовать Django, потому что он использует меньше "магии". С моей точки зрения, однако, "магия" Rails кажется хорошей, поскольку это может сделать разработку более кратким для моего подрядчика, что приведет к меньшему количеству оплачиваемых часов за мой счет. Я понимаю, что преимущество Django может быть более тонким контролем, но как я узнаю, нужен ли мне этот контроль? Есть ли неотъемлемая проблема с "магией"?

Ответ 1

Ну, рассмотрим пару бит Rails "magic": когда вы пишете класс контроллера, его методы имеют доступ к определенным переменным и некоторым другим классам. Но эти переменные и классы не были ни определены, ни импортированы ничем в файле кода Ruby, на который вы смотрите; Rails сделала много работы за кулисами, чтобы убедиться, что они просто будут там автоматически. И когда вы возвращаете что-то из метода контроллера, Rails гарантирует, что результат будет передан вместе с соответствующим шаблоном; вам не нужно писать какой-либо код, чтобы указать, какой шаблон использовать, где его найти и т.д. и т.д.

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

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

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

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

Оба эти, конечно, действительные позиции для принятия, и обычно кажется, что люди просто естественным образом тяготеют к тому или иному; те, кто любит "магию", собираются вокруг Rails или фреймворков, которые пытаются подражать ей, те, кто не собираются вокруг Django или фреймворки, которые пытаются подражать ей (и, в более широком смысле, эти позиции несколько стереотипны для Ruby и Python разработчики, разработчики Ruby, как правило, любят делать что-то в одном направлении, разработчики Python, как правило, любят делать что-то другим).

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

Ответ 2

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

Ответ 3

Магия велик, пока что-то не сломается. Затем вам нужно выяснить, как работают все эти трюки.

Подробнее читайте Джоэл Спольский Закон мертвых абстракций

Ответ 4

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

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

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

Выбор должен заключаться в том, кто среди подрядчиков, которых вы оцениваете, а) имеет проверенный послужной список и б) вы доверяете. Хороший разработчик преуспеет в Rails или Django.

Ответ 5

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

Ему нравится читать рассказ и оставлять автора в стороне от соответствующих поворотов сюжета, потому что они повторяются.

Shazam

Ответ 6

Проблема с "магией" заключается в том, что она скрывает от вас много чего, и IMO затрудняет поиск проблем или знает, что делать/оптимизировать, как только вы начинаете думать "вне коробки" и в конечном итоге "мертвая магическая зона" (т.е. часть, где магия вам не помогает).

IMO - это основная проблема с Ruby on Rails (и не поймите меня неправильно, я действительно, как Ruby on Rails); слишком легко начать с этого, а затем, когда вы столкнетесь с проблемой, когда Rails не выполняет эту работу за вас, или где соглашения Rails не подходят... вы довольно сильно ввернуты, re the Ruby guru, потому что вы больше не можете полагаться на магию и потому, что это отвлекло все от вас, вы не знаете, как это сделать "трудный путь"

Ответ 7

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

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

Ответ 8

Говоря о магии, я считаю, что Rails, Django и большинство, если не все фреймворки делают какую-то магию. То, как они абстрагируют вещи, завершают услуги низкого уровня в API, интегрируют маршруты и контроллеры и т.д., Являются волшебством для людей, которые мало что знают. Я признаю, что у Rails больше волшебства, и люди иногда могут потеряться. Однако из-за этого мы не должны исключать Rails. Как я уже сказал, это не значит, что магия очень плохая, и только Rails делает магию, большинство из них. Мы должны видеть, что Rails развивается очень быстро, и его качество кода улучшается, и оно становится все более модульным. Ресурсы вокруг Rails огромны. Это также следует учитывать.

Ответ 9

Как указывал Guoliang Cao, всегда есть какая-то "магия", на которую вы полагаетесь, начиная с "волшебной" операционной системы, принимая ваш ввод на клавиатуре и визуализируя ее на экране в нужном месте. Каждая веб-структура анализирует параметры, размещенные на веб-странице, и помещает их в структуру данных для легкого доступа. Rails гораздо более агрессивно относится к тому, что можно сделать магически, так как его создатель (с которым я склонен соглашаться) имеет очень сильные мнения о том, как разрабатывать веб-приложения. Таким образом, вопрос действительно должен быть "насколько магия" уместна, а не если есть проблема с ней.