Преимущества и недостатки использования веб-платформы? [закрыто]

16

Этот вопрос направлен на выявление преимуществ и недостатков использования веб-платформ : таких как Cake PHP, Zend, jQuery, ASP.NET). Этот вопрос совершенно не зависит от языка . Позвольте мне начать с понятия «Стоять на плечах гигантов ».

Преимущества:

  • Позволяет разработчикам - взяв на себя функции, которые раньше занимали бы сотни строк кода, и сжимая их в один простой вызов функции, разработчики могут интегрировать более сложные функции в свои веб-сайты.
  • Разрешить более быструю разработку приложений - это очень актуально для людей, которым нужны сайты, созданные в очень маленьком окне (есть ли у кого-нибудь примеры этого?)
  • Низкие затраты - позволяет программистам перенести экономию средств на клиента - создан целый ряд новых клиентов, которым нужен веб-сайт, но ранее они не могли позволить себе более высокие затраты на разработку.

Недостатки:

  • Потерянное понимание - полагаясь на особенности фреймворка, разработчик рискует потерять понимание того, как все работает (под капотом).
  • Обрыв конфигурации - как только вы пойдете дальше, чем конфигурация вашей инфраструктуры, ваша производительность сразу упадет, может быть сложно реализовать функции вне конфигурации инфраструктуры.
  • Трамвайная линия разработчика - вы (разработчик) должны делать то, что разработчик хочет, чтобы вы делали.

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

JHarley1
источник

Ответы:

12

Вот суть: может быть сложно реализовать функции вне конфигурации фреймворка.

Давайте рассмотрим это предположение по предположению.

Потерянное понимание - полагаясь на особенности фреймворка, разработчик рискует потерять понимание того, как все работает (под капотом).

Ложь. Вы никогда не потеряете понимание того, как все работает. Рамки не волшебные. Это просто удобный код, который вам не нужно писать самому.

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

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

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

Это имеет очень мало смысла.

Первый. Сборка без фреймворка может превратить тривиальную работу в большую задачу программирования, которая включает в себя модульное тестирование, отладку, диагностику, управление конфигурацией и все другие бесполезные работы по переосмыслению вещей, которые есть в фреймворке. Как это "производительность"?

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

Трамвайная линия разработчика - вы (разработчик) должны делать то, что разработчик [фреймворка] хочет, чтобы вы делали.

Верный. И это часто хорошо. Делать вещи последовательным способом более ценно, чем делать их по своему усмотрению. Это может потребовать «обучения» и «понимания», но они имеют ценность.

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

Какая? Это не имеет ничего общего с рамками. Мошенничество - это мошенничество, независимо от используемых инструментов.

С. Лотт
источник
3
Я не согласен с вами относительно "Потерянного понимания". Если вы возьмете в качестве примера jQuery, вам просто нужно взглянуть на десятки вопросов о переполнении стека, где очевидно, что запрашивающий не может различить jQuery, JavaScript и DOM.
RoToRa
5
@RoToRa: Если вы посмотрите на какую-то конкретную тему о SO (например, программирование на C), вы увидите большое количество людей, которые не могут понять, что происходит. Действительно, некоторые люди даже не понимают, что такое число с плавающей точкой. Я не думаю, что это рамки. Я думаю, что есть люди, которые имеют ограниченные возможности для понимания технологии.
S.Lott
Скотт, действительно хорошие моменты, вы выдвинули на первый план ряд вопросов. Моя точка зрения была связана с фреймворками и мошенничеством, которые позволили быстро разработать профессионально выглядящий веб-сайт, но это было не по теме (хорошая мысль).
JHarley1
@ JHarley1: «но это было много миль от темы». Вы можете обновить вопрос, чтобы это исправить.
S.Lott
1
«Потерянное понимание» предполагает, что люди понимают, что происходит, когда они используют, например, простую Java. Но сама Java многое делает под капотом, и на самом деле вы не можете точно знать, что происходит на низком уровне, если вы точно не знаете, какая JVM на какой платформе будет использоваться; но не забота о таких деталях - одно из преимуществ таких языков, и то же самое можно сказать и о фреймворках.
user281377
3

Con: возможное падение поддержки / потеря популярности

  • Если есть две веб-фреймворки, которые в основном делают одно и то же, а ваша не выигрывает, есть шанс, что проект умрет. В этой ситуации вам остается самостоятельно поддерживать фреймворк (с открытым исходным кодом), переписать приложение или продолжить без обновлений (с закрытым исходным кодом).
  • В зависимости от платформы, вы можете быть вынуждены обновить свое приложение с графиком выпуска платформы. Слишком большое отставание может лишить вас права на поддержку. Без рамок вы можете работать по расписанию. (Это зависит от того, нужна ли вам поддержка или нет).

Pro: код для бизнеса

  • Фреймворки позволяют вам не беспокоиться о тяжелой работе и сосредоточиться на коде, который напрямую приносит пользу бизнесу.
  • Иногда обновления инфраструктуры, которые (просто работают), позволяют вам предоставлять новые функции вашим пользователям практически «бесплатно». Особенно с фреймворками, которые поставляются с пользовательскими элементами управления (например, сетка, которую новая версия может предложить для поиска / фильтрации).
Райан Хейс
источник
Приветствия Райан, здесь есть несколько хороших моментов. Я никогда не думал, что Фреймворк упал / упал из благодати.
JHarley1
Могу ли я получить отзыв о downvote, пожалуйста?
Райан Хейс
Я нашел это полезным - я проголосовал.
JHarley1
3

преимущества

  • Ускоренное время разработки
  • Меньше ошибок
  • Быстрая совместная разработка
  • Поддержка библиотеки
  • Простое взаимодействие с БД

Недостатки

  • "В штучной упаковке" в рамки
  • Часто негибки, когда хотят расширить или изменить поведение ядра
  • «Ошибки обреченности» - ошибки, которые возникают в ядре или в базовой архитектуре и не имеют обратной связи с местом их возникновения. Прекрасным примером являются ошибки Spring при использовании Grails.

Я выступаю за использование фреймворков для всех проектов, кроме самых простых. Если вам нужно добавить форму обратной связи к существующему сайту HTML, вы можете использовать один файл PHP вместо перехода на платформу.

Джош К
источник
2

Несколько вещей, которые приходят на ум ...

преимущества

  • Повторное использование кода - используя платформу, вы повторно используете проверенный и верный код.
  • Быстрое развитие / прототипирование.
  • (часто) встроенная проверка входных данных, которая может считаться безопасной (если разработчик использует ее правильно)

Недостатки

  • Потеря поддержки. Здесь на ум приходит Symfony 1.4. Я предполагаю, что Symfony будет поддерживать 1.4 в течение некоторого времени, но, зная, что 2.0 не имеет обратной совместимости, 1.4 в ближайшие годы кажется тупиком поддержки.
  • Накладные расходы; Используя платформу, вы запускаете тысячи строк, которые могут не относиться к вашему конкретному приложению, но могут применяться к другим. Некоторые считают это разумным компромиссом, а некоторые предпочитают писать свой код с нуля для повышения производительности.
  • Использование неправильной структуры для ваших конкретных потребностей. Не все рамки созданы одинаково.
Craige
источник
1

Все зависит от того, какую платформу вы используете.

Если вы используете ASP.NET, вы находитесь в невыгодном положении: это в лучшем случае дырявая абстракция , а в худшем затрудняет выполнение вещей, тривиальных в других средах, которые не скрывают, что вы работая в сети.

ASP.NET MVC стремится решить эту проблему, и это хорошо.

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

Джордж Стокер
источник
Вы видите, что моя проблема с ASP.NET MVC состояла в том, что мне пришлось отучиться от некоторых концепций и делать то, что было ASP.NET MVC, что заняло у меня время. Возможно, вы могли бы сказать, что недостатком фреймворка будет снижение производительности, пока вы с ним разбираетесь.
JHarley1
1

Я хотел бы добавить несколько пунктов.

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

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

Преимущества:

  • когда вы постоянно используете фреймворки, время обучения для проектов уменьшается для людей, которые уже работали над вашими проектами.
  • ваше собственное быстрое развитие
  • ваши собственные разработчики расширения возможностей
KeesDijk
источник
@Keedijk: я никогда не думал о лицензировании, есть ли примеры платных платформ?
JHarley1
@ JHarley1 oakleafsd.com Я не знаю, что бы я назвал это «веб-фреймворком», но у Mere Mortals .NET есть расширения, помогающие быстрее создавать веб-приложения. Однако сама платформа .NET Framework делает большую часть этой структуры устаревшей.
Райан Хейс
@JHarley Я, возможно, немного обобщил в своем ответе, но я думал о таких вещах, как telerik webcontrols или itext itextpdf.com/terms-of-use/index.php . Я также работал в компании, где изменение лицензий ExtJs было проблемой sencha.com/forum/showthread.php?33096-License-Change
KeesDijk
-2

Я говорю из личного опыта за последние 13 лет. В моей компании мы использовали распорки, после короткого поворота это было здорово. В моем следующем примере мы использовали архитектуру, которая была в основном непрозрачной, несколько похожей на структуру, но выросла, мы могли расширить ее, но основной код был только jars. И так далее. последние 3 года работали в небольшой компании (количество разработчиков <30) и это были все наши собственные jsps, servlets и ejbs. Если посмотреть на наших многочисленных клиентов и повторение jsps, в 2012 году был создан фильтр j2ee, который имитировал 20% стоек2. Почему бы не использовать Stuts 2? Хотелось бы, чтобы мы имели, но: не могли передать его нашему главному архитектору; недостаточно опыта или времени.

Итак, у нас были перехватчики некоторых распространенных jsps, которые использовала наша мини фреймворк. Теперь, когда у меня было время пройти через книгу о стойках 2, я вижу, что мы так много пропустили!

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

tgkprog
источник