У нас с парой друзей есть традиция еженедельно проводить вечера кино, и хотя они всегда проходят весело, в итоге мы проводим всю неделю, выбирая, какой фильм посмотреть. Легко выбрать один с группой из 2–3 человек, но когда количество людей становится немного больше, это может быть действительно утомительным процессом. Кто-то всегда будет либо ненавидеть фильм, либо уже смотрел его. Ведь у каждого из нас есть свои вкусы, и их нужно учитывать, решая, на что потратить пару часов.

Что делать с этой «огромной» проблемой?
Как это всегда бывает, когда мне нужно сделать какую-то работу в колледже или просто выполнить несколько поручений, я склонен откладывать дела на потом. . Обычно я делаю это, придумывая несуществующую проблему и решая ее самостоятельно. Хотя написанное выше является проблемой, ее решение может оказаться излишним. :) Тем не менее, я люблю исследовать новые технологии и фреймворки, поэтому я не мог устоять перед этим.

Почему (так) ЗНАЧИТ?

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

Там, где есть дым, есть и огонь.

Как вы могли догадаться из названия, я PHP-разработчик. Не из тех, кто застрял на путях старого ужасного унаследованного PHP, а из тех, кто пытается следовать всем современным тенденциям, если я нахожу их полезными для моего рабочего процесса и продукта. Как и любой разработчик, самостоятельно создававший какие-либо веб-приложения, я довольно хорошо знаком с JavaScript, хотя и близко не являюсь экспертом, но я написал довольно много строк JavaScript и записал в console.log слишком много операторов, чтобы выяснить, что, черт возьми, не так с моим условным выражением. До этого момента я никогда не использовал JS-фреймворк на бэкэнде, а мой фронтенд обычно ограничивался кусочками, необходимыми для выполнения работы, а не полноценным фреймворком, таким как AngularJS.

Итак, как проходила разработка (небольшого) приложения в технологиях, построенных на разных принципах. Что мне в итоге понравилось, а что бы я изменил?

Что мне нравится в MEAN

1. Быстрая настройка

Когда я начинаю новый проект малого или среднего размера в своей повседневной работе, я обычно выбираю Laravel5 в качестве своего фреймворка, и мне действительно нравится его простота. Но время от времени мне приходится создавать тривиальное веб-приложение, всего пару простых конечных точек, которые затем используются каким-то другим внешним приложением. Меня это бесит, потому что мне нужно потратить около 10 минут только на то, чтобы настроить проект локально. Мне нужно создать новый проект, установить пакеты композитора, отредактировать мою конфигурацию Vagrant, перезапустить и подготовить машину Vagrant, отредактировать файл hosts, изменить конфигурацию Laravel и сгенерировать необходимые ключи, создать базу данных MySQL, и этот список можно продолжить… Все это для 2 конечных точек? Которые не используют даже 0,5% функций фреймворка?

Настройка моего приложения MEAN была самой простой вещью, какую только можно себе представить, запустите установку NPM, создайте файл, нажмите кнопку в WebStorm, чтобы запустить сервер, и вперед. Еще проще запустить его в производство, git pull, запуск PM2, новый конфигурационный файл nginx и вуаля, моя работа доступна для всеобщего обозрения. Мало того, что процесс установки прост, но приложение с той же базовой функциональностью занимает в 3 раза меньше места без огромных накладных расходов на инфраструктуру. Это достигается за счет использования только тех пакетов, которые вам нужны, без включения всего «на всякий случай» из коробки.

2. Яркое сообщество

Все мы знаем, что iPhone «Для этого есть приложение!» лозунг, который действительно верен, потому что вы можете найти приложение для всего, что душе угодно, в App Store. У NodeJS должен быть собственный слоган:

Для этого есть пакет!

Любая проблема, которая у вас есть, вероятно, есть бедняга, который сделал всю тяжелую работу за вас. Все, что вам нужно сделать, это установить его с помощью NPM. Не только это, но у вас, вероятно, также будет несколько альтернатив. С каждой очевидной проблемой, которую вы, возможно, уже задавали в какой-то малоизвестной ветке Stack Overflow.

3. JavaScript с обеих сторон

Читая множество материалов в Интернете, где люди восхваляют MEAN как лучшее, что есть в галактике Млечный Путь, часто приводится аргумент, что вам не нужно учить два языка, вы можете просто выучить один (пусть и причудливый язык). один). Я всегда находил этот аргумент немного бредовым, потому что, если вы знаете один язык программирования, подобрать другой довольно легко, если только вы в конце концов не знаете первый.

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

Вещи, которые мне НЕ понравились

1. Отсутствие принудительной структуры

Это первое, что меня испугало. Несмотря на то, что я нахожу инициализацию проекта простой и считаю ее огромным преимуществом, отсутствие файловой структуры и вся эта идея «с чистого листа» меня немного пугают. Когда вы инициализируете проект, вы получаете ничего, вы можете настроить его настолько просто или сложно, как вы хотите. Это круто, но я представляю себя работающим с командой людей или даже проверяющим собственный код через пару месяцев/лет. Я бы потерялся! Нет механизма, который помог бы вам организоваться, нет руководства, которому вы могли бы следовать, если хотите найти определенный фрагмент кода в проектах, написанных другими людьми. В такой среде, как Laravel, если вы хотите что-то изменить в представлении, вы точно знаете, в какую папку заглянуть. Нужно изменить некоторую бизнес-логику? Наверное в модели. Если разработчик не убрался со своего пути, чтобы испортить вам день, вы, вероятно, найдете то, что ищете, в логичном месте.

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

2. Прекращение поддержки и отказ

У меня такое ощущение, что на разработку новых фреймворков и инструментов JS тратится больше времени, чем на реальную работу с ними. Несмотря на то, что это действительно хорошо, потому что технологии продолжают развиваться, и в конечном итоге создаются новые классные вещи, это также приводит к тому, что вещи очень быстро становятся некрутыми, а их разработка прекращается. Какой здравомыслящий менеджер проекта решит использовать инструмент/фреймворк для каких-либо серьезных проектов, если есть шанс, что он устареет через две недели, еще до того, как продукт будет создан.
Это не так. Единственная проблема с небольшими/неиспользуемыми фреймворками, Angular был чрезвычайно популярен, а затем устарел в считанные дни, несмотря на то, что у него была огромная пользовательская база.

3. Я знаю JavaScript

Это, с точки зрения бизнеса, может быть огромной болью. Каждый уважающий себя фронтенд-разработчик знает JavaScript, он должен это делать, чтобы выполнять свою работу. Означает ли это, что у них есть навыки, необходимые для создания серверного приложения, готового к работе? Знают ли они, как спроектировать такую ​​систему, чтобы она оставалась ремонтопригодной, а не грудой спагетти-кода, который развалится, если потыкать в него зубочисткой? Большинство, наверное, нет, зачем им это? Это не их работа - беспокоиться о вещах такого рода, если у них нет личного интереса в этом вопросе, они, вероятно, будут знать только то, что им нужно знать, чтобы выполнить свою работу с интерфейсом.

Однако они знают JavaScript. Эта тонкая грань между разработчиком JavaScript и хорошим разработчиком бэкэнда JavaScript может привести к путанице, особенно при приеме на работу. Это может снова стать синдромом разработчика PHP. Все и их бабушки в какой-то момент были разработчиками PHP. Это был язык, который было легко освоить (так же, как JS), вы могли создавать настоящие приложения, не зная слишком много об архитектуре программного обеспечения (так же, как JS) и за выходные стать "PHP-разработчиком". Это, конечно, не означает, что вы можете делать какие-либо реальные приложения без того, чтобы все рухнуло в кучу пыли, для этого требуется совершенно другой набор навыков. Но у вас была (самостоятельная) должность — "PHP-разработчик". Из-за этого настоящие разработчики PHP и все сообщество выглядели как любители — чума, все еще переносимая языком и сообществом, хотя ситуация значительно улучшилась.

Итак, расскажите нам, наконец, что вы создали, чтобы решить постоянно растущую проблему вечеров кино?

Я создал movienight.site, сайт, который позволяет вам создавать 3 опроса фильмов, в которых другие могут голосовать, если им предоставлена ​​ссылка, и получать результаты в реальном времени от других голосующих. Вы можете посмотреть мой (ужасный) код на GitHub.

Первоначально опубликовано на itworkslocal.ly 29 декабря 2015 г.