Як підходити до створення складного продукту: 3 ради розробникам



Ми в «Латере» вже багато років займаємося розробкою білінгу для операторів зв'язку і розвиваємо сервіс для управління виїзними працівниками «Планадо».

Білінг — це складний продукт, робота над яким має свої особливості. По-перше, це вузькоспеціалізований інструмент enterprise-рівня, який впроваджується сотнями екземплярів, а не десятками і сотнями тисяч. По-друге, система повинна працювати в режимі 24x7x365. І найголовніше — саме біллінг рахує гроші, а значить це критично важливий елемент інфраструктури будь-якої компанії.

У наших попередніх статтях ми розповідали про те, як організувати техпідтримку подібної системи і чому краще довірити ее впровадження професіоналам. Сьогодні ж мова піде про підходи, які слід застосовувати в процесі розробки.

Відразу думайте про майбутніх доробках

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

Ілюстрація з близькою нам сфери телекомунікацій — різні оператори вимагають різних можливостей білінгу. Свої особливості телеком-галузі можуть бути в різних регіонах — наприклад, в Норильську і Магадані немає дротових каналів зв'язку, доступний тільки супутник. Тому доступ в інтернет тут дуже дорогий і до цих пір в ходу тарифи з квотами трафіку. Така ж ситуація в деяких країнах Центральної Азії (наприклад, Афганістан) і Африки (Нігерія).

Може мати значення і розмір абонентської бази — процеси невеликого і федерального провайдера будуються по-різному.

Все це означає, що створити систему, яка б задовольняла всі можливі побажання замовників, неможливо. Але можна передбачити напрями, в яких майбутні користувачі можуть захотіти доопрацювати продукт.

Якщо це зробити ще на етапі проектування, ви уникнете багатьох проблем. При цьому зовсім не обов'язково реалізовувати усі закладені в архітектурі можливості — важливо щоб потім їх можна було впровадити малою кров'ю і без «милиць».

Головний секрет того, як уникнути таких помилок, простий — треба серйозно проаналізувати предметну область, перш ніж зробити якісь дії. Приміром, ми в «Латере» у разі необхідності якихось великих доопрацювань витрачаємо до 20% часу на спілкування з клієнтами, занурення в їх бізнес-завдання, вивчення загальноприйнятої практики та розробку вимог до функціональності. Якщо ж обмежувати доопрацювання тільки тим, що потрібно конкретному замовнику, для інших вона буде марною. А для серійного програмного продукту це гарантовані збитки.

Не намагайтеся осягнути неосяжне

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

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

Проблема тут у тому, що за час роботи з самописною системою — а це зазвичай роки — співробітники компанії і її керівники звикають до неоптимальних рішень. І потім вони хочуть бачити ті ж «милиці» у новому продукті. Впроваджувати їх-означає руйнувати архітектуру системи, робити її менш стабільною і ускладнювати підтримку та впровадження.

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

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

Будьте готові до багаторазового переписування коду

Якісні архітектурні рішення гарні своєю стабільною роботою і тим, що економлять час і ресурси на підтримку і експлуатацію продукту. Однак у випадку складного продукту рідко вдається все зробити правильно відразу — напевно якісь елементи системи будуть працювати неоптимально, і з цим доведеться щось робити.

Зрозуміти, де саме необхідні доопрацювання, може бути дуже нелегко. Приклад такої ситуації — розробка функціональності системних подій нашого білінгу «Гідра». Під такими подіями мається на увазі якась зміна важливих параметрів, що вимагає від системи певних дій, наприклад, при зниженні залишку коштів на рахунку до нуля, абоненту слід відключити доступ до послуги. Очевидно, що подія в даному випадку має нести в собі якусь інформацію про абонента, наприклад, його ідентифікатор, MAC-адреса і т. п. Все це здавалося правильним і логічним на етапі проектування, однак потім почалися проблеми. Наприклад, при певному збігу обставин система відпрацьовувала не так, як очікувалося в предметній області: хтось поміняв код послуги, а він використовувався в команді на підключення доступу, повинні пересоздаться події по всім абонентам?

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

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

Висновок

При роботі зі складними системами, до яких відноситься і біллінг, зробити все правильно раз і назавжди неможливо. Однак дотримання декількох простих правил знижує число можливих проблем і полегшує роботу з продуктом в майбутньому.

Інші статті по темі ІТ-інфраструктури від команди «Латеры»:
Джерело: Хабрахабр

0 коментарів

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