در فرایند کدنویسی گاهی اوقات برایمان پیش می‌آید که با لیست بلند بالایی از ارورها در حین اجرای نرم‌افزار مواجه می‌شویم و این در حالی است که با خود می‌گوییم «ان شاء الله اگر فرصتی شد، همه ی ارورها را بعداً رفع خواهم کرد!»

زمانی که ما یک پروژه ی جدید را از پایه شروع به کدنویسی می‌کنیم، نه مشکلی وجود دارد و نه اروری اما همین که سورس کد ما به مرور زمان حجیم و حجیم تر می‌شود، احتمال این که ارورها، هشدارها و اکسپشن ها زیاد شوند هم بالا می‌رود و این در صورتی که اگر این ارورها را به‌ موقع رفع نکنیم، در آینده رفع کرد یک هشدار کوچک می‌تواند به دردسری بزرگ مبدل گردد!

یکی از استراتژی های خوب در حین کدنویسی، به کارگیری سیاست Zero-tolerance Policy است؛ در‌ واقع این سیاست حاکی از آن است که IDE و محیط توسعه ی نرم افزار خود را به گونه یی تنظیم کنیم که هرگونه هشدار، خطا و اروری را به ما گوشزد کند حتی اگر خیلی کوچک و در ظاهر بی اهمیت باشند.

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

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

نکته

به طور کلی، در شاخه ی برنامه نویسی و توسعه ی نرم‌افزار، Build به فرایندی گفته می‌شود که در آن سورس کد به برنامه یی قابل اجرا و قابل استفاده مبدل می‌گردد که معمولاً با یک شناسه -مثلا ۱۷- شناخته می‌شود که قبل از انتشار نهایی نرم‌افزار و در فرایند تست نرم افزار ایجاد می‌گردد. یکی از فرایندهای مهم در بیلد کردن، کامپایل کردن سورس کد است که در این فرایند سورس کد نرم‌افزار به کدهای قابل اجرا توسط ماشین تبدیل می‌شوند.

Build اصولی ارائه کنید