Як ми розробили чат-фреймворк для Android, додатки — Chateau

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


Зрозуміло, Badoo не залишається в стороні від цих тенденцій. Ми постійно вдосконалюємо свій чат і розширюємо його функціональність, але можливості існуючої кодової бази та архітектури ледве встигають за вимогами сучасності. Колись впорядкований і добре протестований код розростається непередбачуваним чином, накопичуючи «технічний борг». Аналізуючи шляхи вирішення цієї проблеми, ми зіткнулися з дилемою, яка знайома кожному розробнику: переписати код або зробити рефакторинг?

В кінцевому підсумку ми вирішили, що краще все-таки його переписати. Такий вибір був обумовлений наступними причинами:
Значний успіх Chatto (фреймворк чату Badoo для iOS) допоміг нам зрозуміти, чого ми можемо досягти.
З моменту розробки кодової бази нашого чату з'явилися і набрали популярність кілька архітектурних концепцій для Android, і деякі з них допомогли б нам значно спростити код.
Наша прихильність концепції відкритого вихідного коду. Ми завжди прагнули брати участь в таких проектах і самі виступали ініціаторами розробки рішень з відкритим вихідним кодом. Крім того, у нас був шанс зайняти практично вільну нішу для Android.
Але це був лише початок великого шляху, лишалося ще багато питань. Яку архітектуру ми хочемо створити? Як, коли і який саме код ми зробимо відкритим? Якихось конкретних результатів ми хочемо досягти?

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

  • Легкість розширення. Необхідно максимально спростити додавання нових функцій (наприклад, підтримку файлів GIF, стікерів, голосових повідомлень) і зробити так, щоб їх додавання не впливало на інші функції чату.
  • Легкість інтеграції. Необхідно забезпечити просту інтеграцію фреймворку в додатки, незалежно від типу використовуваної архітектури або серверної платформи.
  • Легкість розуміння. Код повинен бути простим і зрозумілим, щоб у ньому міг розібратися чоловік, який не є членом нашої команди розробників.
  • Легкість тестування. Чат передбачає різні складні функції взаємодії користувачів і, як наслідок, тут є широкий простір для потенційних помилок. Щоб забезпечити можливість рефакторінгу і розширення кодової бази, необхідно максимально спростити тестування (як модульне, так і інтеграційне).
  • Висока продуктивність. У фреймворку не повинні використовуватися абстракції або шаблони, які помітно знижують продуктивність.
Щоб вирішити поставлені завдання, потрібно було підібрати інструменти і оптимальну архітектуру…

Оптимальна архітектура для Chateau
Сам фреймворк Chateau був написаний з нуля, проте в його архітектурі використовувався багаторічний досвід написання компонентів і функцій чату Badoo.

Оскільки в інших своїх додатках ми вже використали шаблон проектування MVP (Model-View-Presenter) і він дозволив нам створити добре протестований код, це був природний вибір для Chateau. Звичайно, не всі реалізації шаблону MVP однакові, і нам потрібно було вибрати один з безлічі існуючих варіантів. Детальніше про це можна прочитати в нашій документації.

Ще одним елементом мозаїки стала концепція Clean Architecture («чиста архітектура»), запропонована Робертом Мартіном (Robert C. Martin), який також відомий як @unclebobmartin. Згідно з цією концепцією ми ділимо програму на кілька шарів, і для всіх взаємодій між шарами повинне дотримуватися правило залежностей». Залежно в коді завжди повинні йти зверху вниз (у нашому випадку верхні шари — це користувальницький інтерфейс, і зверху вниз ми проходимо через шари уявлень (View), «презентеров» (Presenter), сценаріїв використання (Use case) і сховищ/джерел даних).

Переваги концепції Clean Architecture для нас були аналогічні перевагам концепції MVP, реалізованої на верхніх рівнях додатки. Завдяки цьому ми змогли створити незалежні компоненти, які можуть бути протестовані окремо з використанням швидких модульних тестів замість тестів на платформі Android. Крім того, такий підхід дозволив зробити фреймворк Chateau повністю модульним, що дозволяє використовувати інше сховище даних, інтерфейс або альтернативну реалізацію мережевого коду.

Чого ми навчилися
Розробка Chateau була дуже захоплюючою (до речі, ми ще не закінчили!) і веселою. В процесі роботи ми сміялися, плакали і набивали гулі. Ось деякі з витягнутих уроків:

  • Нелегко знайти золоту середину між двома крайнощами — повнофункціональним чатом (з інтерфейсом, кешування і мережевим кодом) і платформою, яку можна було б використовувати в якості основи для власного чату. Звичайно, здорово створити щось відразу готовий до використання, але все ж не можна забувати про можливість повної заміни окремих модулів (наприклад, користувальницького інтерфейсу або мережевого рівня). Ми вирішили створити зразок програми для Chateau, щоб показати, яким ми уявляємо собі повнофункціональний чат;
  • Вивчати бібліотеку RxJava безпосередньо в процесі розробки фреймворку, в якому вона використовується, — завдання не з легких. Крім того, в нашому випадку це призвело до більш частого рефакторінгу (ще один відмінний привід для того, щоб забезпечити хороше покриття коду);
  • Створення бібліотеки та варіанти її використання краще спланувати заздалегідь, щоб переконатися, що процес розробки відповідає як внутрішнім, так і зовнішнім потребам. Ми хотіли поширювати бібліотеки через jCenter, а також включати їх як звичайну залежність Gradle-проекту при створенні наших додатків (для спрощення крос-модульного рефакторінгу). Крім того, за допомогою git subrepo ми зробили так, щоб бібліотеки Chateau відображалися у вигляді окремої папки основного git.


Що далі?
Поки що у фреймворку Chateau реалізовані не всі функціональні можливості (наприклад, варіанти реалізації користувальницького інтерфейсу і уявлень, а також підтримка певних серверних платформ). Ці функції необхідно додати або реалізувати в самому додатку, в якому використовується Chateau. В майбутньому ми плануємо скоротити обсяг коду, необхідного для повної інтеграції з Chateau. В ідеалі ми хотіли б забезпечити максимальну універсальність Chateau — за умови сумісності з серверною платформою, звичайно.
Ми також працюємо над створенням оптимального макета або платформи для тестування, які можна використовувати з зразком додатка. Слідкуйте за новинами у нашому блозі на Хабре, а також на сторінці проекту GitHub.
Джерело: Хабрахабр

0 коментарів

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