Команды разработчиков ПО часто принимают решения о программной архитектуре или технологическом стеке, основываясь на ошибочных мнениях из социальных сетей и на всем том, что является скорее модным, чем хорошо изученным, без серьезной оценки возможного влияния на их проекты. Я называю эту тенденцию «Hype Driven Development (HDD)», считаю ее вредной и выступаю за более профессиональный подход. Давайте посмотрим, как обстоят дела, и что мы можем противопоставить.
Новые технологии — новые надежды
Вы встречались с подобным? Команда выбирает новейшие, самые «горячие» технологии для использования в проекте. Кто-то из них читает пост в блоге, тренд в Твиттере или только что пришел с конференции, на которой говорили великие вещи. И вот уже команда использует эту блестящую технологию (или новую парадигму программной архитектуры), но вместо обещанной большой скорости работы и высокого качества продукта, они получают неприятности. Темп работы замедляется, пропадает мотивация, возникают сложности с выпуском рабочей версии. Некоторые команды застревают на этапе устранения багов вместо того, чтобы добавлять новые функции. Им требуется «еще пара дней, чтобы все подчистить».
Поддержка публикации — компания Edison, которая разрабатывает SDK для слежения за географическими объектами и систему оперативного учета сети магазинов «Мебель для дома».
Hype Driven Development
Источники подобного хайпа могут быть разными:
- 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. Какая шумиха вам больше пришлась по душе?
Добросовестная практика
Если мы не можем полагаться на интернет и мнения других людей, как в таком случае принимать умные решения? Вот вам несколько дельных советов.
Тестируйте и исследуйте, прежде чем принимать решение
- Исследуйте вашу технологию сами, а не читайте про нее в блогах. Уделите день или два прототипу новой технологии, прежде чем делать окончательный выбор. Пусть команда проанализирует все «за» и «против». Или используйте только пару конкурентоспособных технологий, а остальные пусть тестируются вашими программистами.
- Проведите хакатон, это отличный способ настроить вашу команду на осторожность при внедрении новых технологий. Пусть в течение одного или двух дней они поработают с новыми на сегодняшний день технологиями и отберут наиболее обещающие. Их решения будут более взвешенными, т.к. будут основаны на их собственном опыте.
Когда же?
- В принципе, когда отдача от вложений значительна. Большинство технологий созданы для решения конкретных задач. У вас есть эта проблема? Сэкономит ли это решение вам время? Использование технологии окупит работу по ее внедрению и связанные с этим трудности? Что если работа в итоге станет медленней в два раза? Или в четыре? Оно все еще того стоит?
- Отличным командам программистов больше позволено — некоторые команды просто быстрее других начинают приносить выгоду. Им становится скучно работать с тем, что получается легко. Эти команды могут чаще представлять новые технологии. Это не оправдание не использовать хакатоны и серьезно не анализировать новые предложения. С другой стороны, если у команды проблемы с выполнением работы — будьте осторожны с новыми технологиями.
Нанимайте правильных людей:
- Серьезная техническая подготовка — ваш друг. Люди, которые знакомы с различными парадигмами, понимают теорию программирования (например, алгоритмы, взаимосовместимость) и отличаются хорошей инженерной культурой, менее подвержены хайпу.
- Опыт — шумиху любит молодежь. С годами люди, которые видели много разных новых решений и много раз сталкивались с трудностями, более трезво выбирают технологии.
Автор: Edison
