Бойлерплейт в розробці додатків: що це, приклади та як зменшити

Що таке бойлерплейт?

Бойлерплейт (boilerplate code) — це фрагменти вихідного коду, які повторюються в різних частинах проєкту з мінімальними варіаціями. Термін прийшов з друкарської справи, де boilerplate називали заготовки тексту для газет, що не потребували переписування. У програмуванні це будь-який код, який ви змушені писати знову і знову, щоб задовольнити вимогам фреймворку, мови або архітектури.

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

За даними звіту JetBrains Developer Ecosystem (2025), 67 відсотків розробників вважають бойлерплейт основною причиною зниження продуктивності. У мобільній розробці ця цифра вища: Android-проєкти на Java містять значний обсяг шаблонного коду для findViewById, Intent-ів, адаптерів RecyclerView та ContentProvider-ів. Kotlin та Swift вирішили частину цих проблем синтаксичними засобами, але бойлерплейт повністю не зник.

При проєктуванні архітектури намагайтеся вибирати рішення, які мінімізують шаблонний код. Наприклад, замість ручного написання Parcelable-реалізації використовуйте @Parcelize в Kotlin. Замість фабрик для ViewModel — Hilt з @HiltViewModel. Кожна така оптимізація економить години розробки на масштабі проєкту.

Приклади бойлерплейту в мобільних проєктах

Найвідоміший приклад бойлерплейту в Android-розробці — RecyclerView.Adapter. До появи Kotlin та ViewBinding кожен адаптер вимагав близько 80–100 рядків шаблонного коду: onCreateViewHolder, onBindViewHolder, getItemCount, внутрішній клас ViewHolder, конструктор, прив'язка полів. З ViewBinding код скоротився, але повністю не зник.

Бойлерплейт Adapter без оптимізацій

class UserAdapter(
    private val users: List<User>
) : RecyclerView.Adapter<UserAdapter.ViewHolder>() {

    override fun onCreateViewHolder(
        parent: ViewGroup,
        viewType: Int
    ): ViewHolder {
        val view = LayoutInflater
            .from(parent.context)
            .inflate(R.layout.item_user, parent, false)
        return ViewHolder(view)
    }

    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        holder.bind(users[position])
    }

    override fun getItemCount(): Int = users.size

    class ViewHolder(itemView: View) :
        RecyclerView.ViewHolder(itemView) {
        fun bind(user: User) {
            Glide.with(itemView)
                .load(user.avatarUrl)
                .into(itemView.avatar)
        }
    }
}

Інший показовий приклад — JSON-маппінг в Java без бібліотек. Ручний парсинг відповіді API вимагає написання десятків методів, кожен з яких перевіряє наявність ключа, отримує значення та присвоює полю. З бібліотеками на кшталт Gson, Moshi або Kotlin Serialization — це одна анотація @Serializable.

У iOS-розробці класичний бойлерплейт — реалізація CodingKey та Decodable для кожної API-відповіді, особливо коли ключі JSON відрізняються від camelCase-імен властивостей. Незважаючи на автоматичну генерацію Codable, ручне перерахування CodingKeys залишається джерелом шаблонного коду.

Використовуйте кодогенерацію для створення бойлерплейту на етапі збірки. В Android — Annotation Processing (KSP) для Room, Dagger, Moshi. В iOS — Sourcery для Codable та AutoMockable. На кожну годину, витрачену на налаштування генерації, ви економите дні ручного копіювання.

Чим шкідливий шаблонний код

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

Уповільнення розробки очевидне: розробник витрачає час на написання коду, який не містить бізнес-логіки. Замість того щоб реалізувати нову фічу (наприклад, додавання поля в профіль користувача), він пише міграцію БД, DTO-клас, маппер в domain-сутність, екран з полем введення, валідацію та тести на кожен шар. Більша частина цієї роботи — механічна.

Розсинхронізація — більш підступна проблема. Коли в одному місці змінюється структура даних (наприклад, додається поле в API-відповідь), розробник повинен оновити DTO, маппер, модель, екран та тести. Якщо одне з місць пропущено, додаток компілюється, але падає в рантаймі або — що гірше — показує некоректні дані без помилки. Чим більше шарів бойлерплейту, тим вища ймовірність такої розсинхронізації.

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

Кодогенерація для автоматизації бойлерплейту

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

В екосистемі Android стандартний інструмент кодогенерації — KSP (Kotlin Symbol Processing). Він замінює застарілий KAPT і працює швидше за рахунок прямого доступу до Kotlin AST без генерації Java stubs. KSP використовується Room (генерація DAO-імплементацій), Moshi (генерація JsonAdapter), Glide (генерація цільових класів завантаження) та Dagger (генерація DI-графа).

Генерація Room-сутностей з KSP

@Entity(tableName = "users")
data class UserEntity(
    @PrimaryKey val id: Long,
    @ColumnInfo(name = "full_name") val name: String,
    @ColumnInfo(name = "avatar_url") val avatarUrl: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM users WHERE id = :id")
    suspend fun getById(@Param("id") id: Long): UserEntity?
}

У iOS-розробці роль кодогенерації виконує Sourcery — інструмент, який обробляє Stencil-шаблони та генерує Swift-код на основі анотацій у коментарях. Типові сценарії: AutoMockable (генерація моків для тестів), AutoCodable (генерація реалізації Decodable без CodingKeys), AutoEquatable та AutoLenses.

Для Flutter-проєктів бойлерплейт скорочується генераторами через build_runner: json_serializable для маппінгу JSON, freezed для імутабельних моделей з copyWith, retrofit_generator для API-клієнтів та injectable_generator для DI. Кожен з цих генераторів перетворює 10–20 рядків анотацій у сотні рядків готового коду.

Скорочення через анотації та макроси

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

Найяскравіший приклад — Lombok в Java (історично) та Kotlin data class. Data class в Kotlin автоматично генерує equals, hashCode, toString, componentN та copy — на Java для цього потрібно близько 80 рядків коду від руки або використання Lombok з @Data. Kotlin вирішив проблему на рівні мови, зробивши бойлерплейт неявним.

У Swift схожу роль виконують макроси (Swift Macros, що з'явилися в Swift 5.9). Замість того щоб писати реалізацію Codable вручну, розробник позначає структуру @Codable — і компілятор сам генерує необхідний код. Інші вбудовані макроси: @Observable (спостережуваний стан), @ResultBuilder (будівельники результату) та @MainActor (диспетчеризація на головний потік).

@Codable
struct UserProfile {
    let id: Int
    let displayName: String
    let avatarURL: URL
    let bio: String?
}

// @Codable macro generates:
// extension UserProfile: Codable { }
// private enum CodingKeys: String, CodingKey {
//     case id, displayName, avatarURL, bio
// }

При виборі між кодогенерацією та макросами віддавайте перевагу макросам, якщо мова їх підтримує. Макроси працюють на рівні компілятора, не потребують налаштування build-скриптів, не уповільнюють збірку (на відміну від Annotation Processing) і завжди синхронізовані з вихідним кодом. Якщо макроси недоступні — використовуйте зовнішні генератори через KSP, Sourcery або build_runner.

Практики скорочення за мовами

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

Для веб-фронтенду (React Native / TypeScript) основний інструмент — генерація типів з OpenAPI-специфікації (openapi-typescript, swagger-codegen). Кожен ендпоїнт автоматично отримує типізований запит та відповідь — розробнику не потрібно вручну описувати інтерфейси для сотень API-викликів.

Впроваджуйте кодогенерацію на ранніх етапах проєкту. Перенесення існуючого проєкту на генератори складніше, ніж проєктування з їх використанням з нуля. Якщо проєкт вже написаний — починайте з найболючішої точки: Java → Kotlin (data class), ручні адаптери → ListAdapter з DiffUtil, ручний маппінг JSON → Moshi / Kotlin Serialization.