Что не так с "магией"?

Question

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

Для получения дополнительной информации прочитайте Закон утечки абстракций Джоэла Спольски

Answer 4

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

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

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

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

Answer 5

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

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

Shazam

Answer 6

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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