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

درس 5: نرم افزار به اندازه کافی خوب (Good-Enough Software)یک جوک قدیمی هست که توی اون یک شرکت سفارش 100 هزار قطعه آی سی به یک تولید کننده ژاپنی میده، تو توضیحات اون محصول نوشته بودن ممکنه توی هر 10 هزار قطعه از اون محصول یکیش خراب باشه، چند هفته بعد سفارش اون شرکت میرسه دستش، یک جعبه بزرگ و حاوی چندین هزار آی سی و یک جعبه کوچیک که توش فقط 10 تا آی سی بوده و روش نوشته بودن: اینا خراباشه که گفته بودیم طبق یک ریتی(Rate) ممکنه پیش بیاد.اما تو واقعیت جهان بهمون این اجازه رو نمیده که بتونیم در این حد پرفکت باشیم، نرم افزاری بدون هیچ باگ...زمان، تکنولوژی و دیگر مسائل علیه ما بسیج میشن. اما این نباید باعث نگرانی تون بشه.قبل اینکه این درسو پیش ببریم، نیاز داریم که شفاف تر کنیم راجع به چی میخایم صحبت کنیم. در وهله اول بگم منظورمون از لفظ "good enough" سمت کد تمیز و کثیف نیستش.همه سیستم ها باید نیازهای کاربراشونو رفع کنند، حداقل های پرفورمنسی رو داشته باشن، استانداردهای پرایوسی و امنیتی رو هم رعایت کنند.ما میتونیم به کاربران سیستممون این فرصتو بدیم تا در پروسه تصمیم گیری شرکت کنند، که این منجر میشه به اینکه شما یک محصول به اندازه کافی خوب رو برای نیازهای اونا بسازید.کاربراتونو شرکت بدید تو بازیمعمولا ما نرم افزارو برای دیگران مینویسیم. این به معنیه که شما باید به خوبی بدونید اونا چی میخان. تا حالا شده ازشون بپرسید چیزی که میخان با چه سطح کیفیت و کارکردی مدنظرشونه؟ توی برخی سیستم ها که هیچ راهی به جز یک گزینه وجود نداره مثل سیستم ضربان ساز قلب مصنوعی، خلبان خودکار، یا کتابخونه های سطح پایین(نزدیک به سخت افزار)، چیزی که میخان انجام بشه توسط سیستم مشخص و واضحه و راه های زیادی ام برای حلش وجود نداره و گزینه های کمی برای انتخاب هست.اگر شما روی محصول جدیدی کار میکنید، محدودیت هایی خاهید داشت از براورده کردن قول های تیم فروش برای گرفتن پروژه، تا نیازهای نهان کاربرا که منتظر اولین خروجی هستند تا به ایده های خود پر و بال بدن، تا جریان نقدی و مالی شرکت شما که ممکنه به اون پروژه وصل باشه، تو این شرایط این یک کار غیر حرفه ایه که نیازمندیها و خاسته های کاربرا رو نادیده بگیرید تا فیچر دیگه ای رو تکمیل کنید در عین حال پابلیش کردن دوباره هم داستان خودش رو داره.ما طرفدار شرایط دردناک و سخت نیستیم ولی این رو بخاطر بسپارید که یقینا این یک اخلاق غیر حرفه ایه که برای رسوندن پروژه به یک ددلاین زمانی که قولشو دادیم، اصول استاندارد مهندسی نرم افزارو زیر پا بزاریم. کیفیت رو به عنوان یکی از نیازای اساسی محصول در نظر بگیرید.گاها شما ممکنه توی این ترید اف قرار یگیرید که خیلی از کاربرا اینو انتخاب کنند که با سیستم موجود علیرغم یکسری مشکلات، کار بکنند، تا اینکه یک سال صبر بکنند تا یک سیستم بی نقص و عالی بهشون بدید(البته اینم در نظر بگیرید که قطعا نیازای اونا سال بعد تفاوت هایی خاهد داشت و تغییرات دنیا غیر قابل اجتنابه). اغلب تیم های نرم افزاری با بودجه محدود از این مدل کاربرا استقبال میکنند و موافق این موضوعن. اگر شما یک چیزی رو بندازی جلوی کاربر تا باهاش کار بکنه، فیدبک هایی که بهت میدن شمارو لید میکنه تا به محصول نهایی بهتری برسی.بدون که کی متوقف شی (Know When To Stop)از دیدگاهی برنامه نویسی مثل نقاشی کردنه، تو نقاشی شما با یک بوم سفید و یک سری متریال نقاشی شروع میکنی. ترکیبی از علم، هنر و مهارت استفاده درست از اونها. یک طرح کلی رسم میکنید، رنگ های لایه های پایینو میزنید، بعد میفتید تو جزئیات. شما دائما عقب میاید و با نگاه منتقدانه بهش نگاه میکنید تا بدونید چند چندید و چقدر پیش رفتید. هر زمان ممکنه بوم و بندازید کنار(گند زده باشی توش) و یکی دیگه شروع کنید. نقاشای حرفه ای میگن سخت ترین قسمتش همینه که بدونی کی متوقف شی بیای عقب و طرحو نگاه کنی.یک نرم افزار خوبو با تزئین و اصلاح مجدد پی در پی خراب نکنید، پیش برید، بزارید کدتون توی محیط قرار بگیره و زیر بار بره، عیبی نداره اگر عالی نیست، نگران نباش چون اون هیچ وقت شاید عالی نشه(تو درس 7 ی توضیحاتی راجع این جمله میدیم)دروس مرتبط: 45,46منبع کانال تلگرامی: https://t.me/pragmaticprogrammer_fa