Вступление
Так как на Тостере мне доходчиво объяснили, что там не место для дискуссий, а тема для меня важна — прошу устроить небольшую, но очень спокойную дискуссию здесь. Очень хотел бы услышать ваше аргументированное мнение.
Сама мысль
Я полагаю, вы согласны с тем, что программирование имеет 2 смысла. Первый — мощный инструмент для решения сложных проблем(иногда простых), второй — творчество. Если с последним всё понятно — вы получаете удовольствие от процесса, придумывая оптимальный алгоритм или создавая что-то новое, то с первым не совсем.
Написание любого кода приводит к созданию какого либо продукта (хорошего или нет — не важно). Этот продукт и есть решение проблемы. Нужно распознать человека на фото/видео — задача, программа, которая делает это — продукт, код — инструмент. И ваша задача состоит в том, чтобы конечный продукт решал начальную проблему. Я не говорю о том, что нужно/можно писать говнокод и радоваться жизни — нет, так нельзя. Нужно помнить об оптимальности алгоритма и потребляемых ресурсах. Но погоня за идеальным кодом – не лучшая идея, на мой взгляд. Нужно всегда искать и останавливаться на той золотой середине, которая дает лучшее соотношение затраченных сил и оптимальности решения.
Раньше для разработки чего-либо человек учил язык и подходы к построению/созданию приложения. После этого он создавал продукт и переходил к следующей задаче. Если для решения новой задачи требовалась какая-либо часть прошлого продукта – брались исходники и допиливались до нужного состояния. При этом порог вхождения был ниже и выше, чем сейчас. Ниже для человека, который знает язык. Выше для человека, который не знает ничего.
Сейчас большинство разработчиков стремится поскорее выплюнуть готовый продукт и получить за это деньги, для чего и используются фреймворки. Человек может заучить набор определенных слов и просто копировать их, а на выходе получать более-менее готовый продукт. При этом совершенно не обязательно понимать и разбираться в происходящем. А если что-то пойдет не так, то вы потратите уйму времени на продирание сквозь весь код фреймворка, чтобы понять, что идет не так.
Проблема фреймворков, что они загоняют вас в рамки, лишая свободы и понимания. Библиотека давала вам готовую функцию/функции, написанную кем-то другим, которую вы могли использовать, как и где захотите. При этом при переходе из одного проекта в другой, с одного языка на другой, вы довольно легко могли заменить библиотеку аналогичной на данном языке и переучивать/менять структуру приложения не приходилось. Так как библиотека – это лишь обертка вокруг естественного, голого языка.
Фреймворк же сковывает вас, привязывая к себе. Каждый из них имеет собственную выстроенную логику работы, которую не всегда можно запросто уловить. И при переходе с одного языка на другой/из одной, команды в другую вам приходится зачастую тратить несколько дней, чтобы понять, как использовать новый фреймворк. И при переносе проекта, вам, по сути, приходится заново создавать весь свой продукт. Если бы вы использовали голый язык, то с такой проблемой столкнуться не пришлось бы. Язык он и есть язык и новому разработчику в команде не пришлось бы тратить столько времени на понимание фреймворка, он бы сразу смог работать.
Стоит вспомнить о набирающей в последнее время шутке про мощнейший и популярнейший фреймворк «vanilla.js».
Комментарии (96)
sferrka
29.04.2015 14:22+2Фреймворки — всего лишь новый слой абстракции, считайте их новыми языками программирования, вот и все. И да, у вас всегда остается возможность находиться на любом уровне абстракции. А каждый новый слой родит нам еще кучу новых веток.
Суть описываемой вами проблемы в другом — количество инструментов разработки в IT просто зашкаливает. Это и языки программирования, и утилиты, и фреймворки, и языки разметки, и шаблоны проектирования и т.д. и т.п. Да и собственно задачи все усложняются.
Так что, не воюйте с мельницами, энтропию можно остановить только в своем собственном мире/окружении.
nikitasius
29.04.2015 14:27+1И как, простите, доедать этот слоеный пирог тому, кому вы его оставите?
sferrka
29.04.2015 14:36Как мы уже его едим? Я вот звездочки на гитхабе считаю… А в будущем надеюсь на ИИ.
nikitasius
29.04.2015 15:17+1Я не знаю, поэтому и вас спрашиваю. Если у вас есть слой для… кхм, в виде
magic("Hello world"), то человеку не испорченному этой ерундой придется открывать документацию к фреймворку и смотреть что там заmagic, что там заappepie, что такоеeasyRequestBlablaи далее по аналогии.
Звездочки считать — это элементарная математика. Куда интереснее и сложнее — посмотреть кто их ставит.sferrka
29.04.2015 15:28+1то человеку не испорченному этой ерундой
Странно, зачем этому человеку вообще фреймворки, языки? Можно ведь управлять напряжением в электрических схемах напрямую?
Fesor
29.04.2015 16:07Неявная магия это всегда плохо при работе в команде. Это допустимо только когда на 100% уверены что вся команда вкурсе этой магии.
Fesor
29.04.2015 14:39Слоеные торты доедать удобно, по слоям. Один ест один слой, другой второй, третий — тот что между ними и связывает их вместе. Это не графские развалины где все в кучу.
nikitasius
29.04.2015 14:25-2Уже была статья про фреймворки.
Собственно выскажу свое мнение и здесь: в плане JS я не вижу ничего плохого в том, чтобы использовать фреймворки, ибо это JS.
А вот в плане других языков программирования — категорически против.
lair
29.04.2015 15:44+5Ну то есть вы против использования ASP.net MVC при разработке веб-приложений на C#?
nikitasius
29.04.2015 16:49-4Это мода такая?) Задавать вопросы оппоненту по темам, с которыми он не работает (в профиле отсуствует информация о C#)?
Сейчас я попробую вспомнить… лет 13 назад был (и есть) C и C++. Был борландовый AWL (awl?), и была косметика VCL.
Еще был microsoft… я помню громадный MFC и книжку, которой можно было убить.
Ответил ли я на ваш вопрос? Что вы хотелиуслышатьувидеть?lair
29.04.2015 16:51+2Вы же зачем-то говорите про другие языки программирования? Вот есть C# — язык программирования. Вот есть .net framework, в котором он работает. Вот есть asp.net mvc, который тоже фреймворк, только уровнем выше и с конкретной специализацией.
Вы категорически против использовать этот фреймворк при разработке? Или C# — не язык программирования? Или asp.net mvc — не фреймворк? Или что-то еще?nikitasius
29.04.2015 17:04-7Вот:
- Вышли они почти одновременно (C#'2000ые & .NET 2002 по вики)
- 2015 год — конечно стоит!
- 2005 год — чуть-чуть и 3 года!!! Зачем???
Сейчас что имеем? Имеет огромную «ВО!» которая работает с «ВОО!». За 13 лет обсосана и обросла гуще чем борода.
Мое категоричное мнение заключается в том, что громадных динозавров времен 2000х одели в модные костюмы, все это съели и на волне начала XXI века съели. А текущие фреймворки как приблуда к костюмам, мол напиши костюм-синий и все. Про подкладку и строчку — не парься. И ладно бы — они поражали деталями. Лет через 5 при должном развитии уже «ныть про это» будет не модно и неверно. Сейчас еще можно.lair
29.04.2015 17:12+1Я, вроде бы, задал конкретные вопросы. Использовать, или нет? К любому ответу сразу прилагается вопрос «почему».
nikitasius
29.04.2015 17:38-3Даже целых два. Но ответы так и не прочитали, внимательно.
lair
29.04.2015 17:44+1Вы, к сожалению, не ответили на мои вопросы.
nikitasius
29.04.2015 18:18Что же вы так невнимательно:
2015 год — конечно стоит!
lair
29.04.2015 19:04Ура!
Тогда следующий вопрос: как это сочетается с вашим же утверждением «А вот в плане других языков программирования — категорически против.»? C# — это не язык программирования? Перечисленное — не фреймворки? Ваше утверждение неверно?nikitasius
30.04.2015 11:01-1Читайте внимательно что я написал выше. Вам не хватает абстракции. Надеюсь до вас это дойдет :)
bromzh
29.04.2015 23:49А по теме Java работаете? Вот тогда вопрос про Java-фреймворки: отбросим всякие спринги, и чисто веб-фреймворки (play, spark и т.д.). Уберём JSF и другие фронтенд-фреймворки. Оставим только JavaEE API. Реализации некоторых его частей сами по-себе являются фреймворками: Jersey/Resteasy реализуют JAX-RS, Hibernate/EclipseLink/etc реализуют JPA и т.д.
Останутся по-сути, голые сервлеты. На них писать все веб-приложения?
grossws
30.04.2015 00:50веб-фреймворки (play, spark и т.д.)
WUT?! Он чуток побигдатее… Видимо, вы имели ввиду spring mvc.
Останутся по-сути, голые сервлеты.
Которые тоже, по сути, фреймворк, т. к. навязывает структуру программы и семантику обработки запросов. Без фреймворков — java.net.Socket.bromzh
30.04.2015 01:04Я про этот spark. А что с ним не так?
Которые тоже, по сути, фреймворк,
Да, точно. В принципе, на любом языке это сведётся к либо к работе с http протоколом напрямую, либо вообще к сокетам.grossws
30.04.2015 01:21Понятно, совпадение имени)) Я подумал про Apache Spark (ну и trademark Spark принадлежит ASF). Сказывается предметная область.
crmMaster
29.04.2015 14:26+2Если проект маленький, то фреймворк тащить нет никакого смысла, да.
Но стоит ему перевалить за пару тысяч строк кода, как начинает появляться фреймворк, самописный и часто кривой, зачастую похожий на существующие. Смысл терять время, нервы и деньги, если можно просто взять готовое.
Что касается подходов — большинство специализированных фреймворков в основе имеют принятые для решаемых задач подходы, большинство, но не все, а значит любители извращений так же не останутся в обиде.
Так что фреймворки это хорошо, а если вы упоротый и считаете необходимым вручную реализовывать простейшие вещи, то не надо тереть тут о программировании, ок?
alrusdi
29.04.2015 14:29-1По-моему в 95 процентах случаев хороший фрейворк закрывает все необходимые задачи.
Для остальных 5% имеет смысл описанное в статье. Большинство разработчиков с этими 5% никогда не столкнутся, так что фреймворки имеют право на жизнь.
AlexLeonov
29.04.2015 14:39Фреймворк, помимо всего вышеперечисленного, обязан решать еще одну задачу, о которой часто забывают.
Не допускать написания говнокода. Просто сделать это невозможным физически.
Почему Yii — плохой фреймворк, например? Потому что в шаблонах, написанных на нативном PHP ничто не мешает сделать 100500 запросов к БД в цикле.
Многие так и делают, к сожалению.
Или взять и результат работы контроллера Abc отрендерить в шаблоне Xyz. Счастливой отладки! (с)
Сумбурно, но основная мысль, надеюсь понятна. Фреймворк должен служить мощным ограничителем неразумных «хотелок» разработчика.Fesor
29.04.2015 14:48+1Сумбурно, но основная мысль, надеюсь понятна. Фреймворк должен служить мощным ограничителем неразумных «хотелок» разработчика.
Что бы отказываться от фреймворка нужно четко понимать зачем это делается и в чем менно вас ограничивают и почему. То есть начинающие разработчики обязательно должны быть в ежевых рукавицах фреймворка. А далее можно уже ограничения постепенно упразднять. Тут можно еще вставить про сюхари.
nikitasius
29.04.2015 15:33-5Не допускать написания говнокода. Просто сделать это невозможным физически.
Тогда как это делает фреймворк, написанный физически людьми?)
- Что мешает открыть и посмотреть как устроено, перенять себе?
- Что мешает использовать поиск в случае проблем с реализацией?
нативном PHP ничто не мешает сделать 100500 запросов к БД в цикле
А что мешает немного подумать самостоятельно и написать не 100500 запросов в цикле, а сколько конкретная функция требует?
Я очень надеюсь, что сайты вида «вопрос-ответ» и персональные блоги придушат таки интерес к фреймворкам в сторону чистого кода.
vayho
29.04.2015 15:38+2На самом деле можно писать на ассемблере, нафиг нам эти высокоуровневые языки, согласитесь, столько теряем используя их. А ведь можно подумать головой и написать чистый код на ассемблере.
nikitasius
29.04.2015 16:41-4Почва спора про JS фреймворки жиденькая, так как компилятором выступают движки в браузере и в ней вязнет мой аргумент про то, что фреймворки всего лишь фреймворки, без полноценного компилятора.
Зато ваше сравнение фреймворка и языка высокого уровня, как неба и земля. Фреймворк тут, внизу, как дрель замотанная скотчем, а ЯВУ они там, парят в небе. Вашей картинке не хватает пикселей.Fesor
29.04.2015 16:53+1… я ни слова не понял… как-то все смешано в кучу… браузеры… java… при том что и js и java выполняются в виртуальной машине, и там и там идет трансляция… хз…
nikitasius
29.04.2015 17:08-1- ЯВУ — языки высокого уровня, чтобы не писать три слова, пишу три буквы.
- JS исполняется на стороне браузера движком, встроенным в браузер
- Java исполняется в JRE.
Fesor
29.04.2015 17:12Java исполняется JRE, javaScript выполняется во всяких там спайдер манки, V8, etc. И то и то — JIT, виртуальная машина, оптимизирующие компиляторы…
Fesor
29.04.2015 17:11Тогда как это делает фреймворк, написанный физически людьми?)
Что мешает открыть и посмотреть как устроено, перенять себе?
Что мешает использовать поиск в случае проблем с реализацией?
Собственно то что вы написали это вполне себе нормально. Перенимать практики и т.д. Именно по этому начинающие разработчики должны использовать подобные вещи что бы не писать ужасные вещи самостоятельно и учиться на чем-то. А когда они уже начнут осозновать почему так а не иначе — тогда уже можно думать, оптимизировать инструменты под себя или использовать как учат старшие.
А что мешает немного подумать самостоятельно и написать не 100500 запросов в цикле, а сколько конкретная функция требует?
Клиенту глубоко плевать, что вы используете и какого качества у вас код, пока это не влияет на его прибыль или сроки деливери фич. Если качество кода начинает влиять на этот параметр то беда. А фреймворки нужны что бы разработчики не писали велосипедов для вещей, которые определенно понадобятся (логирование, управление зависимостями в коде и тд., базовый каркас) и вообще не занимать себя лишней работой а сосредоточиться на бизнес логике.
MichaelBorisov
29.04.2015 14:40+5В технике уже давно существует тенденция перехода на все более сложные «стройматериалы».
Если раньше электронщики проектировали свои схемы с использованием дискретных элементов (резисторов, конденсаторов, транзисторов) — то уже в 60-70гг прошлого века основным «строительным кубиком» стала микросхема. Она тоже несколько сужает свободу разработчика, так как содержит фиксированный набор функций, который не всегда идеально приспособлен для конкретных задач. Но зато ее использование значительно проще, а еще она занимает меньше места и потребляет меньше электричества.
В дальнейшем микросхемы усложнялись, и сейчас мало того, что без микросхем вообще почти ничего интересного сделать нельзя, так еще и количество функций, которые они вбирают в себя, возрасло многократно. Скажем, если вам требуется АЦП — то правильный на сегодняшний день способ его реализовать — это поставить микросхему-АЦП или даже микроконтроллер со встроенным АЦП. При этом вам не нужно вникать в детали того, как этот АЦП реализован, а просто подключить его так, как указано в инструкции. Раньше же микросхемы АЦП были малочисленны и дороги, поэтому во многих проектах имелись «самодельные» АЦП. Но сама функция-то остается той же самой. Какая разница, сделаете вы АЦП сами или поставите готовый — АЦП как правило не является самоцелью, а служит реализации другой цели, ради которой проектируется прибор. И время, сэкономленное на разработке АЦП, можно направить на разработку других, уникальных функций всего прибора.
То же и в программировании. До сих пор сохраняется возможность работать на «голом железе» без ОС. Но этим сегодня занимаются разве только разработчики ОС или других узкоспециализированных программ. Большинство же программ работают на готовой ОС и пользуются ее ресурсами как «кирпичами». Фреймворк — это просто еще одно усложнение «деталей», с которыми работает программист. Если ему не нравятся готовые детали — он может разработать свои. Но с готовыми деталями, как правило, можно быстрее собрать продукт с нужными функциями.
Негативный побочный эффект усложнения «деталей» — это необходимость изучать их, что при большом разнообразии таких деталей является трудной задачей. Если раньше достаточно было понять, как работает резистор, конденсатор и транзистор, то сегодня электронщик должен знать, какие бывают микросхемы, что они делают и как ими пользоваться — и это сотни и тысячи наименований. Но что делать, прогресс идет вперед.
Suvitruf
29.04.2015 14:44Вообще, it depends. Если проект небольшой, то фреймворк может нет смысла тащить. Если уж сабж про JS… То для какой-нибудь landing page может и не стоит тянут громоздские фреймворки. С другой стороны, писать на чистом JS… скажем так, малоприятно.
Если же область пошире взять, то, безусловно, от языка и специфики зависит. Да, поначалу они могут быть непонятны. Да, это дополнительные слои абстракции. Но в целом я за фрейморки, ибо они очень сильно упрощают рутинные вещи, тем самым ускоряя разработку, как минимум. Если же говорить про тот же jQuery, то он довольно прост (конечно, если не заглядывать внутрь).
NeoCode
29.04.2015 14:52-3Думаю, проблема в том что их слишком много:)
В С++ как таковых «фреймворков» сравнительно мало — boost, qt, mfc (ну можно вспомнить еще gtk, wxwidgets и vcl из builder'а). Мне, как программисту С++, хочется иногда изучить javascript — язык весьма красивый и интересный, но если изучать — то делать что-то практическое… Но вот беда, все эти фрейморки которые чуть ли не каждый день появляются… напрочь отбивают желание что-либо изучать:)
Zenitchik
29.04.2015 15:00+1Изучать надо «ванильный» JavaScript, и уже следом — изучать фреймворки.
Для чего-то практического — потребность во фреймворках зависит от сложности проекта и характере его работы. А то, бывает, подключают jQuery, чтобы один раз canvas по id найти…
michael_vostrikov
29.04.2015 15:10+12Дайте угадаю, автор недавно закончил универ и практически не писал достаточно больших приложений?) Просто у меня пару раз тоже такие мысли возникали. Давно когда-то…
(достаточно больших — это хотя бы несколько разработчиков и несколько десятков тысяч строк кода)
vayho
29.04.2015 15:17Какой профит мне писать что то самому если уже есть то что написано и работает скорее всего лучше того поделия что я умудрюсь написать?
Если работать над этим каждый день и ставить своей целью написать фреймворк то да там можно поработать, но если цель сделать продукт в установленные сроки то сори, я выберу фреймворк.
iiShrimp
29.04.2015 15:19+2Если бы вы использовали голый язык, то с такой проблемой столкнуться не пришлось бы. Язык он и есть язык и новому разработчику в команде не пришлось бы тратить столько времени на понимание фреймворка, он бы сразу смог работать.
Судя по личному опыту — это утопия которой к сожалению никогда не быть даже при использовании таких догматичных фреймворков как рельсы или эмбер. Погружение в обширные проекты занимает от 2-3 месяцев до года.
А еще меня поражает истерика которая в последнее время возникает около фреймворков. Вот допустим вы с другом решили написать абстрактный код. И договорились что файлы с кодом, название которых начинается на «А» вы сложите в одну папку, а файлы название которых начинается на «Б» вы сложите в другую папку. И сами того не ведая вы только что создали новый фреймворк! Пусть у него нет имени, красивого сайта и документации, но это уже фреймворк. Вы испортили вашу разработку? Думаю что нет.
vlreshet
29.04.2015 15:28Фреймворки созданы чтобы не писать по 100 раз рутину, сосредоточившись на бизнес-логике. Зачем писать каждый раз заново роутинг, подключение к базе, функции для работы с базой если можно написать это один раз очень хорошо и потом юзать и юзать? Другое дело когда фреймворк старается подмять под себя не только рутину но и какую-то логику, в таких местах я согласен с автором.
Reposlav
29.04.2015 18:49+1Если бы вы использовали голый язык, то с такой проблемой столкнуться не пришлось бы. Язык он и есть язык и новому разработчику в команде не пришлось бы тратить столько времени на понимание фреймворка, он бы сразу смог работать.
Только вот в любом сколько-нибудь сложном проекте всегда будет какая-то структура, классы, интерфейсы, функции, и пришлось бы тратить время на понимание всего этого, скорее всего без толковой документации. А фреймворки мало того, что имеют документацию, так еще обычно и довольно хорошо спроектированы, имеют большой функционал, и вероятность того, что попадешь в команду, использующую изученный тобой фреймворк, не так уж и мала.
Throwable
30.04.2015 11:37Многие путают фреймворк и библиотеку. Это принципиально разные вещи. Отличие состоит в том, что библиотека расширяет возможности языка, тогда как фреймворк наоборот, ограничивает возможности написания кода установленными парадигмами.
Как правило фреймворк не имеет технической возможности не дать пользователю использовать «некорректные» для этого фреймворка конструкции. Поэтому фреймворк устанавливает ряд соглашений или спецификаций: типа так можно делать, а так нельзя. Спецификации всегда неполны и оставляют за кадром львиную долю неясностей и неопределенностей. Поэтому поведение большинства фреймворков описательно недетерминированно: в отличие от языка программирования, пользуясь только спецификацией, нельзя определить конечное поведение программы. Чтобы что-то написать, приходится изучать все тонкости внутренней имплементации фреймворка.
Каждый фреймворк предлагает набор шаблонов как «правильно» будет сделать ту или иную задачу. Типичные задачи решаются просто при помощи «магии»: декларативных конструкций фреймворка. Если фреймворк где-то не покрывает требуемый функционал, то найти обходное решение будет весьма сложным делом. Я видел проект, где функционал на 50% состоит из всевозможных подпорок и work-around-ов.
Фреймворки очень плохо интегрируются друг с другом, если эта интеграция не предусмотрена функционалом. В отличие от библиотек, каждая из которых ориентирована на конкретную задачу, и которые без проблем могут использоваться вместе в одном проекте, фреймворки вынуждены пухнуть и вмещать в себя сразу весь требуемый функционал.Idot
03.05.2015 10:46-2>Фреймворки очень плохо интегрируются друг с другом, если эта интеграция не предусмотрена функционалом…
Это и есть главный минус фреймворков.Fesor
03.05.2015 12:26Ну на самом деле эта ситуация сейчас потихоньку начинает исправляться. Angular2 вот вроде будет все же пачкой компонентов. Вообще идея фреймворка как набора библлиотек сдобренного бойлерплейтом для связывания всего этого вместе — не такая уж и плохая идея.
Throwable
04.05.2015 12:03+1Не согласен. Это скорей не цель, а вынужденная необходимость. Из мира Java есть хороший пример — Spring. Тоже начинался как простенький IoC + MVC и очень быстро опух до неудобоваримого состояния. Для интеграции фреймворк определяет рудиментарные прослойки, которые сильно ограничивают и усложняют использование. То есть надо знать и саму низлежашую технологию, и прослойку, и как ее обойти при необходимости. Плюс, следуя сомнительной идее как можно больше бойлерплейта замести «под ковер», фреймворк определяет кучу неявных преобразований, умолчаний и деклараций: у фреймворка появляется магия и заклинания для вызова демонов. Очень быстро начинаешь понимать, что фреймворк концентрирует на себе, а не на решаемой задаче: решение из понятного «просто решить задачу» превращается в сложную и неопределенную «решить задачу с помощью фреймворка». Такое впечатление, что единственный оптимизируемый ресурс — это строки кода, которые сделаны из золота.
P.S. апофеоз «рамочной» инженерной мысли: Spring Batch с документацией в 250 страниц о том как написать скрипт для загрузки файла в базу данных.sferrka
04.05.2015 16:22«просто решить задачу» превращается в сложную и неопределенную «решить задачу с помощью фреймворка»
Нет никакого «просто решить задачу», в этом вся проблема. Без контекста — задача не существует. Решить задачу:
1. С помощью x86/x64 (а скорее под обе).
2. С помощью языка программирования, вот этого вот компилятора.
3. На этой ОС
4. В этом браузере (или под каждый).
5. Вот с этой по эту версию Android.
Просто языки программирования и нюансы ОС многие уже выучили, теперь пора учить языки фреймворков.
P.S. Полное описание загрузки файлов (да еще и в базу данных) на любом языке займет более 250 страниц.Idot
04.05.2015 18:24>описание загрузки файлов (да еще и в базу данных) на любом языке займет более 250 страниц
Это ещё с чего? На Delphi — это пара кликов, легко и просто!
fogone
05.05.2015 12:05+2Надо признать, что некоторые решения спринга сложноваты, но по факту выходит, что смотришь на спринг и думаешь: ишчиво наворотили, кому это надо? Начинаешь свой велосипед пилить, и сам себя хвалишь, вот ведь я хитрец, всех переиграл, сейчас простенькое решение накидаю, без всех этих абстракций — только то, что мне нужно, а через какое-то время смотришь, а ты делаешь тоже самое, что уже в спринге написано, только там уже решены многие проблемы, с которыми ты сталкивался и часто довольно неплохо. И это я не говорю о бесспорно крутых продуктах вроде IoC.
Throwable
06.05.2015 11:09Плохо, что Spring стал своего рода стандартом де-факто. Его лепят везде, даже не задумываясь о целесообразности. В большинстве проектов, которые я видел, Spring рудиментарен и проще и лучше было бы обойтись без него, чем с ним, заменяя легковесными библиотеками с целевым функционалом. Велосипеды легче вести, контролировать и кастомизировать. Они всегда более предсказуемые и легко отлаживаемое. Сколько раз приходилось биться в истерике, когда логически вроде бы все должно работать, но фреймворк либо кидает несколько страниц страшного эксепшна, либо еще хуже — просто игнорирует написаное или работает не как ожидалось? Это бич всех фреймворщиков.
Насчет неплохого решения с архитектурной точки зрения я мог бы долго спорить. Тут и проблемы изначальной заточки только под разработку веб через MVC, и сомнительность самой парадигмы IoC, и куча совершенно ненужных прослоек, типа Spring Data, и тупо неудобство многих вещей, etc…fogone
06.05.2015 16:22+1Плохо, что Spring стал своего рода стандартом де-факто. Его лепят везде, даже не задумываясь о целесообразности.
Действительно плохо, если люди не думают, когда выбирают средства для разработки.
В большинстве проектов, которые я видел, Spring рудиментарен и проще и лучше было бы обойтись без него, чем с ним, заменяя легковесными библиотеками с целевым функционалом.
Просто интересно, какие именно части спринга вы имеете ввиду и о каких легковесных библиотеках вы говорите? Каким таким критериям они удовлетворяют, что делает их легковесными и отличает от спринга?
Велосипеды легче вести, контролировать и кастомизировать. Сколько раз приходилось биться в истерике, когда логически вроде бы все должно работать, но фреймворк либо кидает несколько страниц страшного эксепшна, либо еще хуже — просто игнорирует написаное или работает не как ожидалось? Это бич всех фреймворщиков
В целом, с этим я соглашусь, но эта сентенция скорее верна для случаев, когда нужно специфичное решение и фреймворк не достаточно хорошо расширяется. Если же от фреймворка требуется типичное применение или он достаточно хорошо конфигурируется как спринговый ioc (например), то для меня в общем случае проще использовать его для решения моей задачи, чем писать своё решение или не использовать инструмента вообще.
Насчет неплохого решения с архитектурной точки зрения я мог бы долго спорить. Тут и проблемы изначальной заточки только под разработку веб через MVC, и сомнительность самой парадигмы IoC, и куча совершенно ненужных прослоек, типа Spring Data, и тупо неудобство многих вещей, etc…
Не совсем понял, что означает «заточка веб тольк очерез mvc» — если вы о web-mvc-фреймворке, то он на то и mvc-фреймворк, чтобы быть завязанным на mvc. Но и в остальном — о чем тут спорить? Во-первых, вам никто не навязывает то или иное решение от спринга, он достаточно модульный, чтобы не заставлять использовать все свои решения и даже общую схему приложения не навязывает. Во-вторых, я уже говорил, что некоторые их продукты сложноваты, но это не значит, что они не эффективны для решения тех задач для которых создавались.
Ну и конечно использовать IoC или нет — это вопрос вкусовщины и в целом восприятия архитектуры, о котором бессмысленно спорить.Throwable
07.05.2015 11:59> Просто интересно, какие именно части спринга вы имеете ввиду
Как я уже сказал, IoC — с точки зрения архитектуры концепт достаточно сомнительный. Организация архитектуры более традиционными способами имеет преимущества. Если все же нужен IoC, возьмите Guice — это мелкий IoC контейнер с отличной конфигурацией через DSL. Затем, в реальном проекте очень быстро понимаешь, что и в нем нет необходимости: связать пару бинов можно и ручками.
Затем идет пресловутый Spring MVC. Благодаря Struts и куче выросших на нем кодописунов, он быстро проник в массы и стал стандартом де-факто. Идея была понятна, но совершенно непроработана. В итоге, использование MVC на порядки усложнило разработку. Кроме того, MVC легко позволяет делать плохо, что в неумелых руках ведет к полной дезорганизации. Могу сказать, что в 90% сайтов хватит Servlet + JSP + JSTL, про которые все как-то очень быстро забыли.
Для справки, Apache Tapestry — гораздо более проработанный и организованный фреймворк, нежели Spring MVC.
Spring Data — совершенно рудиментарен. Запросы к базе данных в реальном приложении — это нечто более, чем найти объект в таблице по полям. Repository-per-entity — совершенно глупый концепт, который заставляет пользователя делать JOIN вручную, увеличивая в N раз число запросов к БД.
Spring Hateoas — искусственный концепт экспортировать Spring Data через Rest. Те же проблемы, только еще с участием HTTP.
Т.о. большинство концептов Spring-а искусственны и годны только в теории и для демок.
> Не совсем понял, что означает «заточка веб тольк очерез mvc»
Я об IoC и его scopes. В spring определен request scope, который сохраняет состояние объектов во время запроса. Однако его использование ограничено исключительно MVC контейнером. Когда запросы приходят, например, через JMS или RMI, придется разрабатывать и интегрировать свой scope. Сделать абстрактный request scope для всех endpoint-ов разработчики не догадались. Кроме того, MVC включено в Core Spring Framework, а не существует как отдельный проект, что вместе с другими технологиями делает понятным целевое использование фреймворка.
Вообще согласен, спорить особо не о чем. Spring предлагает большой инструментарий для разработки и интеграции. При хорошем владении и умелом использовании можно достичь хорошего качества продукта.lair
07.05.2015 12:07+2Как я уже сказал, IoC — с точки зрения архитектуры концепт достаточно сомнительный.
Что именно вы находите в нем сомнительного?
fogone
07.05.2015 14:28+2Как я уже сказал, IoC — с точки зрения архитектуры концепт достаточно сомнительный. Организация архитектуры более традиционными способами имеет преимущества.
Если выбираешь IoC осознанно и принимаешь нюансы его использования, то это очень мощное архитектурное решение. Конечно не лишенное проблем, но дающее большУю гибкость, инкапсуляцию и простоту использования.
Если все же нужен IoC, возьмите Guice — это мелкий IoC контейнер с отличной конфигурацией через DSL.
Не очень понимаю, по каким криетриям он «мелкий»? По быстродействию? По потребленю памяти? По размеру jar-ника? Абсолютно ничего не имею против Guice, просто не вижу причин для любой задачи предпочитать его спрингу. У спринга, к слову, тоже есть отличные джава-конфиги аля-дсл.
Затем, в реальном проекте очень быстро понимаешь, что и в нем нет необходимости: связать пару бинов можно и ручками.
Думаю, в проекте на пару бинов, можно и без IoC обойтись, согласен.
Затем идет пресловутый Spring MVC. Благодаря Struts и куче выросших на нем кодописунов, он быстро проник в массы и стал стандартом де-факто. Идея была понятна, но совершенно непроработана.
Да, у второго struts-а было очень много проблем, но он резко улучшал структуру, упрощал рутинные операции и был достаточно гибок, чтобы не сильно стеснять за что ему огромное спасибо.
В итоге, использование MVC на порядки усложнило разработку.
Кому именно он её усложнил? Именно вам стало хуже? Лично я был очень рад его использовать — в то время это было очень достойное решение акутальных проблем. Из ваших слов можно сделать вывод, что mvc как подход в разработке под web усложнил разработку, что выглядит очень сомнительным заявлением.
Кроме того, MVC легко позволяет делать плохо, что в неумелых руках ведет к полной дезорганизации. Могу сказать, что в 90% сайтов хватит Servlet + JSP + JSTL, про которые все как-то очень быстро забыли.
Видимо, вы никогда не видели как «плохо» можно сделать используя Servlet + JSP + JSTL. В свою очередь, spring web-mvc дает неплохую струтуру для проектов, что на мой взгляд делает проекты на нем в среднем чуть лучше, чем стандртный стек.
Для справки, Apache Tapestry — гораздо более проработанный и организованный фреймворк, нежели Spring MVC.
Тапестри это компонентный фреймворк и было бы глупо сравнивать spring web-mvc с ним, подходы совершенно разные. Если смотреть на классические mvc фреймворки для веба, то на мой взгляд у спринга одно из лучших решений. И да, тапестри очень достойное решение, но так же как и любой другой большой фреймворк имеет массу подводных камней и узких мест. Что в очередьной раз подтверждает тезис, что каждой задаче свой инструмент.
Spring Data — совершенно рудиментарен. Запросы к базе данных в реальном приложении — это нечто более, чем найти объект в таблице по полям. Repository-per-entity — совершенно глупый концепт, который заставляет пользователя делать JOIN вручную, увеличивая в N раз число запросов к БД.
Джоины руками, серьезно!? Вас же никто не заставляет все запросы делать исключительно декларативно. Наверное вы имеете ввиду spring data jpa, котоый по большому счету набор инструментов для работы с jpa-провайдерами вроде hibernate. Orm это вообще холиварный вопрос и явно не для этой статьи.
Spring Hateoas — искусственный концепт экспортировать Spring Data через Rest. Те же проблемы, только еще с участием HTTP.
Hateoas — никак со spring data не связан, не понимаю, откуда вы вообще информацию берете? Придумываете?
Т.о. большинство концептов Spring-а искусственны и годны только в теории и для демок.
С любым инструментом нужно учиться работать, исследовать возможности. Пока не умеешь, любой даже самый хороший инструмент будет искусственным концептом.
Я об IoC и его scopes. В spring определен request scope, который сохраняет состояние объектов во время запроса. Однако его использование ограничено исключительно MVC контейнером. Когда запросы приходят, например, через JMS или RMI, придется разрабатывать и интегрировать свой scope. Сделать абстрактный request scope для всех endpoint-ов разработчики не догадались.
Не очень понимаю претензий, если фреймворк из коробки чего-то не умеет — совсем не значит, что это плохой инструмент, тем более, что создатели предумсотрели возможность для расширения в этом месте.
Кроме того, MVC включено в Core Spring Framework, а не существует как отдельный проект, что вместе с другими технологиями делает понятным целевое использование фреймворка.
web-mvc заявлен как часть фреймворка, но не является его обязательной частью.
Idot
03.05.2015 12:20-1Фреймоворки нужно сравнивать с библиотеками — какие сравнительные достоинства и недостатки. Кто-нибудь может быстренько накидать сравнительную таблицу?
Fesor
03.05.2015 12:27+1Фреймворки нельзя сравнить с библиотеками. Как правилоа разница проста — фреймворк, как обязывает название, предоставляет структуру. А библиотека подобное предоставляет только в очень узком контексте, например структура слоя представления данных.
XlebNick
30.04.2015 13:02Я считаю, что для каждого конкретного проекта нужно смотреть отдельно. Да, фреймворки отчасти спутывают руки, но если они помогают достичь цели, пусть и со связанными руками, то тут следует подумать, что для данного проекта приоритетнее: удобство разработки + единообразие мышления членов команды(пусть и навязанное фреймворком), или же сложности разработки функций, не предусмотренных фреймворком, заставляют писать «через» фреймворк, и тогда уже будет легче обойтись без фреймворка/написать свой. Поправьте, если ошибаюсь.
fogone
02.05.2015 11:36+1Размер проекта по моему ощущению прямо пропорционален количеству использованных фреймворков. Не использовать же фреймворки вообще — это утопия, ведь любая абстракция дающая нам какую-то структуру для разработки это уже фреймворк.
dcc0
03.05.2015 07:43Версии PHP, версии Mysql. Вы сейчас начнете спорить… Я сразу отвечу, я смотрю на примеры из жизни. Тут кто-нибудь помнит, что такое php-nuke?
Или недавний пример с форума, человек пришел с проблемой, нашел Free-cms на хостинге не работает — ошибок лезет куча, cms-ке три года…
При этом, чем сложнее система и навороченнее, тем больше вероятности, что после забрасывания проекта (а это 90% процентов случаев) — система через 3 года полетит в помойку… А как жаль, там же ООП, гениальные реализации, добрая сотня классов.sferrka
03.05.2015 07:48Конечно начну спорить, ведь никто не просит их обновлять. А то, что хостинг самовольно меняет версию ПО никак не связано с тремя годами или PHP или ООП. И никуда не летит) Да и если говорить про PHP, что из обратной совместимости, кроме ereg (и еще парочки редчайще используемых возможностей) вообще могло вызвать ошибки?
Fesor
03.05.2015 11:47Версии PHP, версии Mysql.
А еще есть версии Python, версии Ruby, Java… Все меняется и это довольно нормальное течение вещей.
Тут кто-нибудь помнит, что такое php-nuke?
В последний раз я видел оный лет так 9 назад. И больше не хочу видеть.
Или недавний пример с форума, человек пришел с проблемой, нашел Free-cms на хостинге не работает — ошибок лезет куча, cms-ке три года…
Так может проблема в том что разработчики CMS забили на ее разработку?
что после забрасывания проекта (а это 90% процентов случаев) — система через 3 года полетит в помойку…
Вы же понимаете что для чего-то серьезного брать инструмент с высокой вероятностью того, что ее забросят, это как минимум глупо.
А как жаль, там же ООП, гениальные реализации, добрая сотня классов.
Для вас ООП и гениальность как-то коррелируется с количеством классов?dcc0
03.05.2015 18:30Для меня коррелируются силы и время, потраченные на разработку 100 мегабайтного пакета, который решает одну задачу — Интернет-Магазин. И все ради призрачной масштабируемости и еще более иллюзорного удобства пользователя — нажал и загрузилось, аж без перезагрузки страницы и не слева, и не справа, а на плывом из глубины монитора :) с рюшечками и шашечками… + целый мегаадптер с 10 классами, который решает одну задачу — установку cms с помощью нажатия next, но при этом пользователь (бизнес-пользователь) даже для этого дела приглашает специалиста.
Я бы не стал относить ООП к фундаментальным аспектам общей информатики. Это надстройка, она ее была, ею и останется. Согласитесь, есть большая разница между проектированием автомобиля и гаражным тюнингом.
dcc0
03.05.2015 07:57Там с 4 по 5 изменений довольно много, думаю, что zend за этот коротки период — 7-10 лет (а это очень короткий период) сильно переработана. И все будто бы имеет обратную совместимость, но то тут, то там всплывают приятные неожиданности.
Фреймворки портят разработку
Почти точно сформулировано. Только фреймворки портят, скорее, разработчика. Точно так же как упор на структуры данных, ООП, функционал, уводят от разработки фендаментальных вещей…Fesor
03.05.2015 11:53за этот коротки период — 7-10 лет
ничего себе короткий период. Даже по меркам жизни человека это не такой уж и короткий период, не говоря уж о индустркии, которой от силы лет 40.
И все будто бы имеет обратную совместимость, но то тут, то там всплывают приятные неожиданности.
Вы вообще-то говорите о PHP, который имеет свои особенность в плане развистия. Обычно языки проектируют, а с PHP вышел стихийный взрыв. Только начиная с 5-ой версии что-то начали менять и воспринимать язык серьезно можно только с версии 5.3.
Только фреймворки портят, скорее, разработчика.
Проблема не в технологиях а в головах. Я уверен что если что угодно дать новичку и оставить его с этой новой штукой на годи, он наваяет тонны неподдерживаемых решений.
Точно так же как упор на структуры данных, ООП, функционал, уводят от разработки фендаментальных вещей…
Не могли бы поделиться? Ибо то что вы перечислили для меня является фундаментальными вещами, которые помогают решать задачи бизнеса эффективнее, а ведь это главная цель программистов. make the client happy.
mukizu
03.05.2015 12:01+4Автомобили вредят здоровью! Раньше пешком все ходили и здоровыми были, а теперь разъездились все!
Idot
03.05.2015 12:08Не аргумент — а демагогия.
Fesor
03.05.2015 12:31+1ну так и сам пост это демагогия. Чего уж там. Скорость разработки никто не отменял. И если с фреймворками скорость падает — это конечно же повод задуматься. А если увеличивается и остается линейной — то почему бы и да? Все остальное это дело вкуса и личное мнение людей, на которое в общем-то всем плевать.
mukizu
03.05.2015 14:20Демагогия в основном в тексте поста. Разработку портят не инструменты, а неумение ими обращаться, или использование не к месту и далее по списку.
gatoazul
03.05.2015 12:15Таки да — вредят здоровью. Пойдите на природу, куда народ съехался на шашлыки, разделся и загорает. И поглядите, сколько среди автовладельцев толстяков — практически поголовно.
Fesor
03.05.2015 12:28А сколько толстяков среди пешеходов? Мне кажется столько же в процентом соотношении.
mukizu
03.05.2015 14:14Таки нет, здоровью вредит такой образ жизни. Человек может сколько угодно пользоваться автомобилем, но при этом вести активный образ жизни.
Я о том и написал — «разруха не в клозетах, а в головах»
dcc0
03.05.2015 18:14решать задачи бизнеса эффективнее, а ведь это главная цель программистов.
Ваши субъективное право относится к программированию как составляющей бизнеса.Fesor
03.05.2015 19:19Ваши субъективное право относится к программированию как составляющей бизнеса.
Ок, а тогда как к нему относиться еще? Так или иначе программисты решают задачи бизнеса. Тот же интернет-магазин — автоматизация и уменьшение расходов (не нужен физический магазин, можно улучшить логистику и т.д. лучше и проще отчетность). Или там Вася пупкин, который для души выпустил продукт и хочет что бы его использовали. И для этого он принимает решения которые позволяют ему развивать проект максимально эффективным образом и выкатывать новые фичи, которые требуют пользователи или которые могут нести им какую-то ценность (или себе) как можно быстрее пока конкуренты не сделали этого.
Или это все просто так и для души, и платят программистам просто так.
dcc0
03.05.2015 20:00-3Если Вам расскажут, зачем вообще все это надо, Вы все равно не поверите и будете стоять на своем…
Тем более, почему в России так активно продивагаются всякие «технологии»… типа JS, Ajax и всякая лабудень, но это уже мы уходим в политику.
Про ООП, ООП — это не программирование — это оперирование стуктурами, или данных или набором уже готовых логических схем.
Обратите внимание, как много и часто у нас затравливают системщиков, тех же сишников, чуть ли не единственных, которые вообще что-то понимают.
Обсуждать какой-то там бизнес, и то, что нужно какому-то там заказчику мне не интересно, для этого есть фриланс.
dcc0
03.05.2015 22:04-1Srsly? А формально доказать возьметесь?
А что, реальные доказательства не интересны?Fesor
03.05.2015 22:13+1Учим мат часть.
В целом предлагаю закрыть тему, так как народ тут не может определиться в разнице между «кодером» и «программистом», а вы тут поднимаете холивары на уровень выше.Idot
04.05.2015 04:36>народ тут не может определиться в разнице между «кодером» и «программистом»
Срач системные архитекторы с опухшим ЧСВ против всех остальных?
В реальной жизни программист обычно и за архитектора и за кодера — в одном лице! А не так что «Его Божественность Системный Архитектор написанием кода ручки не марает, весь код — индусы за еду пишут».lair
04.05.2015 11:09Бывает и наоборот. Есть компании, где на позиции архетектора код писать не принято. То есть даже и хотел бы, но на собеседовании честно говорят — мы ожидаем другого.
dcc0
03.05.2015 22:31-1Fesor, идите и учите, если Вам нужно. И избавьтесь от императивности в тоне…
Я никаких холиваров не поднимаю, есть выводы, сделанные на основе длительного наблюдения.
Кратко и конкретно: программисты ( «чем ниже уровень» ) почему-то у нас начиная с 90-х затравливались, массово.
«Пишу на С++ за еду» — и т.д.
Вот к этим словам автора, которым почему-то я верю, хотелось бы добавить
«Фреймворк же сковывает вас, привязывая к себе. Каждый из них имеет собственную выстроенную логику работы, которую не всегда можно запросто уловить. И при переходе с одного языка на другой/из одной, команды в другую вам приходится зачастую тратить несколько дней, чтобы понять, как использовать новый фреймворк».
Вот это:
И в общей массе уводит в сторону талантливых людей от фундаментальных разработок, вместо этого они бегут получать сертификаты от Микрософт, Хренософт, чтобы потом писать кнопочки для разных мелкокоммерческих сайтов.
" А формально доказать возьметесь? "
Формальным доказательством на 2015 год является почти полное отсутствие системного программирования в России.
P.S. Покажите мне российскую операционную систему, чтоб при загрузке там не торчало Ванилья Соурс и тогда можно переходить к формальным доказтельствам.
В целом предлагаю закрыть тему, Вот не надо ничего закрывать, не нравится тема, не читайте, места в Интернете много, хостинг штука резиновая… И, кстати, формально у нас в стране демократия =)lair
04.05.2015 00:26+2есть выводы, сделанные на основе длительного наблюдения.
Сколько лет вы в профессии?
Кратко и конкретно: программисты ( «чем ниже уровень» ) почему-то у нас начиная с 90-х затравливались,
У кого «у вас»? «У нас» не затравливались, и училось много, и работы было достаточно.
Формальным доказательством на 2015 год является почти полное отсутствие системного программирования в России.
Как это доказывает тезис «ООП — это не программирование»?dcc0
04.05.2015 12:08-1В какой профессии? Я нигде этого не озвучивал своей профессии.
Не надо думать, что Вы все понимаете только потому, что 15 лет занимаетесь программированием.lair
04.05.2015 12:09+1В какой профессии? Я нигде этого не озвучивал своей профессии.
Окей, мне не сложно переформулировать: сколько лет вы наблюдаете?
Я так понимаю, что доказательства тезиса «ООП — это не программирование» не будет?
Fesor
04.05.2015 01:55+1Ясно. Вы представляете сколько нужно человеко-лет для реализации операционной системы? А теперь скажите зачем? Потешить себя мыслью о национальной операционной системе? Да, операционку сложности DOS написать один человек более чем способен в адекватные сроки. Но кому сейчас нужен еще один DOS? Более того, кому сейчас нужна еще одна операционная система? По сути еще одна платформа, их и так уже слишком много.
P.S. Покажите мне российскую операционную систему, чтоб при загрузке там не торчало Ванилья Соурс и тогда можно переходить к формальным доказтельствам.
ReactOS например. Хотя опять же, ограничивать себя рамками национальной идеи как-то глупо когда разговор идет о настолько масштабном проекте.
является почти полное отсутствие системного программирования в России.
Не знаю как там в России, а в Беларуси с этим вроде как все хорошо. Другой вопрос что в системщики идут 2-4 человека из 100, но каков спрос таково и предложение.
И в общей массе уводит в сторону талантливых людей от фундаментальных разработок
я знаю массу людей которые уходили после ВУЗа в аспирантуру как раз таки что бы заниматься фундаментальными разработками. И где-то через пол года они расстраивались. И причем тут фреймворки и ООП?
p.s. Там есть кнопочка «ответить», в которую вы почему-то не попадаете.
dcc0
04.05.2015 12:16Вы сравнили — Беларусь и Россию. У вас порядка больше на порядок, а может на 2, а может на n.
Я не знаю, как сейчас обстоят дела с информатикой в школе в России (так как это фундамент того, что будет 10-20 лет), в 90-х преподавалась настолько безобразно, что складывать ощущение будто это делается просто нарочно.
Fesor
04.05.2015 13:45У вас порядка больше на порядок, а может на 2, а может на n.
Вот давайте вы поживете у нас и «понаблюдаете» годика 4 хотя бы. Порядок у нас граничит с маразмом и имитацией бурной деятельности и только. У каждой страны свои проблемы. Я думаю у вас что-то похожее только со своими нюансами.
в 90-х преподавалась настолько безобразно, что складывать ощущение будто это делается просто нарочно.
Я боюсь что с этим все плохо и тут как повезет с преподавателями. Сейчас и физику/математику в школах безграмотно преподают. Да и в ВУЗах частенько тоже начитывают бред. У всего есть причина и следствие — работать преподавателем не профитно ни по деньгам ни по статусу. Большинсто либо просто не смогли выйти дальше либо работают ради идеи, коих меньшинство.
dcc0
05.05.2015 21:42-1Ну вот, Вы сами это признаете. Вдобавок, есть некоторые причины считать, что сворачивание разработок в области и IT — как железо, так и программы — осуществлялось намеренно. И вместо фундаментальных знаний/занятий подбрасываются фреймворки (готовые решения, под капот почти не надо залезать), это почти на уровне пропаганды «Построй свой сайт легко и просто с такой-то системой 10 щелчками мыши».
Fesor
06.05.2015 00:13+1готовые решения, под капот почти не надо залезать
Мне нравится думать что человек должен понимать как устроено то что он использует хотя бы на один уровень абстракции ниже.
Построй свой сайт легко и просто с такой-то системой 10 щелчками мыши
Оукей, давайте вспомним начало 20-ого века.Было штучное производство автомобилей и бац, Форд придумал конвеерную сборку. В итоге все потихоньку начали автоматизировать производство в угоду бизнесу и потребителям. В то же время штучная сборка на заказ осталась. И для этой сборки часть деталей заказывается, часть делается вручную…
За последние лет 20 потребность в простых решениях увеличилась, так как потребителей стало невообразимо больше, в то же время вырастить сильных разработчиков как было сложно так и осталось. Вывод — уменьшение сложности и добавить армию роботяг, которые штампуют сотнями сайты в угоду бизнесу. Штучное производство осталось, его гораздо меньше но и людей которые могут его себе позволить не так много (относительно).
Idot
07.05.2015 14:53Статья www.geektimes.ru/post/249972 «Инфляция программного обеспечения с точки зрения ресурсов процессора — почему новые версии приложения порой гораздо медленнее старых?» — про последствия моды на фреймворки.
uLow
/Фреймворк же сковывает вас, привязывая к себе. Каждый из них имеет собственную выстроенную логику работы, которую не всегда можно запросто уловить. И при переходе с одного языка на другой/из одной, команды в другую вам приходится зачастую тратить несколько дней, чтобы понять, как использовать новый фреймворк. И при переносе проекта, вам, по сути, приходится заново создавать весь свой продукт. Если бы вы использовали голый язык, то с такой проблемой столкнуться не пришлось бы. Язык он и есть язык и новому разработчику в команде не пришлось бы тратить столько времени на понимание фреймворка, он бы сразу смог работать./
Если не использовать фреймворк, то первое, чем вы будете заниматься в новом проекте — писать свой фреймворк (роутинг, контроллеры, шаблоны...).
Чтобы не усложнять разработку изучением все новых и новых фреймворков, на сегодняшний день доступны микрофреймворки, которые фактически содержат в себе все необходимое. Да и сами они настолько похожи (к примеру Slim, Silex, Flight, Lumen), что изучать придется только один, скорее даже не фреймворк, а подход идеалогии микрофреймворков.
Fesor
В лучшем случае это будет именно так и из-за нехватки времени выйдет плохо и будут проблемы с производительностью В худжем по итогу мы будем иметь лапшу которую невозможно поддерживать.
vitalybaev
Не забываем про возможные огрехи в безопасности из-за невнимательности/нехватке времени.