Hype Driven Development

Команды разработчиков ПО часто принимают решения о программной архитектуре или технологическом стеке, основываясь на ошибочных мнениях из социальных сетей и на всем том, что является скорее модным, чем хорошо изученным, без серьезной оценки возможного влияния на их проекты. Я называю эту тенденцию «Hype Driven Development (HDD)», считаю ее вредной и выступаю за более профессиональный подход. Давайте посмотрим, как обстоят дела, и что мы можем противопоставить.

Новые технологии — новые надежды

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

Источники подобного ажиотажа могут быть разными:

Reddit driven development — заявление известного блоггера или опубликованный материал на таких сайтах, как reddit, hackernews, blogs twitter, Facebook, GitHub и пр.;
Conference driven development — воодушевление после посещения конференции, что на самом деле палка о двух концах: использование новейших, последних библиотек/интерфейсов/технологий без опыта обращения с ними может быть дорогой в ад;
Loudest guy driven decisions — громкая болтовня какого-нибудь парня, который просто не может не говорить о новинке, которая, в конце концов, убедит коллектив в необходимости ее использования;
Gem/lib/plugin driven development — в рамках сообщества Ruby On Rails появляется новый gem, который вы скачивает для устранения проблемы, хотя написание пары строчек кода самим с такой же легкостью решило бы проблему. Но нет, мы лучше добавим библиотеку, плагин, gem и т.п. …;
Stack Overflow driven development — также стоит упомянуть злоупотребление бездумным копированием программистами решений с ресурса Stackoverflow (или вообще из интернета).

HDD — приговор, которые выносят себе программисты

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

Корень зла — средства массовой информации, в которых идея распространяется быстрее, чем ее успевают проверить, быстрее, чем люди успевают понять ее достоинства и недостатки.

Анатомия хайпа

У большинства ажиотажных случаев схожая структура:

Шаг 1: Реальная проблема и решение

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

Шаг 2: Объявление, суета и ключевые слова

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

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

Шаг 3: Помешательство начинается

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

Шаг 4: Разочарование

Несмотря на отчаянные усилия, технология не облегчает людям жизнь, а, наоборот, доставляет много дополнительных забот — огромное количество переписанного кода и потраченного на изучение времени. Работа команда замедляется, управление крайне недовольно. Люди чувствуют себя обманутыми.

Шаг 5: Реализация!

Наконец-то, команда разработчиков, размышляя о прошлом, осознает назначение технологии и в каких случаях она будет наиболее пригодна. Они становятся мудрее… до очередной подобной шумихи.

Примеры хайпа:

Пример 1: React.js

Шаг 1: В Фейсбуке проблема — приложение виснет при большом объеме информации.
Шаг 2: Фейсбук объявляет о новой парадигме, используя модные слова: функциональный, виртуальный DOM, компоненты.
Шаг 3: Мания. Фейсбук создал внешний интерфейс будущего! Давай быстрей писать комментарии!
Шаг 4: Подождите, тут много работы, и не предвидится быстрой отдачи от инвестиций!
Шаг 5: Решение было найдено для продвинутых одностраничных приложений с большим количеством уведомлений в реальном времени, и не обязательно будет подходить для более простых приложений.

Пример 2: TDD мертв из-за DHH

Шаг 1: Девид Хайнмейер Хенсон (David Heinemeier Hansson (DHH), создатель фреймворка Ruby on Rails) объявляет, что сложно совмещать разработку через тестирование (Test-Driven Development, TDD) с Rails, т.к. последний не обладает архитектурой для поддержки правильного объектно-ориентированного программирования. И делает прагматичный выбор — не писать тесты наперед.
Шаг 2: Истерия начинается с поста Хенсона в блоге и выступления на конференции. Теги: TDD МЕРТВ.
Шаг 3: Давайте пропустим тесты! Наш гуру так сказал. Мы все равно их не писали. Теперь и делать вид не будем. Наконец-то, долой лицемерие.
Шаг 4: Подождите! Сейчас работает еще меньше вещей, чем раньше. Мы сделали корявый код.
Шаг 5: «TDD не мертв или жив. TDD — это уступки, включающие риск изменения программного интерфейса приложения, навыков исполнителя и существующего дизайна» — Кент Бек (Kent Beck).

Пример 3: Микро-сервисы

Шаг 1: Сложно оценить масштабируемость большого монолитного приложения. На определенном этапе мы можем разбить его на несколько сервисов. Так будет легче определить их соотношение запросы\сек.
Шаг 2: Ключевые слова ажиотажа: масштабируемость, слабая связанность, монолит.
Шаг 3: Давайте перепишем все и разобьем на сервисы! У нас «спагетти-код», т.к. у нас монолитная архитектура! Нам нужно все расписать по микро-сервисам!
Шаг 4: Черт! Теперь так медленно развивается приложение, так сложно установить и так много времени тратится на поиск ошибок среди разнообразных систем!
Шаг 5: Микро-сервисы требуют высоких навыков, как в разработке, так и в области информационно-технологического обслуживания, и при правильном инвестировании могут в итоге стать более масштабируемыми. Но прежде чем вы достигнете определенного предела, это будут избыточные вложения средств. Микро-сервисы извлекаются, а не пишутся. Вы должны быть вот такой высоты, чтобы использовать микро-сервисы.

Пример 4: NoSQL

Шаг 1: У базы данных SQL проблемы с большим количеством загрузок и не структурированными данными. Команды по всему миру начинают разрабатывать новые поколения баз данных.
Шаг 2: Ключевые слова ажиотажа: масштабируемость, BigData, высокая производительность.
Шаг 3: Наша база данных слишком медленна и не достаточно объемна! Нам нужно NoSQL!
Шаг 4: Нам надо объединять таблицы? Так не пойдет. Простые операции SQL превращаются в сложности. Разработка идет медленно и наши ключевые проблемы не решены.
Шаг 5: Инструменты NoSQL предназначены для решения специфических проблем (огромные объемы данных, не структурируемые данные, большое количество загрузок). SQL на самом деле отличный инструмент и справляется с большим количеством загрузок и большим объемом данных, если им умело пользоваться. Подходящих ситуаций для NoSQL не так уж много на 2016 год.

Пример 5: Elixir и Phoenix (или любая другая ваша любимая пара язык/интерфейс)

Шаг 1: Сетевые фреймворки, такие как Ruby On Rail, на самом деле не предназначены для высоко производительных приложений, распределенных приложений или веб-сокетов.
Шаг 2: Ключевые слова ажиотажа: масштабируемость, высокая производительность, распределенный, отказоустойчивый.
Шаг 3: О боже, наше приложение медленное и наш чат не масштабируемый!
Шаг 4: Ух ты, изучение функционального программирования или распределенного подхода не так уж и просто. Мы сейчас двигаемся очень медленно.
Шаг 5: Elixir и Phoenix хорошо себя зарекомендовали, но нужно немало усилий для того, чтобы освоиться с ними. Это окупится в долгосрочной перспективе, если вам требуется приложение с выдающейся производительностью.

Список примеров бесконечен

В нашем густонаселенном кружке компьютерных разработчиков очень много областей, где ажиотаж — привычное дело. В мире JavaScript каждый день появляются новые фреймворки: Node.js (ключевые слова: событийно-ориентированное программирование), реактивное программирование, Meteor.js (ключевые слова: разделяемые состояния), front-end MVC, React.js. Сами приведите пример. В области разработки программного обеспечения появляются новые архитектуры: проектно-ориентированная разработка (Domain Driven Development), Hexagon, DCI. Какая шумиха вам больше пришлась по душе?

Добросовестная практика

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

Тестируйте и исследуйте, прежде чем принимать решение

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

Когда же?

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

Нанимайте правильных людей:

Серьезная техническая подготовка — ваш друг. Люди, которые знакомы с различными парадигмами, понимают теорию программирования (например, алгоритмы, взаимосовместимость) и отличаются хорошей инженерной культурой, менее подвержены ажиотажу.
Опыт — шумиху любит молодежь. С годами люди, которые видели много разных новых решений и много раз сталкивались с трудностями, более трезво выбирают технологии.

ссылка на оригинал статьи https://habrahabr.ru/post/316668/

Hype Driven Development

Новые технологии — новые надежды