عنوان عجیبیه نه؟ خب، موضوعی که میخوایم بحث کنیم راجبش اونقدر عجیب نیست ولی.
ما هدفمون از برنامه نویسی اینه که کدهایی رو بنویسیم که ماشین اونارو بفهمه درسته؟ خب ولی نباید تنها هدفمون این باشه. کدی که ما مینویسیم باید خود ما انسان ها هم قابل فهم و خوانا باشه. طوری نباشه 1 سال بعد برگردیم بالای کدی که خودمون نوشتیم و هیچی نفهمیم از ساختار و کدی که طراحی کردیم.
هدف از کلین کد ( کد تمیز ) اینه که کدمون رو به نحوی بنویسیم که برای انسان هم قابل فهم و خوانا باشه و در نتیجه این خوانا بودنه، کد ما توسعه پذیر تر میشه و راحت میشه نگهداریش کرد.
یک حقیقتی در کدنویسی هست به نام نسبت 10 به 1. یعنی ما 10 برابر وقتی که برای نوشتن یک کد میذاریم، وقت برای خوندنش میذاریم؛ و این واقعا عین حقیقته. مثلا وقتی میخواید یه آپدیتی انجام بدید یا ریفکتوری انجام بدید و یا مواردی از این قبیل؛ قبل از اینکه کد جدید رو بنویسید میرید و کل کدهاتون رو میخونید و یه راه حلی برای ایده جدیدتون میسازید. پس اینکه کدتون چطوری نوشته شده و چقدر برای انسان ها خواناست اهمیت بالایی داره.
حالا فرض بر اینکه یک کد کثیف زدید و بعدها میخواید دیباگش کنید یا ازش نگهداری کنید در هر حال. این پروسه چقدر میتونه زمانبر و پر مشقّت باشه براتون وقتی کدتون هیچ ساختار منظمی نداره و خواناییش نزدیک صفره؟ مثل تفاوت یه انباری منظم و یه انباری بهم ریخته هست. فرض کنید داخل هر انباری دنبال یه کارتن مشخص هستید. قطعا داخل انباری ای که همه چی منظمه و سرجاشه زودتر به نتیجه میرسید تا یه انباری شلوغ و بی سر و سامان.
نرم افزارها بر خلاف تصور خیلی ها، مخلوقاتی زنده حساب میشن که ماها میسازیمشون. این نرم افزارها در طول زمان تغییر میکنن، آپدیت میشن، فیچرهای جدید بهشون اضافه میشه، فیچرهای قدیمی حذف میشن و ...
کد کثیف به شما اجازه کارکرد ماژولار نمیده. اینو براتون خیلی سخت میکنه. در حالی که کد تمیز کاملا ماژولار فرندلیه و هرموقع و هرزمان میتونید چرخه زندگی این نرم افزار رو دستکاری کنید.
پس برای توسعه یک محصول و نرم افزار واقعی و حرفه ای، تمیز بودن کد و خوانا بودنش اهمیتش یه چیزی مثل مرگ و زندگیه. باید جدیش گرفت !
یه چک لیست میخوام بهتون بدم خیلی کوتاه و مختصر و مفید و باحال.
توی کدتون این موارد رو چک کنید و اصلاح کنید و سعی کنید از این به بعد این مواردو توی ذهنتون داشته باشید موقع کدنویسی.
خیلی فرق هست بین متغیر X و متغیر daysSinceLastLogin. و حتی متغیر daysSinceLastLogin هم باز خیلی میتونه متفاوت باشه نسبت به موارد مشابه خودش مثل dayLastLogin. اغلب از اسامی طولانی برای متغیرها میترسن و فکر میکنن اشتباهه در حالی که اگر نیاز باشه باید اسم رو طولانی بنویسیم تا بشه کاملا اون متغیر رو در قالب اسمش درک کرد. حسابی برای انتخاب اسامی متغیر هاتون وقت بذارید.
یکی از قوانین محبوب و پایه ای مهندسی نرم افزار و برنامه نویسی شئ گرا که میگه هر تابع، متود یا کلاس باید یک وظیفه مشخصی داشته باشن. یعنی اگر یه تابع برای Launch url دارید، نباید پروسه parse کردن url داخل این متود انجام بشه. چون اسم تابع لانچ کردنه و وظیفه ش فقط لانچ کردن یه آدرس و لینکه. پس parse کردن رو باید به یه متود دیگه ای تبدیل کرد به صورت مستقل.
جاهایی که در کد کامنت میذارید نباید یک قصه طولانی از نحوه عملکرد یه متود یا تابع باشه. صرفا باید یه چرا و توضیح کلی رو بیان کنه. مثلا "verify user after login //"
داخل کد اگر مینویسی مثلا status.code == 404، اون 404 چیه؟ یا مثلا بدترش، status == 2، اون 2 دقیقا چیه؟ عدد جادویی که نیست؛ پس تعریف کن اینارو در قالب متغیر. مثلا const NOT_FOUND_STATUS_COD = 404 یا const int activeStatus = 2.
حلقه های تو در تو کاربردی هستن اما نباید برنامه توی حلقه ها غرق شه. هرموقع دیدی کدت داره عین نوک پیکان تیز میشه "<" یعنی داری زیادی از این حلقه های تو در تو استفاده میکنی و توی یه جهنم گیر افتادی.
بیاید تمیزتز کد بزنیم
💡 شما چه حسی نسبت به کدهای کثیف دارید؟
#فلاتر #برنامه_نویسی #کد_تمیز #مهندسی_نرم_افزار #آموزش
