Uygulama geliştirmede Boilerplate: nedir, örnekler ve nasıl azaltılır

Boilerplate nedir?

Boilerplate kodu, bir projenin farklı bölümlerinde minimum varyasyonla tekrarlanan kaynak kodu parçalarıdır. Terim matbaacılık sektöründen gelir; burada boilerplate, yeniden yazılması gerekmeyen gazeteler için önceden yazılmış metin bloklarını ifade ediyordu. Programlamada, bir framework, dil veya mimarinin gereksinimlerini karşılamak için tekrar tekrar yazmak zorunda kaldığınız herhangi bir koddur.

Boilerplate klasik anlamda teknik borç değildir — hata içermez ve SOLID ilkelerini ihlal etmez. Ancak bakımı, test edilmesi ve okunması gereken kod miktarını artırır. Boilerplate'in her satırı, derleyicinin her zaman yakalayamayacağı potansiyel bir yazım hatası yeridir.

JetBrains Developer Ecosystem (2025) raporuna göre, geliştiricilerin yüzde 67'si üretkenlik düşüşünün ana nedeni olarak boilerplate'i görmektedir. Mobil geliştirmede bu rakam daha yüksektir: Java'daki Android projeleri, findViewById, Intent, RecyclerView bağdaştırıcıları ve ContentProvider için önemli miktarda şablon kod içerir. Kotlin ve Swift bu sorunların bir kısmını sözdizimsel araçlarla çözdü, ancak boilerplate tamamen ortadan kalkmadı.

Mimari tasarlarken, şablon kodu en aza indiren çözümler seçmeye çalışın. Örneğin, Parcelable uygulamasını manuel yazmak yerine Kotlin'de @Parcelize kullanın. ViewModel için fabrikalar yerine — @HiltViewModel ile Hilt kullanın. Bu tür her optimizasyon, proje ölçeğinde saatlerce geliştirme süresi kazandırır.

Mobil projelerde boilerplate örnekleri

Android geliştirmede boilerplate'in en tanınabilir örneği RecyclerView.Adapter'dır. Kotlin ve ViewBinding'den önce, her bağdaştırıcı yaklaşık 80–100 satır şablon kod gerektiriyordu: onCreateViewHolder, onBindViewHolder, getItemCount, iç ViewHolder sınıfı, yapıcı, alan bağlama. ViewBinding ile kod azaldı, ancak tamamen kaybolmadı.

Optimizasyon olmadan Bağdaştırıcı Boilerplate'i

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)
        }
    }
}

Bir diğer açıklayıcı örnek, kütüphanesiz Java'da JSON eşlemesidir. Bir API yanıtını manuel olarak ayrıştırmak, her biri bir anahtarın varlığını kontrol eden, değeri alan ve bir alana atayan düzinelerce yöntem yazmayı gerektirir. Gson, Moshi veya Kotlin Serialization gibi kütüphanelerle — tek bir @Serializable ek açıklaması yeterlidir.

iOS geliştirmede klasik boilerplate, özellikle JSON anahtarları camelCase özellik adlarından farklı olduğunda, her API yanıtı için CodingKey ve Decodable uygulamasıdır. Codable'ın otomatik oluşturulmasına rağmen, CodingKeys'in manuel olarak listelenmesi hala şablon kod kaynağıdır.

Derleme zamanında boilerplate oluşturmak için kod oluşturmayı kullanın. Android'de — Room, Dagger, Moshi için Annotation Processing (KSP). iOS'te — Codable ve AutoMockable için Sourcery. Oluşturmayı yapılandırmak için harcanan her saat, manuel kopyalama günlerinden tasarruf sağlar.

Şablon kod neden zararlıdır

Boilerplate bir projeye üç şekilde zarar verir: yeni işlevsellik yazmayı yavaşlatır, mevcut kodu okumayı zorlaştırır ve değişiklikler sırasında senkronizasyon bozulma noktaları oluşturur.

Geliştirmedeki yavaşlama açıktır: geliştirici iş mantığı içermeyen kod yazmak için zaman harcar. Yeni bir özellik uygulamak yerine (örneğin, kullanıcı profiline bir alan eklemek), DB geçişi, DTO sınıfı, alan varlığına eşleyici, giriş alanı olan ekran, doğrulama ve her katman için testler yazar. Bu işin çoğu mekaniktir.

Senkronizasyon bozulması daha sinsi bir sorundur. Bir yerde veri yapısı değiştiğinde (örneğin, bir API yanıtına alan eklendiğinde), geliştirici DTO'yu, eşleyiciyi, modeli, ekranı ve testleri güncellemelidir. Bir yer atlanırsa, uygulama derlenir ancak çalışma zamanında çöker veya — daha kötüsü — hata olmadan yanlış veri gösterir. Ne kadar çok boilerplate katmanı varsa, bu tür senkronizasyon bozulması olasılığı o kadar yüksektir.

Projeyi tekrarlayan desenler açısından analiz edin. Farklı adlara sahip üç özdeş sınıf görüyorsanız — bu oluşturma için adaydır. Kod oluşturmayı tek seferlik bir optimizasyon olarak değil, mimari çözümün bir parçası olarak tanıtın. Her yeni modülle kendini amorti eder.

Boilerplate otomasyonu için kod oluşturma

Kod oluşturma, boilerplate ile mücadelede en güvenilir yoldur. Şablon kodu manuel yazmak yerine, geliştirici meta verileri (ek açıklamalar, şemalar, yapılandırmalar) tanımlar ve oluşturucu derleme zamanında hazır kod oluşturur.

Android ekosisteminde standart kod oluşturma aracı KSP'dir (Kotlin Symbol Processing). Eski KAPT'nin yerini alır ve Java stub'ları oluşturmadan Kotlin AST'sine doğrudan erişim sayesinde daha hızlı çalışır. KSP, Room (DAO uygulaması oluşturma), Moshi (JsonAdapter oluşturma), Glide (hedef yükleme sınıfı oluşturma) ve Dagger (DI grafiği oluşturma) tarafından kullanılır.

KSP ile Room Varlık Oluşturma

@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 geliştirmede, kod oluşturma rolünü Sourcery üstlenir — Stencil şablonlarını işleyen ve yorumlardaki ek açıklamalara dayalı olarak Swift kodu oluşturan bir araç. Tipik senaryolar: AutoMockable (testler için mock oluşturma), AutoCodable (CodingKeys olmadan Decodable uygulaması), AutoEquatable ve AutoLenses.

Flutter projeleri için, build_runner aracılığıyla oluşturucular boilerplate'i azaltır: JSON eşlemesi için json_serializable, copyWith ile değişmez modeller için freezed, API istemcileri için retrofit_generator ve DI için injectable_generator. Bu oluşturucuların her biri, 10–20 satır ek açıklamayı yüzlerce satır hazır koda dönüştürür.

Ek açıklamalar ve makrolarla azaltma

Ek açıklamalar ve makrolar, derleyiciye veya ön işlemciye hangi kodun oluşturulacağını söylemenin bildirimsel bir yoludur. Geliştirici uygulamayı yazmaz, sadece niyeti işaretler ve oluşturucu işaretlemeyi hazır koda dönüştürür.

En çarpıcı örnek, Java'da Lombok (tarihsel olarak) ve Kotlin data class'tır. Kotlin'deki data class, equals, hashCode, toString, componentN ve copy'yi otomatik olarak oluşturur — Java'da bunun için yaklaşık 80 satır el yazısı kod veya @Data ile Lombok kullanmak gerekir. Kotlin sorunu dil düzeyinde çözerek boilerplate'i örtük hale getirdi.

Swift'te benzer bir rolü makrolar (Swift 5.9'da tanıtılan Swift Makroları) oynar. Codable uygulamasını manuel yazmak yerine, geliştirici yapıyı @Codable ile işaretler — ve derleyici gerekli kodu oluşturur. Diğer yerleşik makrolar: @Observable (gözlemlenebilir durum), @ResultBuilder (sonuç oluşturucular) ve @MainActor (ana iş parçacığına dağıtım).

@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
// }

Kod oluşturma ve makrolar arasında seçim yaparken, dil destekliyorsa makroları tercih edin. Makrolar derleyici düzeyinde çalışır, derleme betiği yapılandırması gerektirmez, derlemeyi yavaşlatmaz (Annotation Processing'in aksine) ve her zaman kaynak kodla senkronizedir. Makrolar mevcut değilse — KSP, Sourcery veya build_runner aracılığıyla harici oluşturucular kullanın.

Dile özel azaltma pratikleri

Her dil ve platform, boilerplate'i en aza indirmek için kendi araçlarını sunar. Aşağıda ana mobil geliştirme yığınları için belirli pratikler verilmiştir.

Web ön yüzü (React Native / TypeScript) için ana araç, OpenAPI spesifikasyonundan (openapi-typescript, swagger-codegen) tür oluşturmadır. Her uç nokta otomatik olarak tipli bir istek ve yanıt alır — geliştiricinin yüzlerce API çağrısı için arayüzleri manuel olarak tanımlaması gerekmez.

Kod oluşturmayı projenin erken aşamalarında tanıtın. Mevcut bir projeyi oluşturuculara taşımak, onlarla sıfırdan tasarlamaktan daha zordur. Proje zaten yazılmışsa — en acı verici noktadan başlayın: Java → Kotlin (data class), manuel bağdaştırıcılar → DiffUtil ile ListAdapter, manuel JSON eşlemesi → Moshi / Kotlin Serialization.