Рассказ о разработке, ориентированной на продукт

«Если вы фронтенд-разработчик и до сих пор не используете React в своих проектах, возможно, вы плохой фронтенд-разработчик. Вы ведь тоже не используете ES6? Тогда плохо для тебя. Может быть, Webpack? Нет? Почему тебя до сих пор не уволили? »

Бьюсь об заклад, вы все слышали подобное мнение раньше. Окружающие хотят, чтобы мы использовали новейшие доступные нам технологии сразу после их создания. Мы прекращаем работу над нашими проектами, написанными без использования React / ES6 / Webpack (или назовите другую новую технологию) только потому, что это не круто, что они были написаны без использования этой технологии. Потому что кто-то сказал, что применяемая нами технология мертва и никто ее больше не использует. Мы тратим кучу времени на то, чтобы все изменить, несмотря на то, что в итоге получим такой же рабочий продукт.

Должны ли мы всегда делать это так слепо? Нет, не совсем. Прекратите это делать. Новые технологии - не всегда хорошо. И вот почему.

Продукт превыше всего

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

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

Более того, ваших пользователей не волнует, какой фреймворк вы используете для разработки своего приложения. Они хотят, чтобы это решило их проблемы. Существует так много отличных продуктов, которые были разработаны с использованием технологий, которые некоторые люди не хотят использовать, потому что считают их «мертвыми».

jQuery, Backbone, LESS, Ember и т. д. Вы все еще думаете, что эти вещи мертвы? Так что, возможно, вам нужно посмотреть, например, список компаний, которые используют Backbone. Или компании, использующие jQuery. Или Ember. Эти фреймворки используют такие проекты, как Pinterest, WordPress, Yandex, StackOverflow, Amazon, Square, TED. И эти проекты работают очень хорошо, и у них много довольных пользователей.

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

Слишком много шумихи

Я не имею в виду, что нам не нужно двигаться дальше и внедрять новые технологии в разработку наших продуктов.

Front-end растет с огромной скоростью, пожалуй, быстрее, чем любая другая область разработки программного обеспечения. Разработчики привносят новые парадигмы и новые шаблоны проектирования из других языков программирования, а также создают новые фреймворки и новые библиотеки. Кажется, что каждый разработчик должен написать свой собственный JavaScript-фреймворк, иначе он недостаточно хорош.

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

Наша общая ошибка - любить эти новые технологии. Когда мы слышим новое красивое слово с «JS» в конце и читаем его небольшое маркетинговое описание, мы готовы приступить к написанию новых проектов с этой «гениальной» штукой. Но правда в том, что маркетинговая чушь и красивое название - единственные преимущества этой новинки, и о ней могут забыть в следующие два месяца. Мы тратим так много времени на изучение новых вещей, чтобы просто забыть о них и разрушить все знания, которые у нас есть, когда снова кто-то в Интернете говорит, что это уже не круто, и есть эта новейшая вещь, которая действительно хороша.

Иногда новые технологии действительно могут быть революционными. Но это еще не повод сразу начинать им пользоваться. Даже революционной технологии нужно время, чтобы «встать на ноги», чтобы получить все необходимые функции и исправить свои первоначальные ошибки. Node.js сначала показался крутым, но если вы решили написать с ним свой проект, у вас было бы гораздо больше проблем, чем если бы вы использовали старый добрый PHP . В то время Node.js не хватало пакетов даже для таких задач, как доставка электронной почты. React - отличное решение, но когда оно было совершенно новым, у него не было устоявшейся основы для работы с данными, и вам приходилось писать его самостоятельно.

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

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

Если по прошествии некоторого времени людям все еще нравится эта обновка, если преимущества все еще очевидны для вас, только тогда пора начинать планировать революцию.

В нужное время и в нужном месте

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

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

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

Как мы уже говорили, вы, как разработчик, должны облегчить жизнь людям. Другими словами, принесите им новую клиентскую ценность . Это может быть выпуск нового продукта или новые удобные функции в уже существующем. И делать это нужно как можно быстрее. Как видите, в таких ограничивающих условиях это может стать серьезной проблемой. И так всегда бывает.

Вы всегда должны быть уверены, что ресурсов вашей компании достаточно, чтобы произвести смену технологий.

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

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

Заключение

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

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

Хакерский полдень - это то, с чего хакеры начинают свои дни. Мы часть семьи @AMI. Сейчас мы принимаем заявки и рады обсудить рекламные и спонсорские возможности.

Если вам понравился этот рассказ, мы рекомендуем прочитать наши Последние технические истории и Современные технические истории. До следующего раза не воспринимайте реалии мира как должное!