Hype Driven Development

image

Команди розробників ПЗ часто приймають рішення про програмної архітектури або технологічному стеку, грунтуючись на помилкових думках з соціальних мереж і на всьому тому, що є скоріше модним, ніж добре вивченим, без серйозної оцінки можливого впливу на їхні проекти. Я називаю цю тенденцію «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 — вирок, які виносять собі програмісти
Проблема в тому, що в стані афекту приймаються погані рішення. І наслідки можуть переслідувати команду розробників місяцями і навіть роками. У гіршому випадку вони приведуть до Тотальної редакції. Яка майже ніколи не вдається.

Корінь зла — засоби масової інформації, в яких ідея поширюється швидше, ніж її встигають перевірити, швидше, ніж люди встигають зрозуміти її переваги і недоліки.

Анатомія хайпи
У більшості хайпів схожа структура:

image

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

Крок 2: Оголошення, суєта і ключові слова
Команда з хвилюванням чекаємо нагоди показати свою роботу всьому світу, і ось вони вже пишуть в блогах і виступають на конференціях. Найчастіше вирішена проблема була нетривіальною, тому вони відчувають гордість, описуючи знайдене ними нетривіальне рішення. Публіка із захопленням дізнається про нову технологію. Однак захоплення аудиторії не має на увазі, що всі її члени до кінця розуміють, у чому саме була проблема чи не вникають у деталі розв'язку.

Адже все-таки це була нестандартна завдання з нестандартним рішенням. І для роз'яснення потрібно трохи більше ніж твіт, пара рядків в чаті або навіть пост в блозі. В сучасних засобах масової інформації суть повідомлення може легко стати нечіткою та розмитою у міру її поширення.

Крок 3: Божевілля починається
Незабаром після того, як новина пройшла по блогах і конференцій, розробники по всьому світу починають знайомитися з новою технологією. І деякі з них з-за розмитості інформації приймають поспішне рішення використовувати описану технологію, навіть якщо вона і не здатна вирішити жодну з їх поточних проблем. Але вони в неї вірять.

image

Крок 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. Яка галас вам більше припала до душі?

Добросовісна практика
Якщо ми не можемо покладатися на інтернет і думки інших людей, як в такому випадку приймати розумні рішення? Ось вам кілька слушних порад.

Тестуйте і дослідіть, перш ніж приймати рішення
  • Дослідіть вашу технологію самі, а не читати про неї в блогах. Приділіть день або два прототипу нової технології, перш ніж робити остаточний вибір. Нехай команда проаналізує всі «за» і «проти». Або використовуйте тільки пару конкурентоспроможних технологій, а інші нехай тестуються вашими програмістами.
  • Проведіть хакатон, це відмінний спосіб налаштувати вашу команду на обережність при впровадженні нових технологій. Нехай протягом одного або двох днів вони попрацюють з новими на сьогоднішній день технологіями і відберуть найбільш обіцяють. Їх рішення будуть більш зваженими, т. к. будуть засновані на їх власному досвіді.


Коли ж?
  • В принципі, коли віддача від вкладень значна. Більшість технологій створені для рішення конкретних завдань. У вас є ця проблема? Заощадить це рішення вам час? Використання технології окупить роботу по її впровадженню та пов'язані з цим труднощі? Якщо робота в підсумку стане повільніше в два рази? Чи чотири? Воно все ще того варто?
  • Відмінним командам програмістів більше дозволено — деякі команди просто швидше за інших починають приносити вигоду. Їм стає нудно працювати з тим, що виходить легко. Ці команди можуть частіше представляти нові технології. Це не виправдання не використовувати хакатони і серйозно не аналізувати нові пропозиції. З іншого боку, якщо у команди проблеми з виконанням роботи — будьте обережні з новими технологіями.


Наймайте правильних людей:
  • Серйозна технічна підготовка — ваш друг. Люди, які знайомі з різними парадигмами, розуміють теорію програмування (наприклад, алгоритми, взаємосумісність) і відрізняються гарною інженерної культурою, менше схильні хайпи.
  • Досвід — галас любить молодь. З роками люди, які бачили багато різних нових рішень і багато разів стикалися з труднощами, більш тверезо вибирають технології.
image
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.