Comments 52
Достаточно загуглить "microframework <ваш ЯП>".
UFO just landed and posted this here
Сразу оговорюсь, что сам я пока дилетант (уже не первый месяц без особых успехов грызу Vue.js).
Строго говоря, фреймворки следует отличать от библиотек. Современный веб-фреймворк — это фундамент, на котором можно построить веб-приложение с заметно меньшими усилиями, чем при использовании, скажем, чистого JavaScript. Правда, сначала потребуется освоить этот фреймворк.
Если бы… По моему скромному опыту, даже при использовании веб-фреймворка мозгу приходится работать, работать и работать…
Приведу конкретный пример. Насколько мне известно, объем кода собственно Vue.js относительно невелик даже по сравнению с другими популярными веб-фреймворками, не говоря уже об операционных системах. Не знаю, сколько строк содержит этот код, но размер минифицированного файла vue.min.js — меньше 90 КБ. Правда, для разработки сколько-нибудь серьезного приложения могут потребоваться дополнительные библиотеки, такие как Vuex, Vue Router и иже с ними.
Если где-то ошибся, надеюсь, меня поправят.
P.S. Вообще говоря, эта статья выглядит как неумелый наброс…
На практике, это означает, что инструмент должен:
1. содержать минимальный набор стандартных, максимально оптимизированных функций
Строго говоря, фреймворки следует отличать от библиотек. Современный веб-фреймворк — это фундамент, на котором можно построить веб-приложение с заметно меньшими усилиями, чем при использовании, скажем, чистого JavaScript. Правда, сначала потребуется освоить этот фреймворк.
2. инструмент не должен заставлять программиста изучать что-то вроде нового «недоязыка» программирования полностью отключающего мозг
Если бы… По моему скромному опыту, даже при использовании веб-фреймворка мозгу приходится работать, работать и работать…
3. и все это, в идеале, должно быть оформлено в легкую библиотеку, не пытающуюся тягаться по объему кода с операционной системой.
Приведу конкретный пример. Насколько мне известно, объем кода собственно Vue.js относительно невелик даже по сравнению с другими популярными веб-фреймворками, не говоря уже об операционных системах. Не знаю, сколько строк содержит этот код, но размер минифицированного файла vue.min.js — меньше 90 КБ. Правда, для разработки сколько-нибудь серьезного приложения могут потребоваться дополнительные библиотеки, такие как Vuex, Vue Router и иже с ними.
Если где-то ошибся, надеюсь, меня поправят.
P.S. Вообще говоря, эта статья выглядит как неумелый наброс…
Да самое плохое, что подобный подход к программирование просто отучает думать и когда этот новый супер крутой фейерверкер дает сбой
Кажется, если люди настолько ленивы и склонны профессионально деградировать, что фреймворк, который делает за них много и облегчает рутину, становится злом, потому что эти специалисты внезапно забывают все остальное — проблема скорее специалистов, а не фреймворков.
Для реализации самых элементарных функций web приложения вам необходимо подключать отдельные gem-ы
Вы всегда можете попытаться реализовать их самостоятельно с достаточным уровнем качества, стабильности и защищенности, чтобы с большой вероятностью иметь возможность убедиться, что это не совсем элементарные функции. Речь, конечно, не идет о node.js со склонностью его пользователей вытягивать гигабайты библиотек для элементарных вещей.
инструмент не должен заставлять программиста изучать что-то вроде нового «недоязыка» программирования полностью отключающего мозг
Вообще странно, что изучение чего-то нового отключает мозг. Обычно наоборот.
Вы всегда можете попытаться реализовать их самостоятельно с достаточным уровнем качества, стабильности и защищенности, чтобы с большой вероятностью иметь возможность убедиться, что это не совсем элементарные функции.
Именно так мы и поступили. Написали на Си gem для Ruby в котором собрали все что используем чаше всего и теперь на нем работаем. Не уверен можно ли здесь публиковать ссылки потому если будет интересно — напишите. Пришлю где его можно посмотреть.
Именно так мы и поступили. Написали на Си gem для Ruby в котором собрали все что используем чаше всего и теперь на нем работаем. Не уверен можно ли здесь публиковать ссылки потому если будет интересно — напишите. Пришлю где его можно посмотреть.
Чистые, как агнец божий, программисты в современном мире не живут, их обходят более быстрые писаки на «псевдоязыках». Чистый код не интересен бизнесу. И да язык, фреймворки и библиотеки всего лишь инструменты — под задачу.
Всему свое место и время. Если не разобраться с этим тезисом, то так и будешь всю жизнь ассемблером микроскопом забивать гвозди. И даже статьи не надо писать, всего одно предложение. Так что тут и 2й тезис подъехал — не создавай проблем там, где их нет)
Фреймворки придуманы не сколько для ускорения работы, сколько для её удешевления. "фреймворкер" может многое не знать и не уметь и при этом выдавать работающий софт.
Конечно, софт будет тормозить, у него будут проблемы с нестандартным функционалом, разработка будет занимать непредсказуемое время из-за войны с фреймворком, но зато можно набрать команду из сеньора и толпы студентов, и они выдадут продукт.
Что делать сеньорным командам? Хорошие сфокусированные библиотеки, решающие одну проблему и решающие её хорошо. Хороший модульный код с максимальной инкапсуляцией, написанный по тому же принципу — сфокусированность и качество. Хороший язык программирования, позволяющий писать изолированные модули и их композицию.
Могу добавить, что изучение ФП значительно повышает качество кода, вне зависимости от языка программирования.
UFO just landed and posted this here
Фреймворки колоссально облегчают разработку.
В каком проекте может быть проще заново реализовывать шаблонизаторы, ORM, парсинг HTTP запросов, генерацию HTTP ответов, generic views (для CRUD компонентов), админку, роутинг, защиту от CSRF, REST API, и многое другое?
Не использовать готовый фреймворк не значит писать ORM и прочее с нуля, для этого библиотеки есть.
Меня, честно говоря, очень удивляет позиция практически всех комментаторов, которые путают фреймворки и библиотеки. Отличие очень простое — библиотеку всегда можно заменить за разумное время на другую, с похожим функционалом. Фреймворк — нет.
Еще почему-то многие не верят в существование библиотек в природе и делают выбор только между фреймворком и самописками.
Преимущества использования библиотек очевидны — это декомпозиция, инкапсуляция и возможность замены неподходящих/устаревших/медленных сторонних компонентов на альтернативы или, в крайних случаях, на свои разработки. Приложение на библиотеках способно эволюционировать, заменяя или развивая неподходящие части по мере эволюции. Выбор же фреймворка — это навсегда, проще будет переписать заново.
С недостатками тоже всё понятно — чтобы собрать самому целостный каркас приложения с нуля и поддерживать его качество, требуется навык, опыт, и, чего уж там, некоторые вложения труда. Но по моему опыту это вложение окупается многократно.
Отличие очень простое — библиотеку всегда можно заменить за разумное время на другую, с похожим функционалом. Фреймворк — нет.
Как человек, однажды переносивший значимый код из AngularJS в реакт, я вам скажу, что ваш тезис на редкость бессмысленен. Очень многое зависит от самого кода, в котором вы собрались что-то менять, и не менее многое — от того, что вы считаете «разумным» временем. С критериями такой потрясающей точности я вам любой чужой код могу подписать под «библиотеку» или же под «фреймворк», в зависимости от того, как мне захочется.
UFO just landed and posted this here
Фреймворки придуманы не сколько для ускорения работы, сколько для её удешевления.
Именно для ускорения. Вы просто попробуйте включить NIH-синдром на полную мощность, и поделать что-нибудь относительно масштабное на фронте (да и на бэке), а потом еще обеспечить кроссплатформенность и прочие типичные желания бизнеса.
«фреймворкер» может многое не знать и не уметь и при этом выдавать работающий софт.
А кто будет работать, пока вы (и все остальные) будут грызть гранит теории, чтоб знать всё?
UFO just landed and posted this here
1) до фреймворков я писал все это вручную
2) при работе с фреймворком, регулярно читаю его исходники, чтобы понять, как он устроен
3) просто любопытно — мне кажется, что хороший разработчик должен быть любопытным
Ну да, и еще 4) надо знать как оно устроено тупо потому, что иначе можно не сойтись во взглядах с авторами фреймворка и убить всю производительность, память, и так далее (в документации не всё пишут).
В голову одного человека не могут вместиться все знания, связанные с базами данных, API, нюансами HTTP, безопасностью, и т.д.
Очень даже ошибаетесь. Слава яйцам такие люди есть и всегда будут, но конечно по сравнению со всей массой «разработчиков» их ничтожное кол-во. И это конечно печально, но тут ничего не поделаешь, люди так устроены, не просто так есть расслоение населения по «классам». Так же и в разработке, многие считают себя хорошими специалистами, а по факту им до них ещё расти и расти.
UFO just landed and posted this here
Я вот за все двадцать с лишним лет работы в отрасли ни одного такого не видел.
В голову одного человека не могут вместиться все знания, связанные с базами данных, API, нюансами HTTP, безопасностью, и т.д.
Очень даже ошибаетесь.
Ощущение «всё знаю» возникает если не развиваться вширь и не развивать свой кругозор.
Слава яйцам такие люди есть и всегда будут
За всю карьеру — ни одного не видел. Видел тех, кто знает что-то досконально, и плюс к этому знает все «правильные ответы» из множества других областей, так или иначе связанных с его деятельностью. То есть, спец в некоторых вещах, и знаток «по верхам» многих других вещей. И даже таких людей очень мало.
Тот, кто знает всё в деталях в очень широком наборе вопросов — он, очевидно, не может работать; всё его время будет уходить на то, чтоб поддерживать свой уровень.
Заводы придуманы не столько для ускорения, сколько для удешевления. Рабочий может многое не знать и не уметь и при этом выдавать работающий продукт.
Конечно, продукт будет бракованным, у него будут проблемы с использованием не по назначению, настройка оборудования будет занимать непредсказуемое время, зато можно набрать команду из чернорабочих и одного мастера.
А что делать ремесленным командам? Пилить по 5 лет «произведения ремесленного искусства». Например инструменты, позволяющие работать ещё эффективнее (но ни в коем случае не использовать их самим, чтобы не уподобляться чернорабочим).
Могу добавить, что изучение пасатижей значительно повышает качество продукции, вне зависимости от профиля работ.
Конечно, продукт будет бракованным, у него будут проблемы с использованием не по назначению, настройка оборудования будет занимать непредсказуемое время, зато можно набрать команду из чернорабочих и одного мастера.
А что делать ремесленным командам? Пилить по 5 лет «произведения ремесленного искусства». Например инструменты, позволяющие работать ещё эффективнее (но ни в коем случае не использовать их самим, чтобы не уподобляться чернорабочим).
Могу добавить, что изучение пасатижей значительно повышает качество продукции, вне зависимости от профиля работ.
А почему ни слова про чудовищно низкую производительность Ruby on Rails и Symfony? И вообще если использовать ORM, это просто убийство производительности. Или никого не смущает когда бэкенды отвечают секундами и сотнями миллисекунд?
UFO just landed and posted this here
А почему ни слова про чудовищно низкую производительность Ruby on Rails и Symfony?
Смею предположить, что не умеете готовить
И вообще если использовать ORM, это просто убийство производительности.
Гидрируем в массивы и импакт от ORM становится незаметным
Или никого не смущает когда бэкенды отвечают секундами и сотнями миллисекунд?
Вы подтверждаете мое предположение про умение готовить
Смею предположить, что не умеете готовить
Смешно, как раз таки бэкенды написанные мной отрабатывают менее чем за 0.5ms в среднем на каждый запрос, плюс сетевой пинг до клиента. Загрузка CPU около нулевая, отжирание оперативки ни о чем. Разумеется эта скорость не доступна для популярных фреймворков особенно в связке с ORM. Я считаю если у тебя обычные CRUD операции работают дольше 2ms именно бэк + БД, то это просто не приемлемо. Кроме случаев когда у тебя сотни тысяч запросов в секунду летит на чтение и запись конечно. Но 99.9999% диванных экспертов работа в проектах где в самый самый пик будет 50-60 запросов в секунду.
UFO just landed and posted this here
Разумеется эта скорость не доступна для популярных фреймворков особенно в связке с ORM
Вы еще раз подтверждаете мое предположение про умение готовить. Время инициализации вполне отлично тюнится. Что касается тяжелых БД запросов, часто эта проблема решается за счет очередей. Если нужно именно за http запрос вытянуть много всякого без кэширования — пишется raw запрос с гидрацией в массив.
А почему ни слова про чудовищно низкую производительность Ruby on Rails и Symfony?
Потому что не в этом их цель, да и всё нормально с производительностью у Symfony так точно. Там теперь даже ORM из коробки не идёт.
вообще если использовать ORM, это просто убийство производительности.
Если у вас тормозит доктрина, возможно вы её используете не по назначению и грузите из неё сущности пачками.
Фреймворки — больше минусов чем плюсов
Прямо как у этого поста)
Вообще, когда запятых начинает не хватать уже с заголовка, это дурное предзнаменование.
попытка всех без исключения авторов фейерверков изобрести, что-то вроде своего языка программирования
DSL.
AleksShved
Ваши рассуждения могут быть вполне справедливы для мелких проектов, грубо говоря на одного/пару инженеров, но не более. Хотите вы того, или нет, но функциональность проекта должна быть написана, у вас так, или иначе получится свой "фреймворк". Разница между вашим правильным и плохим чужим в том, что чужой:
Имеет bus-фактор на порядки больше вашего.
Когда вы уходите с проекта, вы уносите с собой знания о вашем фреймворке. Это сильный удар по команде. Я лично попал в такую ситуацию, через 2 недели после моего устройства автор хорошего фреймворка уволился, bus-фактор был 1, стал 0. Было дешевле переписать, на известном фреймворке, чем поддерживать.
На много лучше документирован.
Это официальная документация, статьи, вопросы на stackoverflow, issues на github и т.д. Я очень сомневаюсь, что вы можете похвастаться чем-то подобным про свой правильный фреймворк.
На много лучше протестирован.
Я сильно сомневаюсь, что вы можете попасть хотя бы в 1% ситуаций от тех, в которые попали/попадают пользователи того, или иного фреймворка. Для популярного фреймворка с довольно большой вероятностью столкнувшись с проблемой можно быстрее найти ее решение.
Во многом лучше реализован.
Это спорное утверждение, и корректно только в частностях, по этому приведу пример: http роутер symfony — дико мощная и производительная штука, если у вас получилось лучше, я очень хотел бы взглянуть.
Не тратит ваше время на разработку себя.
Поддержка собственного правильного фреймворка — это куча времени, которого как правило нет.
Безусловно, бывают ситуации, когда существующие фреймворки вам ни как не помогают в решении задачи, конкретно в таких ситуациях напил своего вполне оправдан.
>> И что же делать?
Коротко — подстраиваться. Хотя ещё есть вариант найти некое подразделение «перспективных разработок», где думают именно на перспективу. Но обычно под этой вывеской сидят зазнавшиеся бездельники и думают они лишь о том, как бы позабористей навешать лапши начальству.
В более реалистичном случае нужно просто неторопливо писать «правильные» библиотеки для себя, отбирать «правильные» готовые решения. В сумме получится приятная для существования экосистема. Но если придётся менять работу, то сразу наступит этап купания в ледяной проруби со всеми этими забавными игрушками, с которыми нужно разбираться и, самое главное, самому себя заставлять хлебать это гуано полной ложкой.
Ну и стоит заметить, что так же было бы неплохо научиться разделять фреймворки на «отстой» и «более или менее». То есть часто встречаются совершенно безумные поделия, но иногда можно найти что-то полезное, правда в обмен на полезности придётся мириться с некоторыми изысками авторов, которые могут не понравиться. Из второй категории можно постепенно выбрать инструменты для более глубокого ознакомления и длительного использования. Но опять же — на новой работе это всё может оказаться невостребованным.
А вообще, боль разработчиков по поводу «ну почему всё так убого» — разделяю. Хотя и объяснение давно известно — таков мир, который ни разу не идеален. Общее решение скорее должно касаться нахождения вашего личного места в этом мире.
Коротко — подстраиваться. Хотя ещё есть вариант найти некое подразделение «перспективных разработок», где думают именно на перспективу. Но обычно под этой вывеской сидят зазнавшиеся бездельники и думают они лишь о том, как бы позабористей навешать лапши начальству.
В более реалистичном случае нужно просто неторопливо писать «правильные» библиотеки для себя, отбирать «правильные» готовые решения. В сумме получится приятная для существования экосистема. Но если придётся менять работу, то сразу наступит этап купания в ледяной проруби со всеми этими забавными игрушками, с которыми нужно разбираться и, самое главное, самому себя заставлять хлебать это гуано полной ложкой.
Ну и стоит заметить, что так же было бы неплохо научиться разделять фреймворки на «отстой» и «более или менее». То есть часто встречаются совершенно безумные поделия, но иногда можно найти что-то полезное, правда в обмен на полезности придётся мириться с некоторыми изысками авторов, которые могут не понравиться. Из второй категории можно постепенно выбрать инструменты для более глубокого ознакомления и длительного использования. Но опять же — на новой работе это всё может оказаться невостребованным.
А вообще, боль разработчиков по поводу «ну почему всё так убого» — разделяю. Хотя и объяснение давно известно — таков мир, который ни разу не идеален. Общее решение скорее должно касаться нахождения вашего личного места в этом мире.
В более реалистичном случае нужно просто неторопливо писать «правильные» библиотеки для себя, отбирать «правильные» готовые решения. В сумме получится приятная для существования экосистема.
В более реалистичном случае эта приятная экосистема будет скорее всего никогда не создана (технологии устаревают, да и автор со временем скорее всего будет писать лучше, и на свой старый код будет смотреть искоса). И даже в том исчезающе малом количестве случаев, когда будет — остальные от неё будут шарахаться по причинам, описанным в комменте над вашим.
От фреймворков же не шарахаются. Так что здесь вы просто узко смотрите на мир.
Разумеется, вы можете работать в достаточно большой конторе, которая экономически сможет выращивать свой фреймворк.
Вообще, речь шла про инструменты. Про фреймворк было сказано как про «самый большой инструмент», то есть если не отказываются от самого большого, то про меньшие и говорить нечего. Поэтому экономика в данном случае точно так же корректируется на «размер» инструмента.
Ну и про фреймворки — какой-нибудь спринг выкинуть — очень даже полезно, а заменить его можно весьма скромным набором более приспособленных к задаче инструментов. Экономически это недорого, ну а по претензиям на «фреймворковость» вполне сравнимо с тем же спрингом. То есть опять всё доступно и нет серьёзных ограничений кроме лени или отсутствия вменяемых разработчиков.
Ну и про фреймворки — какой-нибудь спринг выкинуть — очень даже полезно, а заменить его можно весьма скромным набором более приспособленных к задаче инструментов. Экономически это недорого, ну а по претензиям на «фреймворковость» вполне сравнимо с тем же спрингом. То есть опять всё доступно и нет серьёзных ограничений кроме лени или отсутствия вменяемых разработчиков.
Ругаете фреймворки и просите универсальный инструмент.
фейерверкер фремверкеров *facepalm*
фейерверкер фремверкеров *facepalm*
Моя первая претензия и к RoR, и Yii, и Symfony, и почти всем иным, с которыми пришлось познакомиться — их монстрообразность и тонны совершенно лишнего кода
Lumen, Slim, Silex, тон лишнего кода нету.
Возможно. Понятно, что досконально разбираться в коде всех у меня возможности не было. Нужно еще и работать.
Но интересно. Такое впечатление что половина тех кто пытается комментировать даже не поняла о чем статья. Увидела что ругают их любимые фреймверки и понеслась в бой. Я не против «инструментов» оптимизирующих работу. Я против того какие они. Точнее большинство из них в настоящее время.
Но интересно. Такое впечатление что половина тех кто пытается комментировать даже не поняла о чем статья. Увидела что ругают их любимые фреймверки и понеслась в бой. Я не против «инструментов» оптимизирующих работу. Я против того какие они. Точнее большинство из них в настоящее время.
Ну вы же сами в конце выставили требования, они как раз подходят под 90% микрофреймворков. Вам не кто не запрещает собирать что-то свое под свои нужды. Jquery сокращает код очень существенно (до десятки тысяч строк кода в мелком/среднем проекте), приходилось писать на нем части веб-приложения, другое дело бывало встречались сайты где его использовали ради одного ScrollTop. А уж Vue/Angular/React сокращают время разработки и облегчают ее просто многократно, после Jquery прямо небо и земля.
Как раз про Jquery я написал что цитата " При этом jq имеет кучу других плюсов ради которых я готов освоить новый синтаксис. " ))
А вообще я уже прочитал здесь столько мнений… С какими то я согласен с какими то нет Но однозначно думаю пора бы написать еще одну статью и как то все это суммировать )
А про «ScrollTop» вы даже не представляете сколько мне приходилось встречать сайтов где ради одной элементарной функции человек подключал кучу какого то барахла про который часто даже ни кто не слышал.
Более того как то прочила в блоге у одного товарища «После этого подлючаем наш замечательный less который из одной строчки нашего кода генерит 20к строк в css фале» (как то так) и все это только ради того что бы залить окружность радиальным градиентом с переходами.
А вообще я уже прочитал здесь столько мнений… С какими то я согласен с какими то нет Но однозначно думаю пора бы написать еще одну статью и как то все это суммировать )
А про «ScrollTop» вы даже не представляете сколько мне приходилось встречать сайтов где ради одной элементарной функции человек подключал кучу какого то барахла про который часто даже ни кто не слышал.
Более того как то прочила в блоге у одного товарища «После этого подлючаем наш замечательный less который из одной строчки нашего кода генерит 20к строк в css фале» (как то так) и все это только ради того что бы залить окружность радиальным градиентом с переходами.
Разве ваши самописные инструменты не будут являться фреймворками?
Очень не правильное рассуждение.
Понятие фреймворков сейчас изменилось, а вы продолжаете жить в древние времена, сейчас это расширенная либа с определенной структурой, подходом, правилами и кодестайлом.
Использование фреймворка позволяет сконцетрировать силы на написание важных частей приложений.
Да, постепенно от базового фреймворка остается мало, но это правильный цикл, чем изобретать велосипед.
И видно, что автор не работал с Yii2 и тем более с Yii3, также автор не знает тенденций современной разработки.
Сейчас задачи у программистов:
1. делать быстро с максимальным покрытием тестами — во многих крупных компаниях CI/CD через TDD;
2. параллельно рефакторить, профилировать, оптимизировать;
3. использовать подход DDD — очень большое кол-во кода переходит из проекта в проект, тем самым все заворачивают всё в приватные репы, которые потом подключаешь к нужным проектам.
Понятие фреймворков сейчас изменилось, а вы продолжаете жить в древние времена, сейчас это расширенная либа с определенной структурой, подходом, правилами и кодестайлом.
Использование фреймворка позволяет сконцетрировать силы на написание важных частей приложений.
Да, постепенно от базового фреймворка остается мало, но это правильный цикл, чем изобретать велосипед.
И видно, что автор не работал с Yii2 и тем более с Yii3, также автор не знает тенденций современной разработки.
Сейчас задачи у программистов:
1. делать быстро с максимальным покрытием тестами — во многих крупных компаниях CI/CD через TDD;
2. параллельно рефакторить, профилировать, оптимизировать;
3. использовать подход DDD — очень большое кол-во кода переходит из проекта в проект, тем самым все заворачивают всё в приватные репы, которые потом подключаешь к нужным проектам.
Понятие фреймворков сейчас изменилось
Framework = каркас, отличие от билиотеки в IoC.
сейчас это расширенная либа с определенной структурой, подходом, правилами и кодестайлом.
Меня не интересует «структура, подходы и кодстайл» либы. Только её интерфейс. Фреймворк общего назначения не должен оказывать значительное влияние на структуру моего приложения.
И видно, что автор не работал с Yii2 и тем более с Yii3, также автор не знает тенденций современной разработки.
Yii 2 это старьё с кучей велосипедов, давно устаревшими подходами, скудным и ужасно реализованным функционалом прибитым к фреймворку. Yii 3 — попытки дожать труп.
Сейчас задачи у программистов:
1. делать быстро с максимальным покрытием тестами — во многих крупных компаниях CI/CD через TDD;
Можно примеры «многих» таких компаний? Чтобы вот прям TDD, не налепить приёмочных перед реализацией, не просто test first, а именно TDD с юнит тестами и инкрементальной разработкой. И CI/CD с частыми релизами и всем вот этим вот, а не просто cs fixer на гит хук поставили
использовать подход DDD — очень большое кол-во кода переходит из проекта в проект, тем самым все заворачивают всё в приватные репы, которые потом подключаешь к нужным проектам.
DDD про общение с бизнесом(конкретным, на конкретном проекте), перенос знаний в код, общую терминологию, ни о каких «общих библиотеках» там речи нет.
del(промахнулся веткой)
Фреймворки, и яркий пример — Симфони, это исключительно про стандартизацию. Фреймворку всё равно что вы будете писать. Его задача, чтобы ваш код был максимально похож на то, что было бы написано кем-то другим. Это именно та архитектура, которую уже знают все кто пишет на ФВ. Когда и если вы познаете всю мудрость архитектур всех ФВ и на основе этого напишете свой собственный ФВ или супер библиотеку — они никому не будут нужны. Точнее, придется переучить миллионы программистов с Симфони на ваш ФВ.
Когда вы пишите для себя — ваша попоболь от ФВ никого не интересует. Но, когда после вас ваш код придется читать кому-то ещё, он испытает ещё большую боль от изучения вашего кода, вашего уникального и неповторимого супер оптимизированного подхода с короткими названиями методов и переменными в одну букву.
Всем уже всё равно на оптимизацию. Все уже лет 10 как поняли, что написать проект можно и быстро и дешево, и даже супер оптимально. А вот дальнейшая поддержка и модернизация этого супер оптимального кода может стать не то что очень дорогой — от работы с таким проектом программисты просто будут отказываться (На всякий случай: из-за высокой сложности. С меньшими усилиями и без ощущения боли в заднем проходе, они за то же время заработают столько же, что и с супер уникальным кодом. И очень многие согласятся заработать даже меньше предложенного, избегая этого «всем известного» стресса).
Когда вы пишите для себя — ваша попоболь от ФВ никого не интересует. Но, когда после вас ваш код придется читать кому-то ещё, он испытает ещё большую боль от изучения вашего кода, вашего уникального и неповторимого супер оптимизированного подхода с короткими названиями методов и переменными в одну букву.
Всем уже всё равно на оптимизацию. Все уже лет 10 как поняли, что написать проект можно и быстро и дешево, и даже супер оптимально. А вот дальнейшая поддержка и модернизация этого супер оптимального кода может стать не то что очень дорогой — от работы с таким проектом программисты просто будут отказываться (На всякий случай: из-за высокой сложности. С меньшими усилиями и без ощущения боли в заднем проходе, они за то же время заработают столько же, что и с супер уникальным кодом. И очень многие согласятся заработать даже меньше предложенного, избегая этого «всем известного» стресса).
Sign up to leave a comment.
Фреймворки — больше минусов чем плюсов