Сейчас начало 2017 года, а фреймворков становится все больше и больше), а еще больше становится статей на тему "Как выбрать фреймворк" или почему тот или иной фреймворк самый пи$датый на свете. Так вот, для начала нужно запомнить самое важное - Все супер популярные фреймворки продвигают большие компании с маркетологами, почти каждый разработчик, который выкладывает в public свою библиотеку или фреймворк хочет, чтобы его инструмент использовался другими людьми и компаниями. Это не означает что все мудаки и хотят денег и славы, нет, не всегда. Просто это означает, что каждый человек и каждая компания преследует какие-то свои цели. Компании типа google продвигают подобные вещи, чтобы заслужить доверие у разработчиков. Это хороший способ, чтобы привлечь себе кадры (ты ведь начинаешь думать, что там работают норм.пацаны), еще это отличный способ подсадить тебя на свои инструменты, чтобы потом сообщить тебе, что в их облаке или платформе все интегрировано с этим фреймворком и стоить это будет 20$ в месяц (теперь на 10 минут работы меньше делать, за 20-ку, класс!!). Чем больше сообщество вертится вокруг инструмента, тем больше бесплатных тестировщиков получает команда разработчиков. Они сразу же сообщают о багах, даже сами фиксят иногда баги и отправляют разработчикам. И вот это самый страшный момент.
Последнее время качество подобных инструментов сильно снизилось, зачем тестировать так тщательно, когда за тебя это сделает грустный кодер, который вывалил свежую бетку на свой продакшен и чинит теперь ее в 3 часа ночи, потому что не хочет получить пи$ды от руководства.
Вот все это самое важно при выборе. Прежде чем влюбиться в фреймворк и почитать 2-3 строчки магического кода, которые сделают за вас всю работу, пожалуйста, убедитесь в том, что все это реально работает. Как это сделать?
Идем в гугл или на github (или переходим по ссылке с офф.сайта библиотеки) смотрим на кол-во звездочек. Набролось > 500-1000? Это отлично можно продолжать дальше. Смотрим на дату последнего коммита. Если не больше 1 месяца назад, значит ок. Идем в раздел Issues. В этом разделе смотрим на кол-во отправленных вопросов/багов и на их дату (если присылают часто, значит людям все еще интересен проект). Переходим во вкладу Closed (закрытые/пофикшеные баги), если ребята закрывают их хотя бы в течении недели, значит работа идет и если у вас что-то еба№ет, есть большая вероятность, что вам помогут. Обязательно погуглите, узнайте кто вообще пользуется этим фреймворком, что пишут, что говорят. Давайте так, программирование это не про психологию и философию, где нужно видеть хорошее, так что ищите минусы, ищите плохое и сомневайтесь. Потому что самые страшные вещи происходят, когда вы уже обмазались этим всем и назад дороги нет.
Представим теперь реальную ситуацию - фреймворк свежий, крутой, никто из известных и больших еще не пользовался им, обещает много и пи;дец какой няшка, хочу! Если это ваш проект, вы его сами спонсируете, дохода с сайта нет, пользователи не будут гнобить вас если что-то сломается, Оооокей, берете ставите, развлекаетесь, все хорошо. А если это коммерческий проект, самый популярный случай - вы сидите на зарплате в компании и у вас есть возможность принять участие в выборе инструмента. Перед тем как все это внедрять, даже по чуть-чуть обязательно затестите все это вне коммерческого проекта, посидите неделю другую поковыряйте его, реализуйте похожий ф-ционал в новой библиотеке/структуре/фреймворке вы должны точно быть уверенным, что вам станет удобнее работать, что все будет работать, что в команде все понимают на что идут и что некоторые вещи все равно придется самим додумывать.
Как тестировать все это. Юниттесты во фронтенде не так популярны как на бекенде, поэтому эти тесты не будут сообщать нам о проблемах кроссплатформенности и кроссбраузерности, придется ручками поработать)) похенджобить)), открываешь кучу браузеров, включаешь ПК или виртуалку и прокликиваешь все что можно.
Новый фреймворки обещают нам, что мы будем мало работать и много делать, а так же, что все будет супер производительно и мы даже можем об этом не беспокоится - сука ложь ваще!)
Обязательно проверяйте производительность, когда компонентов, элементов и всяких там ивентов и контроллеров становится много, в каждом фреймворке есть точка при которой все вдруг начинает безбожно тормозить, после чего часами, а то и днями приходится искать проблему, отключая каждый компонент и замеряя производительность. Когда глюк найден, начинаешь искать способ, чтобы пофиксить.
Ну и понаписал же я тут, жесть... Как выбрать то фреймворк? Простые правила:
У вас большая команда фронтендеров, а вы не готовы диктовать условия и правила игры, тогда берите AngularJS 1(не 2, потому что в марте уже выйдет 4))) или ReactJS, почему? Потому что эти фреймворки большие, они диктуют правила, команда играет по правилам и получает предсказуемый результат, если не играет и лажает, сразу видно где.
У вас есть команда, вы крутой ниндзя и вас любят и слушают, да у вас вообще все хорошо, не знаю зачем вообще вы это читаете)). Берете минимум, может у вас есть свои инструменты, своя структура проекта или вы в состоянии договорится как будете работать (это отличный вариант). Так что выбираете просто по опыту. Главное не быть принципиальной сукой! Всегда задавайте себе вопрос "А что если?". А что если никто не поймет и будет тупить? А что если все разъ:бется и кто будет чинить это кроме меня? А что если я забыл протестировать все это? и т.д.
У вас маленькая команда, которая вас слушает или вы один. Всегда стоит потестить большие фреймворки, они сложные, интересные, это пригодится для общего развития (главное сильно не упарываться, все равно во фронте все умирает за 1 год). А в реальности 1 человек делает не супер здоровенные проекты (можно сломаться физически/психически/морально) поэтому берите либы(библиотеки) берите все то, что не можете реализовать сами, берите те паттерны, которые вы понимаете и которые действительно упрощают код. Чтобы понять можете ли вы это реализовать я использую вот такой способ - Для начала я верю, что могу реализовать все сам на vanila js, а потом считаю сколько примерно времени у меня бы ушло на это + тесты + переделки и фиксы, допустим вышло около 2 недель или больше, значит я считаю что реализовать я это не могу т.к. для меня и для моих сроков это очень долго. Ищу уже реализованную фичу в гугле и так же тестирую ее как писал выше (по звездочкам на гитхабе и т.п.). И вот в какой-то момент ты уже собрал для себя пакет гов#, пакет потрясающих исходников, с опытом уже понимаешь, что тебе нужно для работы, чтобы реализовывать ф-ционал быстрее.
Ну и немного критериев для выбора инструмента: Скорость разработки, Скорость поиска и фикса багов, Общее субъективное впечатление и самое главное результат. Самое важное чтобы фичи работали, а подра№; "пооптимизировать" скорость всегда успеете.
Также не забывайте, что фреймворк не может делать ВСЕ хорошо, поэтому некоторые вещи на нем могут тормозить или быть неудобными в реализации. Выносите этот ф-ционал отдельно (вне инструмента) если это решит проблему. Если вы выбрали один жирный инструмент это не значит, что теперь вы должны действовать как фанатик.
Короче-чоъ, это тема на которую можно бесконечно говорить, VanilaJS наше все.
froncubator.com курсы для frontend разработчиков
https://vk.com/froncubator наша группа в vk
Последнее время качество подобных инструментов сильно снизилось, зачем тестировать так тщательно, когда за тебя это сделает грустный кодер, который вывалил свежую бетку на свой продакшен и чинит теперь ее в 3 часа ночи, потому что не хочет получить пи$ды от руководства.
Вот все это самое важно при выборе. Прежде чем влюбиться в фреймворк и почитать 2-3 строчки магического кода, которые сделают за вас всю работу, пожалуйста, убедитесь в том, что все это реально работает. Как это сделать?
Идем в гугл или на github (или переходим по ссылке с офф.сайта библиотеки) смотрим на кол-во звездочек. Набролось > 500-1000? Это отлично можно продолжать дальше. Смотрим на дату последнего коммита. Если не больше 1 месяца назад, значит ок. Идем в раздел Issues. В этом разделе смотрим на кол-во отправленных вопросов/багов и на их дату (если присылают часто, значит людям все еще интересен проект). Переходим во вкладу Closed (закрытые/пофикшеные баги), если ребята закрывают их хотя бы в течении недели, значит работа идет и если у вас что-то еба№ет, есть большая вероятность, что вам помогут. Обязательно погуглите, узнайте кто вообще пользуется этим фреймворком, что пишут, что говорят. Давайте так, программирование это не про психологию и философию, где нужно видеть хорошее, так что ищите минусы, ищите плохое и сомневайтесь. Потому что самые страшные вещи происходят, когда вы уже обмазались этим всем и назад дороги нет.
Представим теперь реальную ситуацию - фреймворк свежий, крутой, никто из известных и больших еще не пользовался им, обещает много и пи;дец какой няшка, хочу! Если это ваш проект, вы его сами спонсируете, дохода с сайта нет, пользователи не будут гнобить вас если что-то сломается, Оооокей, берете ставите, развлекаетесь, все хорошо. А если это коммерческий проект, самый популярный случай - вы сидите на зарплате в компании и у вас есть возможность принять участие в выборе инструмента. Перед тем как все это внедрять, даже по чуть-чуть обязательно затестите все это вне коммерческого проекта, посидите неделю другую поковыряйте его, реализуйте похожий ф-ционал в новой библиотеке/структуре/фреймворке вы должны точно быть уверенным, что вам станет удобнее работать, что все будет работать, что в команде все понимают на что идут и что некоторые вещи все равно придется самим додумывать.
Как тестировать все это. Юниттесты во фронтенде не так популярны как на бекенде, поэтому эти тесты не будут сообщать нам о проблемах кроссплатформенности и кроссбраузерности, придется ручками поработать)) похенджобить)), открываешь кучу браузеров, включаешь ПК или виртуалку и прокликиваешь все что можно.
Новый фреймворки обещают нам, что мы будем мало работать и много делать, а так же, что все будет супер производительно и мы даже можем об этом не беспокоится - сука ложь ваще!)
Обязательно проверяйте производительность, когда компонентов, элементов и всяких там ивентов и контроллеров становится много, в каждом фреймворке есть точка при которой все вдруг начинает безбожно тормозить, после чего часами, а то и днями приходится искать проблему, отключая каждый компонент и замеряя производительность. Когда глюк найден, начинаешь искать способ, чтобы пофиксить.
Ну и понаписал же я тут, жесть... Как выбрать то фреймворк? Простые правила:
У вас большая команда фронтендеров, а вы не готовы диктовать условия и правила игры, тогда берите AngularJS 1(не 2, потому что в марте уже выйдет 4))) или ReactJS, почему? Потому что эти фреймворки большие, они диктуют правила, команда играет по правилам и получает предсказуемый результат, если не играет и лажает, сразу видно где.
У вас есть команда, вы крутой ниндзя и вас любят и слушают, да у вас вообще все хорошо, не знаю зачем вообще вы это читаете)). Берете минимум, может у вас есть свои инструменты, своя структура проекта или вы в состоянии договорится как будете работать (это отличный вариант). Так что выбираете просто по опыту. Главное не быть принципиальной сукой! Всегда задавайте себе вопрос "А что если?". А что если никто не поймет и будет тупить? А что если все разъ:бется и кто будет чинить это кроме меня? А что если я забыл протестировать все это? и т.д.
У вас маленькая команда, которая вас слушает или вы один. Всегда стоит потестить большие фреймворки, они сложные, интересные, это пригодится для общего развития (главное сильно не упарываться, все равно во фронте все умирает за 1 год). А в реальности 1 человек делает не супер здоровенные проекты (можно сломаться физически/психически/морально) поэтому берите либы(библиотеки) берите все то, что не можете реализовать сами, берите те паттерны, которые вы понимаете и которые действительно упрощают код. Чтобы понять можете ли вы это реализовать я использую вот такой способ - Для начала я верю, что могу реализовать все сам на vanila js, а потом считаю сколько примерно времени у меня бы ушло на это + тесты + переделки и фиксы, допустим вышло около 2 недель или больше, значит я считаю что реализовать я это не могу т.к. для меня и для моих сроков это очень долго. Ищу уже реализованную фичу в гугле и так же тестирую ее как писал выше (по звездочкам на гитхабе и т.п.). И вот в какой-то момент ты уже собрал для себя пакет гов#, пакет потрясающих исходников, с опытом уже понимаешь, что тебе нужно для работы, чтобы реализовывать ф-ционал быстрее.
Ну и немного критериев для выбора инструмента: Скорость разработки, Скорость поиска и фикса багов, Общее субъективное впечатление и самое главное результат. Самое важное чтобы фичи работали, а подра№; "пооптимизировать" скорость всегда успеете.
Также не забывайте, что фреймворк не может делать ВСЕ хорошо, поэтому некоторые вещи на нем могут тормозить или быть неудобными в реализации. Выносите этот ф-ционал отдельно (вне инструмента) если это решит проблему. Если вы выбрали один жирный инструмент это не значит, что теперь вы должны действовать как фанатик.
Короче-чоъ, это тема на которую можно бесконечно говорить, VanilaJS наше все.
froncubator.com курсы для frontend разработчиков
https://vk.com/froncubator наша группа в vk
Комментариев нет:
Отправить комментарий