Clean Code (بخش اول)

سخن اولطی این سلسله پست ها قصد دارم مفاهیم ساده ولی مهمی رو که می تونه برنامه نویسی رو برای ما بیشتر از قبل جذاب بکنه و همین طور کمک کنه تا به یه برنامه نویس خوب شایدم به یه حرفه ای تبدیل بشیم رو مطرح بکنم.همه چیز از اونجایی شروع شد که وارد یه پروژه نسبتا بزرگ شده بودم و پیچیدگی و حجم کار بالا بود و البته مدیریت ضعیف، روز به روز که جلو می رفتیم می دیدم که داریم توی کد هامون غرق می شیم و نگهداری و بروزرسانی کد ها و اضافه کردن فیچر های جدید داشت روز به روز سخت تر می شد یکی از دلایل عمده ی این مشکل حضور دائمی ددلاین تو یک قدمی ما بود روزی رو سراغ ندارم که فرداش ددلاین نباشه (یکم مبالغه امیز ولی تقریبا درسته) و مشکلات ریز و درشت دیگه ای که جای مطرح کردنش نیست. خود این مشکل فرصت کافی فکر کردن و سازماندهی به کد هارو از برنامه نویسا گرفته بود.مشخص بود هرچی بیشتر جلو بریم بازدهی برنامه و برنامه نویس روز به روز کم تر میشه در نهایت به جایی می رسیم که نمیشه کاریش کرد یا باید همه چیو از صفر شروع کرد یا باید همه چیو ریخت دور یه روز که کلید واژه های مختلف و سرچ می کردم و داشتم فکر می کردم که چطوری باید خودمون و از باتلاقی که درست کردیم نجات بدیم و با این کار خود پروژه رو از سرنوشت شومی که در انتظارش نجات بدیم به کتابی بر خوردم که برای حل همین مشکل یعنی کمک به نگهداری و اعمال راحت تر تغییرات طراحی شده بود.کتاب عنوان ساده ای داشت Clean Code، همین که صفحات اولیه کتاب رو خوندم متوجه شدم که این دقیقا همون راه حلی بود که دنبالش بودم. نویسنده این کتاب Robert Cecil Martin معروف به uncle bob مدرس و مهندس نرم افزار امریکایی هستش که به عنوان یکی از نویسندگان Agile و همچین ارائه دهنده چندین اصل طراحی نرم فزار شناخته شده است.سخن اول کتابشما این کتاب را به دو دلیل می خونین دلیل اول اینکه برنامه نویس هستین دلیل دوم اینکه شما قصد دارید برنامه نویس بهتری بشید.خاطره ای کوتاه از کتابکمپانی رو در دهه 80 میشناختم که یک اپلیکیشن موفق طراحی کرده بود و محبوبیت زیادی کسب به دست اورده بود اما روز به روز زمان انتشار نسخه جدید اپلیکیشن طولانیتر می شد و نظم قبلا رو نداشت و باگ ها از نسخه ای به نسخه بعد از بین نرفته بودن و زمان لود اپ و کراش اپ بیشتر و بیشتر شده بود و بالاخره کمپانی مجبور شد ادامه کار روی اپلیکیشن متوقف کنه و دیگه هیچ وقت ازش استفاده نکرد.حدود 20 سال بعد من یکی از کارمندان قدیمی اون شرکت رو ملاقات کردم و در مورد دلیل این اتفاق ازش سوال کردم. جواب نظریه های منو تایید کرد. ما باید اپلیکشین رو هر چه زود تر به بازار ارائه می دادیم به همین دلیل کدها به شدت کثیف و ناخوانا بود. ما اسمی براش گذاشتیم و اون رو wading (توده های انباشه شده روی هم) صداش می کردیم. ما هرچه بیشر و بیشتر ویژگی اضافه می کردیم نگهداری و مدیریت کد ها سخت تر و سخت تر می شد. این کد نامناسب بود که کمپانی رو از بین برد.نمودار نسبت بازده به زمان بر اساس یک کد بدشاید الان فک کنین که مشکل مدیریت کمپانی بود که همه چی از بین رفته ولی دلیل اصلی خود برنامه نویس ها هستن چون مدیر،مشتری و بازار با توجه به اطلاعاتی که ما بهشون میدیم برنامه ریزی میکنن و جلو میرین و حتی اگر از ما برنامه ریزی نخوان هم ما باید مشکلات و اشتباهاتی مانند زمان بندی که تو کد تاثیر دارن و بهشون بگیم حتی اگه خوشون نیاد(یکم آرمانگرایانه است) و در نظر داشته باشیم که ما به عنوان برنامه نویس مسئولیم. و توجه داشته باشیم که تمیز کاری کد رو هیچ وقت به بعدا موکول نکنیم چون طبق قانون لبلانک بعدا === هرگز.در ادامه و در پست های بعدی نکات مهم و مباحث مختلف و مطرح میکنم که با رعایت ساده هر کدوم از اونا روز به روز می بینین که همه چی تمیز تر میشه و البته سعی میکنم نقل قول های مختلفی که توی کتاب در مورد کد تمیز اومده رو در خلال پست ها بعدی جا بدم خوندن اونام خالی از لطف نیست.