Boilerplate چطور سرعت توسعه وب را افزایش می‌دهد؟

در پروژه‌ای که برای یک استارتاپ کوچک انجام می‌دادم، تیم فنی تصمیم گرفت همه‌چیز را از صفر بسازد چون به boilerplate های عمومی اعتماد نداشت. سه ماه بعد همان پروژه به‌خاطر پیچیدگی‌های پیکربندی و دوباره‌کاری تأخیر داشت. اگر از ابتدا یک boilerplate مناسب انتخاب شده بود احتمالاً یک ماه صرفه‌جویی می‌شد. از آن پروژه فهمیدم boilerplate و سرعت توسعه یک رابطه‌ی مستقیم دارند که کمتر جدی گرفته می‌شود. در این متن تجربه‌ی خودم از مکانیزم این اثر و روش اندازه‌گیری واقعی آن را با شما در میان می‌گذارم.

Boilerplate و سرعت؛ رابطه‌ی واقعی چیست؟

boilerplate به‌خودی‌خود سرعت پروژه را زیاد نمی‌کند؛ این کار را با حذف کارهای تکراری انجام می‌دهد. تفاوت این دو جمله ظریف اما مهم است چون نشان می‌دهد boilerplate باید در جای درست استفاده شود نه به‌عنوان چسب جادویی. مفهوم کلی boilerplate را در Boilerplate چیست و چه کاربردی در برنامه‌نویسی دارد کامل توضیح داده‌ام.

در پروژه‌های وب امروز بخش بزرگی از زمان توسعه صرف کارهایی می‌شود که در همه‌ی پروژه‌ها تکراری‌اند: پیکربندی ابزارهای بیلد راه‌اندازی ساختار پوشه‌ها تنظیمات امنیتی سیستم احراز هویت ساختار routing و مدیریت state. این کارها در هر پروژه‌ی جدید به‌طور معمول بین سه تا هفت روز کاری وقت می‌گیرند. boilerplate این بخش‌ها را از پیش آماده دارد و زمان صرفه‌جویی‌شده را به بخش‌های اختصاصی پروژه اختصاص می‌دهد.

رابطه‌ی boilerplate و سرعت در تجربه‌ی خودم یک رابطه‌ی ضربی است نه جمعی. یعنی هر روزی که صرفه‌جویی می‌شود نه فقط آن روز بلکه تأخیرهای زنجیره‌ای بعدی را هم حذف می‌کند چون هر تأخیر کوچک روی تسک بعدی اثر می‌گذارد. اگر این مفهوم را با مکانیزم آبشاری تأخیر در پروژه‌های نرم‌افزاری ترکیب کنیم اهمیت boilerplate بیشتر روشن می‌شود.

boilerplate جادو نمی‌کند؛ فقط اجازه می‌دهد از بخش‌های تکراری عبور کنید تا به ارزش اصلی پروژه برسید.

مکانیزم اثر boilerplate بر سرعت

اثر boilerplate بر سرعت توسعه در چهار لایه قابل توضیح است که در تجربه‌ی خودم هر چهار لایه محسوس بوده‌اند.

لایه‌ی اول: حذف پیکربندی از صفر

هر پروژه‌ی وب جدید نیاز به پیکربندی ده‌ها ابزار دارد: build tools linters فرمترها تست runners ابزارهای امنیتی و غیره. هر ابزار یک ساعت تنظیمات دارد و اگر از boilerplate آماده شروع کنید این ساعت‌ها حذف می‌شوند. مسیر این ابزارها در ابزارهای توسعه وب چیست نوشته‌ام.

لایه‌ی دوم: ساختار آماده برای شروع

وقتی ساختار پوشه‌ها و معماری کلی آماده است شما از روز اول می‌دانید هر چیزی کجا باید برود. این ساختار آماده زمان فکر کردن به معماری را به حداقل می‌رساند و باعث می‌شود تیم روی محتوای پروژه متمرکز شود.

لایه‌ی سوم: کاهش تصمیم‌گیری‌های کوچک

هر پروژه ده‌ها تصمیم کوچک دارد: کدام لینت‌ر کدام تست‌رانر کدام ساختار پوشه. boilerplate این تصمیم‌ها را از قبل گرفته و انرژی ذهنی تیم را برای تصمیم‌های مهم آزاد می‌کند. در تجربه‌ی خودم این اثر از دو لایه‌ی اول مهم‌تر است چون تصمیم‌های کوچک به‌سرعت تجمع می‌یابند.

لایه‌ی چهارم: کاهش خطاهای ابتدایی

خطاهای ابتدایی مثل فراموش کردن متاتگ viewport یا نبود normalize در نهایت باعث دوباره‌کاری می‌شوند. boilerplate این خطاها را حذف می‌کند و باعث می‌شود زمان صرف‌شده برای رفع خطا کاهش پیدا کند. مسیر مشابه را در اشتباهات رایج در استفاده از Boilerplate نوشته‌ام.

کجا واقعاً زمان صرفه‌جویی می‌شود؟

صرفه‌جویی زمان در boilerplate یک تصویر ساده نیست. در تجربه‌ی خودم سه نقطه‌ی مشخص صرفه‌جویی وجود دارد که هر یک محاسبه‌پذیر است.

نقطه‌ی اول زمان راه‌اندازی: بین سه تا هفت روز در پروژه‌های معمولی که با boilerplate به یک تا دو روز کاهش می‌یابد. نقطه‌ی دوم زمان تصمیم‌گیری معماری: بین دو تا چهار روز که با boilerplate به چند ساعت کاهش می‌یابد. نقطه‌ی سوم زمان رفع خطاهای ابتدایی: بین یک تا سه روز که با boilerplate تقریباً حذف می‌شود.

جمع این سه نقطه در پروژه‌های متوسط بین شش تا چهارده روز کاری صرفه‌جویی است. در پروژه‌های بزرگ‌تر این عدد بیشتر می‌شود چون تصمیم‌های اولیه‌ی معماری اثر بزرگ‌تری دارند. در پروژه‌های کوچک این صرفه‌جویی کمتر است چون boilerplate خودش زمان یادگیری دارد. مسیر انتخاب boilerplate مناسب اندازه پروژه را در Boilerplate های HTML و CSS و Boilerplate های Vue نوشته‌ام.

مقایسه‌ی عملی با و بدون boilerplate

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

بخش جالب این جدول ردیف آخر است: توسعه‌ی بخش‌های اختصاصی پروژه در هر دو مورد یکسان است چون boilerplate روی آن اثر ندارد. این نشان می‌دهد boilerplate سرعت بخش‌های تکراری را چند برابر می‌کند اما روی بخش‌های اختصاصی خنثی است. یعنی هر چه پروژه بیشتر از بخش‌های تکراری تشکیل شده باشد boilerplate مزیت بیشتری دارد.

boilerplate روی بخش‌های اختصاصی پروژه هیچ کمکی نمی‌کند؛ فقط بخش‌های تکراری را از سر راه برمی‌دارد.

اندازه‌گیری سرعت واقعی توسعه

برای اینکه بدانید boilerplate واقعاً سرعت را افزایش داده یا فقط حس بهتری ایجاد کرده باید سرعت توسعه را اندازه بگیرید. چهار سنجه در تجربه‌ی خودم مفید بوده‌اند.

1. زمان تا اولین commit معنادار: از لحظه‌ی شروع پروژه تا اولین commit که بخشی از منطق اختصاصی پروژه را دارد. این عدد نشان می‌دهد چقدر از زمان اولیه صرف کارهای تکراری شده.
2. زمان تا اولین deploy قابل نمایش: از شروع تا اولین نسخه‌ی آنلاین که قابل نمایش به مشتری است.
3. تعداد دوباره‌کاری‌ها: تعداد قابلیت‌هایی که به‌خاطر خطاهای ابتدایی باید بازسازی می‌شدند. این عدد با boilerplate به‌شدت کاهش می‌یابد.
4. زمان صرف‌شده روی تصمیم‌های تکراری: جمع زمان جلساتی که برای تصمیم‌گیری‌های پایه مثل ساختار پوشه یا انتخاب ابزار صرف شده.

این چهار سنجه را می‌توانید در دو پروژه‌ی مشابه مقایسه کنید و به نتیجه‌ی واقعی برسید. مسیر مشابه در اندازه‌گیری سرعت پروژه‌های وب را در بهینه‌سازی سرعت سایت چیست نوشته‌ام.

انواع boilerplate و اثرشان بر سرعت

اثر boilerplate بر سرعت به نوع آن بستگی دارد. در تجربه‌ی خودم چهار دسته‌ی اصلی وجود دارد که هرکدام سرعت متفاوتی ایجاد می‌کنند.

boilerplate های مینیمال بیشترین سرعت در پروژه‌های کوچک دارند چون سربار کمی دارند و امکان شروع سریع می‌دهند. boilerplate های مبتنی بر framework در پروژه‌های متوسط بیشترین سرعت را می‌دهند چون بخش بزرگی از استایل‌های پایه آماده است. boilerplate های پرامکانات در پروژه‌های بزرگ با نیازهای متنوع سرعت بیشتری می‌دهند اما در پروژه‌های کوچک سربار می‌شوند. boilerplate های اختصاصی که خودتان ساخته‌اید بیشترین سرعت را دارند چون دقیقاً با نیازهای شما هماهنگ هستند.

در تجربه‌ی خودم انتخاب نوع boilerplate بر اساس اندازه و نوع پروژه مهم‌تر از محبوبیت آن است. برای پروژه‌های کوچک boilerplate مینیمال و برای پروژه‌های بزرگ boilerplate اختصاصی بهترین نتیجه را می‌دهد. مسیر مشابه در انتخاب boilerplate های اختصاصی را در Boilerplate های React و Boilerplate های PHP نوشته‌ام.

مرزهای سرعت؛ boilerplate همه‌چیز نیست

boilerplate سرعت را افزایش می‌دهد اما مرزهای مشخصی دارد که در تجربه‌ی خودم باید بشناسید.

اولین مرز کیفیت تیم است. اگر تیم شما تجربه‌ی کافی نداشته باشد boilerplate کمکی نمی‌کند چون بخش‌های اختصاصی پروژه به‌خاطر عدم تجربه کند پیش می‌روند. دوم پیچیدگی نیازهای پروژه. اگر پروژه‌ی شما نیازهای بسیار غیرمعمول داشته باشد boilerplate مزیت کمتری دارد چون بخش بزرگی از کار اختصاصی است. سوم کیفیت boilerplate. boilerplate ضعیف نه‌فقط سرعت را افزایش نمی‌دهد بلکه ممکن است آن را کاهش دهد چون تیم باید با مشکلات آن دست‌وپنجه نرم کند. مسیر بررسی کیفیت boilerplate را در Boilerplate های امن نوشته‌ام.

چهارمین مرز سرعت یادگیری تیم است. اگر تیم با boilerplate آشنا نباشد ممکن است چند روز اول صرف یادگیری ساختار آن شود. این هزینه در پروژه‌های طولانی‌مدت بازگشت پیدا می‌کند اما در پروژه‌های کوچک ممکن است توجیه نداشته باشد.

تله‌های سرعت؛ جایی که boilerplate کند می‌کند

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

• ناسازگاری با پروژه: boilerplate ای که با نیازهای پروژه سازگار نیست باعث می‌شود تیم زمان بیشتری برای دور زدن محدودیت‌های آن صرف کند.
• سربار کد اضافه: boilerplate سنگین با امکاناتی که استفاده نمی‌شوند سرعت توسعه را کاهش می‌دهد چون تیم باید ساختار آن را بشناسد و دور بزند.
• وابستگی به ساختار: اگر تیم بیش‌ازحد به ساختار boilerplate وابسته شود انعطاف پروژه کم می‌شود و تصمیم‌گیری کندتر می‌شود.
• نبود مستندات: boilerplate بدون مستندات باعث می‌شود تیم زمان زیادی صرف فهمیدن ساختار کند.
• استفاده از boilerplate قدیمی: boilerplate ای که با آخرین نسخه‌ی ابزارها سازگار نیست باعث می‌شود تیم برای رفع مشکلات نسخه وقت بگذارد.

این تله‌ها با انتخاب دقیق boilerplate در ابتدا قابل اجتناب هستند. مسیر این انتخاب را در اشتباهات رایج در استفاده از Boilerplate نوشته‌ام.

سرعت تیمی و نقش boilerplate

در تیم‌های چندنفره نقش boilerplate در سرعت پیچیده‌تر از پروژه‌های فردی است. در تجربه‌ی خودم سه اثر مشخص در تیم‌ها دیده‌ام.

اثر اول کاهش زمان هماهنگی است. وقتی همه از یک ساختار استفاده می‌کنند جلسات هماهنگی کوتاه‌تر می‌شود چون نیاز به توافق روی ساختار اولیه نیست. اثر دوم تسریع onboarding است. عضو جدید تیم با یادگیری boilerplate سریع‌تر می‌تواند مشارکت کند چون ساختار برایش آشناست. اثر سوم کاهش کد متفاوت است. در پروژه‌های بدون boilerplate هر توسعه‌دهنده ممکن است ساختار خودش را بسازد که بعداً باعث ناهماهنگی می‌شود.

اثر چهارم که کمتر گفته می‌شود بهبود ارتباط بین تیم‌ها است. اگر تیم فرانت‌اند و بک‌اند از boilerplate مشترک استفاده کنند ارتباطات فنی بین آن‌ها ساده‌تر می‌شود چون ساختار پروژه در هر دو طرف قابل پیش‌بینی است. مفهوم مشابه در فول‌استک چیست و چه مهارت‌هایی نیاز دارد نوشته‌ام.

ساخت boilerplate اختصاصی برای سرعت بیشتر

boilerplate اختصاصی بیشترین سرعت را می‌دهد چون دقیقاً با نیازهای تیم شما هماهنگ است. فرآیند ساخت آن در تجربه‌ی خودم چهار مرحله دارد.

1. شناسایی نقاط پرتکرار: در سه تا پنج پروژه‌ی گذشته نقاطی که همیشه تکرار شده‌اند را فهرست کنید. مثلاً ساختار پایه صفحه ساختار فرم سیستم احراز هویت.
2. جداسازی الگوهای عمومی: هر چیزی که در همه‌ی پروژه‌ها یکسان است را به boilerplate منتقل کنید.
3. ساختار ماژولار: boilerplate را طوری بسازید که بخش‌های اضافه قابل حذف یا جایگزینی باشند. این کار اجازه می‌دهد boilerplate برای پروژه‌های مختلف با نیازهای متفاوت تطبیق پیدا کند.
4. نگهداری در Git: boilerplate را در مخزن Git نگه دارید و نسخه‌بندی معنادار داشته باشید.

boilerplate اختصاصی یک سرمایه‌گذاری اولیه است که در پروژه‌های بعدی چند برابر بازگشت می‌دهد. در تجربه‌ی خودم بعد از ساخت boilerplate اختصاصی زمان راه‌اندازی پروژه‌های مشابه از پنج روز به یک روز کاهش یافت. مسیر مشابه این فرآیند را در چگونه یک پروژه توسعه وردپرس را ساختاربندی کنیم و گیت در وردپرس نوشته‌ام. برای درک عمیق‌تر از فرآیندهای توسعه و ابزارهای مرتبط نگاهی به توسعه وردپرس چیست و از کجا باید شروع کنیم بیندازید.

در این مسیر اگر به زبان‌های دیگر مثل Python یا Vue کار می‌کنید، ساخت boilerplate اختصاصی همان اثر را خواهد داشت. یک ابزار تخصصی برای پروژه‌های Vue در Boilerplate های Vue و برای پروژه‌های HTML و CSS در Boilerplate های HTML و CSS آمده است. برای درک این که boilerplate چه تفاوتی با template و framework دارد نگاهی به Boilerplate code بیندازید.

پرسش‌های پرتکرار درباره boilerplate و سرعت

آیا boilerplate همیشه سرعت توسعه را افزایش می‌دهد؟

خیر. boilerplate در صورتی سرعت را افزایش می‌دهد که با اندازه و نوع پروژه هماهنگ باشد. boilerplate سنگین برای پروژه‌های کوچک می‌تواند سرعت را کاهش دهد چون سربار یادگیری و پیچیدگی دارد.

چقدر زمان واقعاً صرفه‌جویی می‌شود؟

در پروژه‌های متوسط بین شش تا چهارده روز کاری در تجربه‌ی من. این عدد بستگی به اندازه پروژه کیفیت boilerplate و تجربه تیم دارد. در پروژه‌های کوچک این عدد کمتر است چون بخش بزرگی از کار اختصاصی است.

آیا boilerplate روی سرعت اجرای پروژه هم اثر دارد؟

boilerplate روی سرعت توسعه اثر مستقیم دارد اما روی سرعت اجرای نهایی پروژه (performance) بستگی به کیفیت خود boilerplate دارد. boilerplate ای که بهینه باشد سرعت اجرا را هم بهبود می‌دهد. مسیر این تفکیک را در بهینه‌سازی سرعت سایت چیست نوشته‌ام.

چطور بفهمم boilerplate واقعاً سرعت پروژه را افزایش داده؟

با اندازه‌گیری زمان تا اولین deploy و مقایسه با پروژه‌ی مشابه بدون boilerplate. اگر تفاوت محسوس باشد boilerplate مؤثر بوده. بدون اندازه‌گیری، حس بهتری که boilerplate ایجاد می‌کند می‌تواند گمراه‌کننده باشد.

آیا boilerplate اختصاصی سریع‌تر از boilerplate عمومی است؟

در بلندمدت بله چون با نیازهای تیم شما هماهنگ است و سربار کمتری دارد. اما ساخت آن زمان اولیه می‌برد که در پروژه‌های کوتاه‌مدت ممکن است بازگشت پیدا نکند. زمان درست برای ساخت boilerplate اختصاصی بعد از سه تا پنج پروژه است.

آیا باید boilerplate را برای هر پروژه جدید به‌روز کنم؟

نه برای هر پروژه اما به‌طور دوره‌ای بله. boilerplate باید هر شش ماه یک بار بازبینی شود تا با آخرین نسخه‌ی ابزارها و الگوهای بهتر هماهنگ بماند. به‌روزرسانی مداوم باعث می‌شود boilerplate در طول سال‌ها به یک دارایی زنده تبدیل شود.

آیا boilerplate روی اندازه تیم اثر دارد؟

boilerplate در تیم‌های متوسط و بزرگ اثر بیشتری دارد چون زمان هماهنگی و onboarding را کاهش می‌دهد. در تیم‌های کوچک (یک تا دو نفر) اثر اصلی روی سرعت راه‌اندازی است نه هماهنگی.

آیا boilerplate روی هزینه‌ی پروژه هم اثر دارد؟

بله به‌طور غیرمستقیم. زمانی که صرفه‌جویی می‌شود در پروژه‌های با قیمت ثابت به سود تیم تبدیل می‌شود و در پروژه‌های ساعتی به مشتری. این اثر در پروژه‌های طولانی‌مدت محسوس‌تر است.

معادله‌ی سرعت توسعه

boilerplate و سرعت توسعه یک رابطه‌ی ضربی دارند نه جمعی. یعنی هر ساعت صرفه‌جویی در ابتدای پروژه اثر چند برابری در ادامه دارد چون تأخیرهای بعدی را حذف می‌کند. اما این معادله شرط دارد: boilerplate باید با اندازه و نوع پروژه هماهنگ باشد و تیم باید ساختار آن را بشناسد.

معادله‌ی سرعت توسعه در تجربه‌ی خودم سه ضریب دارد: boilerplate درست انتخاب شده معماری صحیح پروژه و تیم با تجربه. اگر هر یک از این سه ضریب صفر باشد سرعت مطلوب به‌دست نمی‌آید. پیشنهاد عملی من: با یک boilerplate عمومی معتبر شروع کنید و بعد از سه تا پنج پروژه boilerplate اختصاصی خودتان را بسازید. اگر تجربه‌ای از boilerplate ای دارید که واقعاً سرعت پروژه‌تان را چند برابر کرده در دیدگاه‌ها به اشتراک بگذارید تا فهرست انتخاب‌های تجربی کامل‌تر شود. ⚡