Перевод одноименной статьи Marek Kirejczyk из daftcode.pl.
Команды разработчиков программного обеспечения часто принимают решения о программной архитектуре или базовом технологическом стеке на основе спорных мнений из социальных медиа, да и в целом выбирая то, что считается «горяченьким», вместо того, чтобы провести скрупулезное исследование и серьезно рассмотреть возможный эффект от их применения на своих проектах. Я называю эту тенденцию Hype Driven Development (прим. разработка управляемая беззастенчивой рекламой или обманом, но обман… в общем я склонен считать что хайп это хайп, но в переводе иногда буду использовать другие слова), считаю ее вредной и выступаю за более профессиональный подход, который называю «Solid Software Enginering». Приглашаю узнать больше о том, как это работает, и выяснить, что можно сделать вместо этого [HDD].
Новая технология — новая надежда
Сталкивались с этим? Команда выбирает новейшие, самые горячие технологии, чтобы использовать их в своем проекте. Кто-то читает сообщения в блогах, кто-то видит в трендах на Twitter, а еще мы только что вернулись с конференции, на которой много говорили о новой технологии. Вскоре после того, как команда начинает использовать эту восхитительную новейшую технологию, можно наблюдать неожиданный эффект. Вместо того, чтобы решать задачи быстрее (как и обещалось) и создавать более совершенный продукт они сталкиваются с проблемами. Они замедляются, теряют мотивацию. Возникают новые проблемы, которые делают сложным или невозможным поставку следующей версии. Некоторые команды продолжают исправлять ошибки, вместо того, чтобы работать над новыми возможностями. Им нужно «просто еще несколько дней», чтобы все разобрать.
Hype Driven Development
Hype Driven Development (HDD) имеет множество оттенков и может коснуться вашего проекта по-разному:
Reddit Driven Development — когда команда или кто-то конкретный принимает решение по технологии / архитектуре / дизайну, основываясь на том, что об этом написал популярный блоггер, или это очень жарко обсуждается на Reddit, hackernews, Twitter, facebook, GitHub или других социальных медиа.
Conference Driven Development — присмотритесь к тому, что происходит после того, как люди вернулись с конференции. Люди вдохновляются. И это палка о двух концах. Переходя на новейшие «горячие» библиотеки/фреймворки/архитектурные парадигмы без должного их исследования можно попасть прямиком на шоссе из песни AC/DC (прим. Highway to hell).
Хотя зачастую можно встретить и обратный вариант, когда люди много ходят на различные курсы, тренинги и прочее, но в итоге не используют ничего… по этому поводу мне нравится следующее изображение.
Loudest guy driven decisions — это когда у нас есть один парень, который все время говорит об этой клевой новой штуке, в которой у него нет никакого опыта, но говорит он безостановочно и в итоге команда принимает решение использовать её.
Gem/lib/plugin driven development — особенно сильна в комьюнити Ruby On Rails, где время от времени я могу встретить такой длинный Gemfile, что длиннее будет только загрузка приложения. Это явление происходит от идем о том, что каждая проблема в Rail должна быть решена с помощью gem’а. Иногда самостоятельное решение стоило бы всего нескольких строк кода. Но мы просто решаем проблемы добавлением библиотек, плагинов, гемов или фреймфорков.
Что-то похожее встречается при работе со сборщиками в «новых» концепциях asp.net и т.п. В общем подобную историю можно встретить довольно часто, а временами, кроме прочего еще и наткнуться на Dependency Hell, в общем путей в ад много.
И, пожалуй, я хотел бы упомянуть здесь поведение, популярное среди HDD-разработчиков — Stack Overflow driven development — когда разработчики копипастят решения со Stackoverflow (или в принципе откуда-то с просторов интернета) без реального понимания их сути.
HDD это о том, как команды несут погибель сами себе
Проблема хайпа в том, что он легко приводит к неверным решениям. Плохие архитектурные решения или неудачный выбор технологического стека зачастую преследуют команду месяцами или даже годами. А в самом худшем случае они могут привести к другой весьма проблематичной ситуации: The Big Rewrite. Что практически никогда не помогает.
Корнем всех зол, видятся, социальные медиа — где новые идеи распространяются гораздо быстрее, чем они тестируются и гораздо быстрее, чем люди в состоянии оценить их плюсы и минусы.
Анатомия обмана
Большая часть хайпа имеет сходую структуру. Она на картинке:
Шаг 1: Реальная проблема и решение
Все начинается в какой-то компании с проблемой. Команда этой компании решает, что технологическое решение проблемы выходит за рамки текущего стека, процесса или архитектуры. Команда создает новые фреймворки, библиотеки или парадигмы, и вскоре проблема решена.
Шаг 2: Презентация, шумиха и «ключевые слова»
Команда воодушевлена и готова продемонстрировать свою работу всему миру. Вскоре пишется сообщение в блоге и начинаются выступления на конференциях. Проблема часто является нетривиальной, поэтому команда с гордостью представляет свои впечатляющие результаты нетривиального решения. Люди заинтересованы новой технологией. Единственная проблема, не каждый заинтересованный способен в полной мере понять какая именно проблема была решена и тем более все детали ее решения, но все слышат ключевые слова в сообщении. В конце-концов это было нетривиальным решением нетривиальной задачи, объяснение которого требует больше, чем твит, сообщение в блоге или чат. И, вот, проходя долгий путь из различных средств коммуникаций: социальных медиа, сообщений в блогах, твитов, конференции и быстрых переговоров основной посыл размывается.
Шаг 3: Мания
В ход идут все формы HDD: чтение блогов, посещение конференций. Вскоре команды по всему миру начинают изучать новую технологию. Из-за размытости посыла некоторые из них делают поспешное решение использовать фреймворк, даже если он в действительности не решает актуальные для них проблемы. Тем не менее у команды есть надежда, что новая технология все таки им поможет.
прим. Я лично неоднократно сталкивался с подобным. А вы?
Шаг 4: Разочарование
По мере того как спринты (прим. речь идет о кратких временных интервалах планирования в рамках гибких подходов в разработке ПО) идут, приходит понимание, что технология не улучшает жизнь команды настолько, насколько ожидалось, зато добавляет много дополнительной работы. Очень много кода, который требуется переписать, и дополнительного обучения для команды. Команда замедляется, менеджмент злится, все чувствуют себя обманутыми.
Шаг 5: Осознание!
Наконец, команда делает ретроспективу и понимает, что именно несет новая технология и с какой целью ее использование было бы более уместным. Они становятся мудрее … ну, по крайней мере до следующего хайпа. ^_^
Примеры хайпов:
Давайте исследуем некоторые примеры хайпов и посмотрим как это было.
Пример 1: React.js
Шаг 1: У Facebook была проблема — сложные одностраничные веб-приложения, каким является Facebook, имеют множество различных событий изменяющих состояние в следствии чего становится сложно отслеживать происходящее и последовательно изменять состояние.
Шаг 2: Facebook представил новую парадигму с шумихой вокруг ключевых слов: functional, virtual DOM, components.
Шаг 3: Мания: Facebook создал фреймворк переднего-конца будущего (прим. простите, «front-end framework»)! Давайте всё писать на React!
Шаг 4: Погодите ка, работы много, но возврат инвестиций совсем не быстрый.
Шаг 5: React отлично подходит для продвинутых одностраничных приложений с большим количеством изменений/уведомлений в режиме реального времени странице, но не обязательно окупится для простых приложений.
Пример 2: TDD мертв благодаря DHH
Шаг 1: David Heinemeier Hansson (DHH, создатель фремворка Ruby on Rails) осознает что трудно использовать TDD с Rails поскольку этот фреймворк не поддерживает в должной мере OOP. Делает прагматичный выбор — не писать тестов заранее.
Шаг 2: Хайп начинается с сообщения в блоге DHH blog post и разговора на конференции conference talk. Ключевые слова: TDD мертв.
Шаг 3: Давайте пропустим тесты. Наш Гуру так сказал. Мы все равно их не писали, теперь мы по крайней мере не делаем вид, мы наконец-то честны.
Шаг 4: Подождите! Намного меньше вещей стало работать по сравнению с тем что было раньше. Мы написали какой-то очень глючный код!
Шаг 5: “TDD не жив или мертв. TDD зависит от принимаемых компромиссов, например риск изменения API, навыки участников и существующий дизайн” — Кент Бек.
Пример 3: Микросервисы
Шаг 1: Большие монолитные приложение сложно масштабируемы. Вот почему наступает момент когда мы разбиваем их на сервисы. Так будет легче масштабировать с точки зрения количества запросов в секунду и разделения зоны ответственности между несколькими командами.
Шаг 2: Ключевые слова: масштабируемость, слабосвязность, монолит.
Шаг 3: Давайте перепишем все на сервисы! У нас тут «спагетти код» потому что у нас монолитная архитектура! Мы должны переписать все на микросервисы!
Шаг 4: Дерьмо! Теперь мы разрабатываем медленнее, у нас сложности с развертыванием и мы тратим массу времени на отслеживание багов между несколькими системами.
Шаг 5: Микросервисы требуют серьезных навыков DevOps у команды и с правильными подходом могут окупиться как вариант масштабирования система и команды. Пока вас не коснулись серьезные проблемы масштабируемости использовать такой подход — лишние издержки. Микросервисы извлекаются, а не пишутся.
Пример 4: NoSQL
Шаг 1: SQL базы данных имеют большие проблемы с высокой загрузкой и неструктурированными данными. Команды по всему миру начинают разрабатывать новое поколение баз данных.
Шаг 2: Ключевые слова: масштабируемость, BigData, высокая производительность.
Шаг 3: Наши базы данных слишком медленным и не недостаточно вместительны! Нам нужен NoSql!
Шаг 4: Нам нужно связать таблицы? Ну нет. Простые SQL операции становятся все более сложными. Разработка замедляется, а ключевые проблемы так и не решены.
Шаг 5: NoSql это иструмент для решения очень специфичных проблем (чрезвычайно большие объемы данных, неструктурированные данные или очень высокая нагрузка). SQL на самом деле является отличным инструментом и справляется с высокой нагрузкой и огромными объемам данных, если его использовать с умом. Варианты для NoSQL по прежнему крайне редки в 2016 году.
Пример 5: Elixir and Phoenix (или поставьте сюда пару своих любимых языков/фреймворков)
Шаг 1: Веб-фреймворки типа Ruby On Rails плохо справляются в случаях когда нужно иметь дело с высоконагруженными приложениями, распределенными приложениями или веб-сокетами.
Шаг 2: Ключевые слова: масштабирумость, высоконагруженные, распределенные, отказоустойчивость.
Шаг 3: О, мой хороший, (прим. я почти уверен, что у автора опечатки и он имел ввиду О боже мой!) наше приложение медленное и наш чат не масштабируется!
Шаг 4: Ничего себе, изучение функционального программирования и распределенного подхода не так просто. Мы двигаемся очень медленно.
Шаг 5: Эликсир и Феникс великолепные фреймворки, но требует значительных усилий на изучение. Они окупаются в долгосрочной перспективе, если вам нужно дейтвительно специфическое высоконагруженное приложение.
Можно продолжать и продолжать:
В JavaScript новые фреймворки рождаются каждый день. Node.js (ключевые слова: программирование событий), реактивное программирование, Meteor.js (ключевые слова: shared state), передний конец MVC, React.js. В программной инженерии рождаются новые архитектуры: Domain Driven Development, Hexagon, DCI. А какой хайп предпочитаете вы?
Хорошие практики
Итак, если не стоит полагаться на мнения высказанные другими людьми в интернетах, то как принять разумное решение? Здесь несколько хороших практик:
Тестируй и исследуй до принятия решения:
- Spikes — узнавайте интересующую вас технологию не из блогов, а лично, на своем опыте. Возьмите пару дней, чтобы создать прототип новой функциональности в новой технологии, прежде чем принять решение. Пусть команда проанализирует плюсы и минусы. Возьмите несколько конкурирующих технологий и пусть разные части команды создают свои прототипы.
- Hackathon — отличный способ для повышения уровня информированности команды о разных технологиях. Выберите пару дней для всей команды, чтобы пощупать все технологии, которые находятся на подъеме и заманчиво выглядят для использования. Это позволит членам команды сделать своё осознанное решение.
Когда?
- В принципе, когда ожидается значительная отдача от инвестиций. Большинство технологий создаются для решения конкретной задачи. Есть ли проблема? Это большая проблема? Будет ли сэкономлено много времени? Окупится ли использование новой технологии с учетом входа в нее и переписывания кода? Что делать, если мы изначально замедлились в два раза? А если четыре? Является ли она по-прежнему стоящей?
- Великим командам разрешено больше — некоторые команды просто быстрее чем другие приносят ценность. Им становится скучно с тем, что им дается очень легко. Эти команды могут внедрять новые технологии все чаще. Это не повод, чтобы не использовать Spikes и не делать Хакатоны. С другой стороны, если у команды есть проблемы — действовать с осторожностью.
Нанимайте на работу правильных людей:
- Сильный технический бэкграунд это ваш друг — люди знающие различные парадигмы, понимающие теорию программирования (алгоритмы, параллелизм) и имеющие хорошую инженерную культуру, как правило, меньше подвержены хайпу.
- Опыт — хайп сильнее у молодых разработчиков. С годами, люди, видевшие много технологий и сталкивавшиеся с трудностями много раз более рассудительно подходят к выбору технологий.Ну и конечно, ссылка на первоисточник для страждущих оригинал.
Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.
Уведомление: Используем HTTPS насильно | Дмитрий [KP0H] Пелевин
Уведомление: Используем HTTPS | Дмитрий [KP0H] Пелевин