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