Джесси, мне очень нужно было прочитать эту статью.

Я работал в небольшой команде разработчиков, которая росла и сокращалась на 3–7 разработчиков из-за различных реорганизаций и текучести кадров. Мы команда внутренних инструментов для киностудии, о которой вы слышали. В настоящее время наш список приложений и утилит насчитывает около тридцати пяти и продолжает расти. Широта технологий варьируется от Ruby on Rails до Python и Node.js. Мы использовали такие библиотеки, как Django, Flask, Angular, Backbone и Express. Что касается вас и ваших комментаторов, конечно, вы можете научиться любой из этих вещей, и это может быть даже не сложно, но для этого требуются время, ресурсы и, откровенно говоря, деньги. Из-за размера нашей команды с таким количеством различных продуктов мы теряем эффективность каждый раз, когда нам приходится менять контекст. Последние пару лет мы боролись за то, чтобы найти то, чего мы хотели придерживаться и двигаться вперед.

За две недели до анонса Angular 2 мы остановились на Angular 1 для нашего следующего проекта. После этого объявления мы перешли на Backbone. Хотя было весело работать с такой легкой библиотекой, отсутствие принудительных соглашений оказалось очень неприятным в проекте с довольно ограниченным графиком времени. Мне не нравилось, что нам приходилось принимать так много инфраструктурных решений только для того, чтобы заставить тесты работать или решить, где разместить файлы. Я хотел просто написать приложение.

Когда я только начал работать в этой команде, они были сосредоточены на приложениях Ruby on Rails, которые я никогда раньше не разрабатывал. Я изучил технологию и увидел в ней ценность. Наша студия много работает с Python, поэтому мы хотели отойти от Ruby. Затем Node.js стал большим, и мы подумали, что не сможем стать хорошей веб-командой, не изучая Node.js. Все эти решения за последние пять лет дали нам большой опыт, и мы выпустили несколько продуктов. Но я часто задаюсь вопросом, если бы мы просто остановились на Ruby on Rails, смогли бы мы поставить гораздо больше.

Ember — это фреймворк, с которым я раз или два сталкивался в начале его разработки, и он всегда был у меня в голове как Ruby on Rails для клиентского JavaScript. Но поскольку это был не новый продукт, и все статьи, всплывающие в различных новостных лентах, были о React и об Angular, мы никогда не чувствовали необходимости проверять его.

Недавно из-за реорганизации команда выросла до 7–8 разработчиков, и я ее возглавляю. Я действительно хочу, чтобы мы работали вместе, чтобы решить, какие инструменты мы можем попытаться стандартизировать. Мы почти уверены, что серверная часть будет содержать либо Python, либо Node. В прошлом году мы сделали проект с Angular 2 и были очень впечатлены им. Как лидер, я очень не решаюсь покупать Angular из-за отсутствия у них обязательств перед такими командами, как мы, в обеспечении стабильной дорожной карты разработки, где нам нужно поддерживать множество приложений.

Как разработчик, я хочу контроля, поэтому в прошлом я предпочитал конфигурацию условностям. Однако за последние несколько лет я полностью уверился в обратном: соглашение превыше конфигурации. Я пришел посмотреть, как я могу больше сосредоточиться на логике приложения, когда мне не нужно беспокоиться о шаблоне. К твоему сведению, Джесси, кто-то, более знакомый с клиентской разработкой, чем я, принимает решения за меня — и это нормально. Цель моей команды не в том, чтобы в студии быть мастером передовых технологий. Нам просто нужно отправить товар.

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