خلاصه کتاب Pragmatic Programmer. درس 25

خلاصه کتاب Pragmatic Programmer. درس 25

درس 25: Assertive Programmingاینجوری بنظر میرسه که یک زمزمه درونی وجود داره که هر برنامه نویسی ام در شروع کارش اونو حفظ میکنه، در هر پروسه از تولید نرم افزار از طراحی دیزاین و کد هم وجود داره، حتی برای امور دیگه زندگی هم همینطور.This can never happen… مثلا:- این اپلیکیشن که نمیخاد خارج از مرزها استفاده بشه پس لوکالیزیشن لازم نداره- فیلد تعداد هیچ وقت نمیتونه منفی باشه توی ی جای خاص- پروسه لاگ کردن هیچ وقت خودش خطا نمیخوره و ترمینیت نمیشه** بیاید این مدل خود فریبی ها رو تمرین نکنیم، مخصوصا موقع کدنویسی• استفاده از Assertion برای جلوگیری از غیر ممکن هاهروقت خودتونو توی شرایطی دیدید که دارید فکر میکنید راجع به اینکه یک چیز غیر ممکنه رخ بده، برای چک کردنش کدی رو بنویسید. یکی از ساده ترین راه ها استفاده از assert هستش که در بسیاری از زبون های برنامه نویسی پیاده سازی شده که معمولا یک شرایط بولین رو براتون چک میکنه.مثلا اگر نتیجه ای نباید نال باشه اینجوری چکش میکنید:assert (result != null);یا برای اطمینان از نتیجه یک الگوریتم استفاده میشه، فرض کنید یک الگوریتم سورت نوشتید و میخاید چکش کنید که درست عمل کرده یا نه:books = my_sort(find(“scifi”))assert(is_sorted?(books))از assert برای ارور هندلینگ استفاده نکنید، assert ها رو فقط برای چیزهایی که هیچ موقع امکان نداره که رخ بده استفاده کنید. مثلا کد زیر توصیه نمیشه:puts(“Enter ‘Y’ or ‘N’: “)ans = gets[0] # Grab first character of responseassert((ch == ‘Y’) || (ch == ‘N’)) # Very bad idea!• ساید افکت های Assertionخیلی بد میشه اگر کدی که برای چک کردن چیزی میزنیم خودش باعث خرابی و خطا بشه، مثلا کد زیرو فرض کنید:while (iter.hasMoreElements()) {assert(iter.nextElement() != null);Object obj = iter.nextElement();// ….}iter.nextElement() این خودش یکی از المنتهای ایتریتورو میگیره و خط بعدشم کد اصلی میخاد یکی بگیره اینجوری نصف کالکشن فقط پردازش میشه. برای اصلاحش کدو به شکل زیر در میاریم:while (iter.hasMoreElements()) {Object obj = iter.nextElement();assert(obj != null);// ….}• بزارید assert ها توی کد بموننیک سری بدفهمی راجع به استفاده از assert ها وجود داره، مثلا: استفاده ازشون برای کدمون سربار ایجاد میکنه، چون دارن چیزی رو چک میکنن که قرار نیست اتفاق بیفته، اون ها فقط در شرایط وجود باگ در کد تریگر میشن، وقتی کدو تست بکنیم دیگه بهشون نیازی نداریم. و غیرفعالشون کنیم تا کد سریعتر اجرا بشه و اونها فقط ابزار دیباگینگ هستن.در اینجا دو فرض کاملا اشتباه وجود داره:اول اینکه فکر کنیم تست ها قراره همه باگ ها رو شناسایی کنند، در واقعیت و در برنامه های پیچیده حالت هایی رخ میده و باگ هایی میزنه بیرون که شما توی تست کاور نکردید.دوم اینکه این افراد خوش بین فراموش میکنند که برنامه شون در دنیایی خطرناک قراره اجرا بشه، از موشی که قراره کابل شبکه رو گازش بگیره و قطع بکنه بگیر، تا کاربری که روی سیستم بازی میکنه و مموری کم میاد، تا لاگ فایلهایی که انقدر زیاد شدن حجم استوریج سرورو پر کردن و … تمام این داستانا توی محیط پروداکشن ممکنه اتفاق بیفته. خط اول دفاعی تون باید کدهایی باشه که حالت های خطا رو بررسی میکنن و در خط دوم با assert ها اون حالتهای غیرممکن که احتمال میس شدن دارنو چک میکنید.علی ایحال میتونید اون assert هایی که براتون پر هزینه تموم میشه رو چشم پوشی کنید ولی مدلهایی که در این درس مثال زدیم برای هر اپلیکیشن مشابهی حیاتیه.دروس مرتبط 23, 24, 42, 43منبع کانال تلگرامی: https://t.me/pragmaticprogrammer_fa

Author: admin

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *