سلام✋
توی قسمت قبلی راجع به اینکه چرا اصلا باید به تمیز بودن کدمون اهمیت بدیم اشاره کردیم و دلیل‌های اونو بررسی کردیم، و علاوه بر اون خود کتاب رو معرفی کردیم و توضیح دادیم که این کتاب چه قسمت‌هایی داره و اصلا چجوری باید کتاب رو بخونیم!(لینک قسمت‌های قبلی بالای همین پست هست)
حالا می‌‌خوایم به عنوان اولین قسمت اصلی یا اولین فصل خوده کتاب به این موضوع بپردازیم که چرا باید کدتمیز بنویسیم و بابت‌اش مجبور باشیم این کتاب رو مطالعه کنیم و اینکه کد تمیز یعنی چی و بزرگان برنامه‌نویسی به چی کدی میگن "کد تمیز".
به طور خیلی خلاصه ما به دو دلیل قراره خودمون رو قانع کنیم که کد تمیز بنویسیم:
اول اینکه ما برنامه‌نویسیم
دوم اینکه تمایل داریم برنامه‌نویس بهتری بشیم(دنیا به برنامه‌نویس‌های بهتری نیاز داره)
هدف اصلی این کتاب اینه که ما به برنامه‌نویس‌های بهتری تبدیل بشیم، علاوه بر اون توی طول کتاب ما به کد ها از زاویه‌های بیرونی و با دیدگاه بالاتری نگاه میکنیم که همین امر باعث میشه تفاوت بین کد خوب و بد رو متوجه بشیم و قادر باشیم کد بد رو به کد خوب تبدیل کنیم.
شاید جالب باشه که بدونین بعضی‌ها هستند که فکر میکنن کد نوشتن روند رو به منسوخ شدن داره و اکثر برنامه نویسان شغل خودشون رو از دست میدن و کلا کد بجای نوشته شدن باید براساس نیاز هامون تولید بشه، پس خوندن این نوع کتاب‌ها معنی نداره!
حرف پوچ و بی اساسیه چون، کد جزئیات نیازمندی هارو بیان میکنه. بعضی از مواقع این جزئیات قابل حذف و خلاصه شدن نیست بلکه دقیقا باید مشخص بشن، و برنامه‌نویسی یعنی توصیف کردن نیازمندی ها با جزئیاتی که یک ماشین بتواند آنهارا اجرا کند. چیزی که قابل پیشبینی است اینه که سطح انتزاع زبان‌ها رو به افزایشه و تعداد زبان‌های مربوط به یک دامنه رو به رشده، اما کد هیچوقت حذف نمیشه به دلیل اینکه حتی با وجود سطح بالا بودن زبان‌ها در آینده باز هم تنها راه توصیف نیازمندی ها از طریق کد صورت میگیره.
به یاد داشته باشید که کد در واقع زبانی است که ما درنهایت نیازمندی‌ها را با استفاده از آن بیان میکنیم. ممکن است زبان‌هایی تولید بشن که به زبان توصیف نیازمندی‌ها نزدیک‌تر اند یا ابزارهایی ایجاد بشن که توی تجزیه کردن و سرهم کردن نیازمندی‌ها به ساختارها رسمی به ما کمک میکنن. ولی هیچوقت دقت لازم حذف نمیشه. پس در نتیجه کد همیشه وجود داره.
خوب حالا که به این نتیجه رسیدیم که هیچوقت قرار نیست از دست کد خلاص بشیم، میریم مرحله بعد، یعنی درک کد خوب و عواقب استفاده از کد بد.
مثال‌های زیادی وجود داره از عواقب استفاده از کد بد، مثلا در دهه‌ی ۸۰ یک شرکت نرم‌افزاری برنامه‌ای درست کرد که در آغاز راه با استقبال زیادی روبه‌رو شد، اما بعد از مدتی چرخه‌های انتشار‌اش شروع به طولانی‌تر شدن کرد و باگ‌ها از یک نسخه به نسخه بعدی اصلاح نشده باقی میموندن. بعد از مدتی محصول با شکست روبه‌رو شد و شرکت تولید کننده از چرخه‌ی بازار خارج شد که علت اون کد های بد بود.
همه‌ی ما با هر سطح از دانش در برنامه‌نویسی، بارها با کد بد مواجه شده‌ایم. سوال اینجاست که، اگر یک کد بد جلوی انجام کار مقاومت میکنه، پس چرا اونو بنویسیم؟
جواب : باورهای اشتباه ما از کد بد.
کد بد باعث ایجاد بههم ریختگی و اتلاف وقت در طولانی مدت میشه. کد بد باعث میشه روند روبه رشد تبدیل به روند حلزونی بشه.
یعنی با جلو رفتن و بیشتر شدن ابعاد پروژه، به هم ریختگی‌ها و وابستگی‌ها هم بیشتر میشه و در کل باعث میشه که سرعت بهبود پروژه رو به کاهش باشه.
همزمان با ایجاد بههم ریختگی‌ها، بهره‌وری تیم رو به کاهش میره. با کاهش بهره‌وری، مدیریت تصمیم میگیره که افراد جدید به تیم فنی اضافه کنه به امید افزایش بهره‌وری. ولی افراد جدید هماهنگ به طراحی سیستم نیستند. اونا فرق بین تغییری که مطابق با اهداف تعیین شده با تغییراتی که برخلاف اهداف تعیین شده رو نمیدونن. در نتیجه تحت فشار کاهش بهره‌وری، اونها هم شروع به تولید بههم ریختگی میکنن.
بالاخره کاسه صبر تیم توسعه لبریز میشه و به مدیریت اعلام میکنن که باید طراحی دوباره(Refactor) اتفاق بیفته!
مدیریت از یک طرف علاقه‌ای به خرج منابع دوباره برای طراحی نداره و از طرف دیگه هم میزان بهره‌وری فعلی‌اش هم سود جذابی بهش نمیده. در نتیجه انتخاب دیگه‌ای نداره و مجبور به اجرای، طراحی دوباره میشه.
طراحی دوباره که توسط تیم توسعه حرفه‌ای انجام میشه زمان بر و پر هزینه‌ی و بعضی وقت‌ها تا ۱۰ سال هم طول میکشه!!
نتیجه‌ای که از این داستان میشه گرفت اینه که: صرف زمان برای تمیز نگه داشتن کد نه تنها مقرون به صرفه‌اس، بلکه یک مسئله مهم برای بقایٔ حرفه‌ایه.
اولین نکته برای برخورد حرفه‌ای، مسئولیت پذیری و چرخاندن انگشت اتهام به سمت خودمان است!
شاید ما از مشتریان،مدیران،بازاریاب‌ها و دیگر اعضای تیم راجع به مسائلی مثل زمان‌بندی، تغییر نیازها حین طراحی و ... برای ایجاد کد بد بهانه داشته باشیم، ولی این مهمه که ما خودمون رو برای اون مقصر بدونیم نه کس دیگه‌ای رو.
بازاریاب‌ها برای اطلاعات مورد نظرشون برای تعهد دادن، به ما نگاه میکنن.
کاربران برای اعتبارسنجی محصول مطابق با نیازهاشون، به ما نگاه میکنن.
همچنین مدیران برای زمان بندی‌هاشون.
پس ما توی برنامه‌ریزی پروژه عمیقا شریک جرم هستیم و در مسئولیت هر شکستی سهیم هستیم، بخصوص اگه شکست‌ها ناشی از کد بد باشه.
پزشک جراحی رو درنظر بگیرین که قبل از عمل باید دست‌هاشو بشوره. طبیعیه که بیمار برای جلوگیری از اتلاف وقت بهش بگه که این کار احمقانه رو کنار بزاره و سریع‌تر بیاد برای جراحی. مطمئنا دکتر باید با اینکار مخالفت کنه چون بهتر از هرکس دیگه‌ای از عفونت و بیماری آگاهه. موافق دکتر با بیمار نه تنها غیرحرفه‌ایه بلکه جنایتکارانه هم هست. پس برای برنامه‌نویسان هم کوتاه آمدن دربرابر خواسته‌ی مدیران که خطر بهم‌ریختگی را نمیدانند، غیر حرفه‌ای است.
حالا که به این باور رسیدیم که بهم‌ریختگی یک مانع مهم است،حالا که میدونیم تنها راه سریع بودن، تمیز نگه داشتن کده، پس حالا به اینجا رسیدیم که بفهمیم چجوری باید کد تمیز بنویسیم.
اگه ندونیم معنی کد تمیز چیه، تلاش برای نوشتن کد تمیز نتیجه خوبی نداره.
کد مثله نقاشی میمونه، یعنی اینکه ما اگه قادر باشیم کد خوب یا نقاشی خوب رو از کد بد یا نقاشی بد تشخیص بدیم، به این معنی نیست که ما میتونیم کد خوب رو تولید کنیم.
نوشتن کد تمیز نیازمند رعایت هزاران تکنیک کوچیکه که از طریق اعمال فهم تمیز بودن دقیق به دست میاد.
این "حس کردن کد" کلیدیه. بعضی ها از بچگی دارن‌اش، بعضی ها باید کسب‌اش کنن. این حس نه تنها به ما اجازه میده که فرق بین کد خوب رو با بد بفهمیم، بلکه بهمون استراتژی تبدیل کد بد به خوب رو هم نشون میده.
یک برنامه‌نویس بدون حس کردن کد میتونه به یک ماژول بهم‌ریخته نگاه کنه و تشخیص بده که کد ها بد طراحی شدن ولی هیچ ایده‌ای برای تبدیل‌اش به کد خوب نداره. یک برنامه‌نویس دیگه هم که کد رو میفهمه میتونه به یک ماژول نگاه کنه و انتخاب ها و تغییرات به ذهن‌اش برسه.
خلاصه اینکه برنامه‌نویسی که کد تمیز رو مینویسه یک هنرمنده که میتونه با استفاده از یک سری از تبدیلات یک صفحه خالی رو به یک سیستم کدنویسی شده زیبا تبدیل کنه.
شاید به اندازه برنامه نویسان برای این مفهوم تعریف وجود داشته باشه، پس میریم که نظر چندتا از برنامه نویسان بزرگ و باتجربه رو بخونیم:
-من دوست دارم کدهایم زیبا و کارا باشند. منطق باید سرراست باشد و وابستگی ها در حداقل ممکن باشد تا نگهداری از کد آسان شود. رسیدگی به خطاها باید براساس یک استراتژی گام به گام تکمیل شود، کارایی باید به سمت بهینگی باشد تا افراد برای بهینه‌سازی غیراصولی، به بهم ریخته کردن کد وسوسه نشوند. کد تمیز یک کار را خوب انجام میدهد.
-کد تمیز ساده و مستقیم است. کد تمیز مثل یک نثر خوب نوشته شده است. کد تمیز هیچوقت نیاز یک طراح را مبهم نمیکند و در عوض سرشار از انتزاع پر شور و روند کنترلی واضح و مستقیم است.
-کد تمیز قابلیت خوانده شدن و بهبود داده شدن توسط توسعه دهنده‌ی دیگری غیر از توسعه دهنده اصلی کد را دارد. به این منظور تست‌های پذیرش و تست‌های واحد وجود دارد. نام‌های بامعنایی دارد. یک راه به جای چند راه برای انجام یک کار فراهم میکند. حداقل وابستگی را شامل میشود، واضح‌ترین و کمترین API را فراهم میکند و دارای کامنت مفید است.
-کد تمیز همیشه مانند این است که توسط فردی نوشته شده است که به آن اهمیت میدهد. در نتیجه شما نمی‌توانید کار مشخصی برای بهتر شدن کد انجام دهید.
-کدی تمیز است که این قوانین را به ترتیب رعایت کند:
-تمام تست‌ها اجرا شده باشد
-شامل تکرار نباشد
-تمام ایده‌های طراحی موجود در سیستم را بیان کند
-تعداد موجودیت‌ها مثل کلاس‌ها، متد‌ها،توابع و غیره در آن به حداقل رسیده‌اند
-وقتی هر روتینی که میخوانید به اندازه‌ای که انتظار دارید به نظر خوب می‌آید، شما میدانید که درحال کار کردن بر روی یک کد تمیز هستید. وقتی کد، شبیه زبانی هست که برای حل مسأله ساخته شده است، می‌توانید آنرا کد زیبا بنامید.
-عمو باب به عنوان نویسنده‌ی این کتاب، باور و اعتقاد خودشو از "کد تمیز" با ریز جزئیات(نحوه نام‌گذاری متغییر ها، توابع تمیز، کلاس‌تمیز و غیره) خواهد گفت و بابت اعتقادش هم عذرخواهی نخواهد کرد! چون به نظرش توی این نقطه از راهش، این اعتقاد قطعی و مسلم‌اش هست. درست مثل تکنیک‌های مبارزه که هیچ رزمی‌کاری در مورد بهترین روش مبارزه یا تکنیک مبارزه‌ای توافق نداره. معمولا اساتید مکتب فکری خودشون رو دارن و برای خودشون شاگرد جمع میکنن و اصولا فعالیت در یک سبک مبارزه به معنی نقض سبک‌های دیگه نیست.
عمو باب ادعای بهترین بودن را ندارد ولی در عوض ادعای اینو داره که اگه ما از این روشها پیروی کنیم، از فوایدی بهره‌مند میشیم که اون شده.
کتاب‌های هنری قول نمی‌دهند که از شما یک هنرمند بسازن، در عوض هدف اونها ارئه‌ی ابزار‌ها، فرآیندها و روش‌های فکری است که سایر هنرمندان استفاده میکنند. بنابراین این کتاب هم قول نمیده که از ما برنامه‌نویس خوب بسازه. نمیتونه به ما قول بده که کد خوب رو حس و درک‌اش کنیم در عوض نشان دهنده‌ی فرآیند فکری برنامه‌نویسان خوب و فوت‌و‌فن‌ها و روشها و ابزارهایی که اونها استفاده میکنن.
درست مثل یک کتاب در مورد هنر، این کتاب سرشار از جزئیات است، و ما روش تبدیل شدن کد بد به خوب رو میبینیم و بعد از اون نوبت خود ماست تا این روش‌هارو پیاده سازی کنیم?
و تمام...
تا قسمت بعدی خدانگهدار✋
(آیدی اینستاگرام من: hossein._.no1)
