نود و هفت چیزی که هر برنامه‌نویسی باید بداند: Build اصولی ارائه کنید


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

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

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

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

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

نکته
به طور کلی، در شاخه ی برنامه نویسی و توسعه ی نرم‌افزار، Build به فرایندی گفته می‌شود که در آن سورس کد به برنامه یی قابل اجرا و قابل استفاده مبدل می‌گردد که معمولاً با یک شناسه -مثلا ۱۷- شناخته می‌شود که قبل از انتشار نهایی نرم‌افزار و در فرایند تست نرم افزار ایجاد می‌گردد. یکی از فرایندهای مهم در بیلد کردن، کامپایل کردن سورس کد است که در این فرایند سورس کد نرم‌افزار به کدهای قابل اجرا توسط ماشین تبدیل می‌شوند.
لیست نظرات
کاربر میهمان
دیدگاه شما چیست؟
کاربر میهمان
محسن
محسن
اینکه ارورها بعدا در فرصت مناسب بر طرف میشن مصداق بارز "بدهی فنی" یا Technical Debt که هرچه دیرتر بشه تسویه حسابش هم سخت تر و سخت تر می شه
مطلب زیر به به طور کامل این مفهوم رو توضیح داده

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: بدهی فنی
https://sokanacademy.com/courses/ninety-seven-things-every-programmer-should-know/1447/نود-و-هفت-چیزی-که-هر-برنامه-نویسی-باید-بداند:-بدهی-فنی


در مورد Build کردن کدهای نوشته شده
مرحله 5 از چرخه حیات اپلیکیشن هست و اینقدر مهم بوده که در رفرنس های مایکروسافت به عنوان یک مرحله مستقل در نظر گرفته شده

9 مرحله چرخه حیات اپلیکیشن
Planning your project
Designing the user interface (UI)
Updating the app manifest
Writing the code
Building the app
Debugging and testing the app
Packaging the app
Validating the app
Deploying the app