بویلرپلیت در توسعه برنامه‌ها: چیست، مصادیق و چگونه آن را کاهش دهیم

بویلرپلیت چیست؟

بویلرپلیت (کد قالبی) — بخش‌هایی از کد مبدا هستند که در بخش‌های مختلف پروژه با تغییرات حداقل تکرار می‌شوند. این اصطلاح از صنعت چاپ آمده است، جایی که بویلرپلیت متون از پیش تهیه‌شده برای روزنامه‌ها بود که نیازی به بازنویسی نداشتند. در برنامه‌نویسی، این هر کدی است که مجبورید بارها بنویسید تا نیازهای فریم‌ورک، زبان یا معماری را برآورده کنید.

بویلرپلیت به معنای کلاسیک بدهی فنی نیست — حاوی خطا نیست و اصول 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 کد کوتاه‌تر شد، اما کاملاً ناپدید نشد.

بویلرپلیت آداپتر بدون بهینه‌سازی

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، مپر به نهاد دامنه، صفحه با فیلد ورودی، اعتبارسنجی و آزمایش برای هر لایه را می‌نویسد. بخش بزرگی از این کار مکانیکی است.

ناهمگامی مشکل پیچیده‌تری است. وقتی ساختار داده در یک جا تغییر می‌کند (مثل افزودن فیلد به پاسخ API)، توسعه‌دهنده باید DTO، مپر، مدل، صفحه و آزمایش‌ها را به‌روز کند. اگر یکی از جاها از قلم بیفتد، برنامه کامپایل می‌شود اما در زمان اجرا سقوط می‌کند یا — بدتر از آن — داده‌های نادرست را بدون خطا نشان می‌دهد. هر چه لایه‌های بویلرپلیت بیشتر باشند، احتمال چنین ناهمگامی بیشتر است.

پروژه را از نظر الگوهای تکراری تحلیل کنید. اگر سه کلاس یکسان با نام‌های مختلف می‌بینید — این کاندیدای تولید کد است. تولید کد را به عنوان بخشی از تصمیم معماری پیاده کنید، نه به عنوان بهینه‌سازی مالی. این کار در هر ماژول جدید به صرفه است.

تولید کد برای اتوماتیسازیون بویلرپلیت

تولید کد — قابل اعتمادترین راه مبارزه با بویلرپلیت است. به جای نوشتن دستی کد قالبی، توسعه‌دهنده فراداداده (حواشی‌ها، شمات‌ها، پیکربندی‌ها) را توصیف می‌کند و تولیدکننده کد آماده را در مرحله کامپایل ایجاد می‌کند.

در اکوسیستم Android ابزار استاندارد تولید کد KSP است (Kotlin Symbol Processing). آن جایگزین KAPT کهنه شده است و با دسترسی مستقیم به AST Kotlin بدون ایجاد 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. هر کدام از این تولیدکننده‌ها ده تا بیست خط حواشی را به صدها خط کد آماده تبدیل می‌کند.

کاهش از طریق حواشی‌نویسی و کلان‌نماها

حواشی‌نویسی و کلان‌نماها راهی اعلامی برای نشان دادن به کامپایلر یا پیش‌پردازنده است که چه کدی باید تولید شود. توسعه‌دهنده پیاده‌سازی را نمی‌نویسد، فقط نیت را علامت‌گذاری می‌کند، و تولیدکننده علامت‌ها را به کد آماده تبدیل می‌کند.

بهترین مثال — 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 تولید می‌کند:
// extension UserProfile: Codable { }
// private enum CodingKeys: String, CodingKey {
//     case id, displayName, avatarURL, bio
// }

هنگام انتخاب بین تولید کد و کلان‌نماها، اگر زبان آنها را پشتیبانی می‌کند، کلان‌نماها را ترجیح دهید. کلان‌نماها در سطح کامپایلر کار می‌کنند، نیازی به راه‌اندازی build-skript ندارند، کامپایل را کند نمی‌کنند (بر خلاف Annotation Processing) و همیشه با کد مبدا همگام هستند. اگر کلان‌نماها در دسترس نیستند — از تولیدکننده‌های خارجی از طریق KSP، Sourcery یا build_runner استفاده کنید.

روش‌های کاهش بر اساس زبان‌ها

هر زبان و پلتفرم ابزارهای خود را برای کاهش بویلرپلیت ارائه می‌دهند. در زیر روش‌های مشخص برای انبارهای اصلی توسعه موبایل آورده شده است.

برای فرونتند وب (React Native / TypeScript) ابزار اصلی تولید انواع از مشخصات OpenAPI است (openapi-typescript، swagger-codegen). هر endpoint به طور خودکار درخواست و پاسخ تایپ‌شده دریافت می‌کند — توسعه‌دهنده نیازی به توصیف دستی انترفیس‌ها برای صدها تماس با API ندارد.

تولید کد را در مراحل اولیه پروژه پیاده کنید. انتقال پروژه موجود به تولیدکننده‌ها از طراحی از پایه با آنها دشوارتر است. اگر پروژه قبلاً نوشته شده است — از داغ‌ترین نقطه شروع کنید: Java → Kotlin (data class)، آداپترهای دستی → ListAdapter با DiffUtil، نقشه‌برداری دستی JSON → Moshi / Kotlin Serialization.