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

درس 24: برنامه های مرده دروغ نمیگن (Dead Programs Tell No Lies)تاحالا پیش اومده که وقتی ی مشکلی دارید یا ی چیزی تون بهم ریخته، قبل از خودتون دیگران متوجه ش بشن؟ این در مورد کدها هم صدق میکنه مثلا وقتی کد ی نفر دیگه رو میبینی. گاهی اوقات کدی که فکر میکنی درسته، باگش توسط کتابخونه تردپارتی و جایی که زیر بار میره در میاد، شاید ی مقدار نال یا لیست خالی پاس دادیم، یا شایدم ی کلید ضروری از یک هش ست خالیه، یا خطای شبکه، یا حتی خطای فایل سیستمه سیستم عامل، که ما حواسمون به مدیریت خطاش نبوده، یا حتی توی سوییچ کیس مقدار دیفالت نزاشتیم یا همش داره مقدار دیفالت برمیگرده ی جای کار میلنگه. ما میخایم جایی که "غیر ممکن" اتفاق افتاده رو شناسایی کنیم.این خیلی ساده است که بیفتی روی جمله‌ی "این که رخ نمیده"، اکثرا کدی مینویسیم که چک نمیکنه فایلی که باز و استفاده شده، موفقیت امیز کلوز شده یا نه. و ممکنه برای حالت های نرمال و وضعیت های گل و بلبل کد بزنید. اما قبلتر گفتیم ما مدل تدافعی رو میپسندیم، ما دیتای ورودی رو دقیق چک میکنیم تا همون چیزی باشه که باید، دیتایی که حاصل پردازش کدمون بوده رو هم همینطور چک میکنیم، همچنین چک میکنیم که کتابخونه های وابسته دقیقا همون ورژن های مد نظر باشه که لود میشه.همه خطاها به شما اطلاعات کافی رو میدن. ممکنه شما اون سبک "خطایی رخ نمیده رو" انتخاب کنید، قطعا اشتباه میکنید. در عوض برنامه نویس عملگرا (Pragmatic Programmer) همیشه به این فکر میکنن که اگر خطایی رخ بده اتفاق خیلی خیلی بدیه و تمام ابعاد قضیه رو میسنجن.• CATCH AND RELEASE IS FOR FISHبعضی از برنامه نویسا حال خوبی دارن از اینکه خطاها رو کچ و لاگ و بعدم ریز کنن مثل کد زیر:try do add_score_to_board(score);rescue InvalidScore Logger.error("Can't add invalid score. Exiting"); raiserescue BoardServerDown Logger.error("Can't add score: board is down. Exiting"); raiserescue StaleTransaction Logger.error("Can't add score: stale transaction. Exiting"); raiseendاما همین کدو یک برنامه عملگرا اینجوری میزنه:add_score_to_board(score);ما این کدو به دو دلیل ترجیح میدیم، اول اینکه کد برنامه تحت شعاع خطایابی قرار نمیگیره و دلیل دوم و مهمتر اینکه، این کد کمتر وابستگی داره به نسبت کد قبل، توی کد قبل یکسری لیست خطاهای خاص کچ شده، فرض کنید اگر خطای جدیدی هم بخاد هندل بشه باید این کد تغییر بکنه و اون خطا هم به لیست کچ هاش اضافه بشه، اما کد دوم هر خطایی بخوره به سطح بالاترش ریزش میکنه.• CRASH, DON’T TRASHاین خیلی مفیدتره که زودتر خطاها و مشکلاتو دیتکت کنید، زودتر کرش(Crash) کنید، این بهترین اتفاقیه که میتونه براتون بیفته، که اگر نیفته در مقابلش اینه که شما به نوشتن کد مشکل دار ادامه میدید و اونو روی یک دیتابیس حیاتی اجرا میکنید.در زبون های برنامه نویسی Erlang و Elixir این فلسفه بخوبی پیاده شده، در حدی که آرمسترانگ سازنده زبون ارلنگ و نویسنده کتاب برنامه نویسی ارلنگ، توی کتاب میگه برنامه نویسی تدافعی اتلاف وقته، بزار کرش کنه. وقتی کرش کرد با سوپروایزرهای سیستمی مدیریت میشه، سوپروایزرها مسئول اجرای کد و مانیتور وضعیتشن، میتونن اجرا، ریست و حتی ببندن اجرای برنامه رو. اما اگر سوپروایزر خودش خطا بخوره چی؟ سوپروایزر خودش توسط مجموعه درختی از سوپروایزرها منیج میشه.در محیط های برنامه نویسی دیگر، ممکنه این مناسب تر باشه که برنامه بسته بشه اگر خطا خورد، یا خطاها لاگ بشه و یا از تراکنشها استفاده کنید و یا حتی با پراسس های دیگه ارتباط برقرار کنید برای مدیریت خطاها.اما در نهایت اصل پایه اینه که وقتی کد میزنید و به چیزهایی میرسید که فکر میکنید رخ دادنش محاله، و بهش رسیدگی نکنید و مدیریتش نکنید، برنامه شما مضنون خاهد بود و خیلی زود گندی رو به بار میاره.یک برنامه مرده معمولا آسیب کمتری از یک برنامه مشکل دار میزنه.دروس مرتبط: 20, 23, 25, 26, 43منبع کانال تلگرامی: https://t.me/pragmaticprogrammer_fa