کد تمیز گلی از گل های گیتهاب است

به نام خداوند کدهای پاک

خانه ی دل ما را از کرم، عمارت کن!
پیش از آنکه این خانه رو نهد به ویرانی
(شیخ بهایی)

بعد از چند ماه سلام ?

اواخر تابستون بود که می خواستم یک مطلب درمورد یکی از پکیج های فلاتر بنویسم که حوادثی پیش اومد که نشد ? حدود یک ماه پیش تصمیم گرفتم در اولین فرصت به اون تصمیم جامه عمل بپوشونم که به یک پروژه برخوردم که تصمیم گرفتم موضوع صحبت رو موقتا عوض کنم ? خلاصه که این نوشته برای من مثل حبسیه اس برای ملک الشعرا.. ?

پروژه کذایی از این قرار بود که باید UI یک اپلیکیشن توسعه یافته رو rebuild می کردم که کار عجیبی هم نبود.

قبلا مقداری در جريان پروژه بودم که مثلا از cubit استفاده شده، نحوه پیاده سازی api ها به چه صورت فاجعه باره. اما سمت view رو ندیده بودم که ای کاااش میشد برم عقب، ای کاش ندیده بودمت !

الآنی که دست به کیبورد شدم لازم دونستم یک سری نکاتی رو بگم که اگر معدود فلاتر دولوپر هایی داریم که این جوری نرم افزار توسعه میدن برن یه گوشه بشینن و به کثیف کاری هاشون تو کد فکر کنن.. ?

این همه پریشانی بر سر پریشانی…

خب خیلی هامون می دونیم که آنکل باب مهربان یک کتاب داره به اسم clean code که به تفصیل توضیح داده کجا و چجوری کدهای شیک بزنیم و احادیث زیادی در باب مطالعه این کتاب اومده. علاوه بر این، یک اصطلاح دیگه داریم به اسم clean architecture که اگه در جریانش هستید که آفرین! اگه هم نه که برادرمون گوگل حرف در این مورد زیاد داره. از Chat GPT هم می تونید بپرسید ?. مورد سوم هم داخل فریمورک فلاتر قابل رؤیته؛ میدونید که اساس این فریمورک بر پایه widgetها بنا شده. از ب بسم الله که شروع به توسعه می کنیم یک widget می سازیم و همین فرمون رو ادامه می دیم.

با عنایت به این ۳ اصل اساسی میریم که اون کد رو نقد کنیم.. ? از شما به عنوان یک توسعه دهنه فهیم و محترم انتظار میره که جوری نرم افزار رو توسعه بدید که بعدا مورد لطف بقيه قرار نگیرید! نرم افزار و اون کدی که براش نوشته میشه همچون فرزند شماست؛ نباید جوری فرزندتون رو بار بیارید که بعدا نتونید جمعش کنید! خشت اول رو باید درست بذارید که می چرخه زمونه، اینجور نمی مونه!

خب برگردیم به نقد کد..

• شما موقع توسعه اپ تون به ویجت هایی برمیخورید که ویژگی های مشترکی دارند و تکرار می شن و مثلا ممکنه تفاوتش در یک title باشه. مثل دکمه ای در چندین جای اپ وجود داره و تفاوتش مثلا فقط در عنوان و عملکردش هست. اینجا عقل سلیم میگه این ویجت رو extract یا استخراج کن و مثلاً عنوان و فانکشن مربوط به onTap ش رو به عنوان ورودی در سازنده دریافت کن. تا اگه یه روز خواستی یک تغییری در ظاهرش ایجاد کنی یک جا رو فقط بخوای عوض کنی. یا همون اصل DRY (Don’t Repeat Yourself). علاوه بر اون کدت هم خواناتره؛ ۴ صباح دیگه اومدی پاش نشستی بهتر یادت میاد اینا چی ان اونا کدومن ?
• نکته بالا تا حدی درمورد تم برنامه هم صادقه؛ اگر فرضاً تمامی TextField های برنامه borderRadius یکسان دارند این رو باید توی Theme برنامه یک بار برای همیشه تعریف کنی و خلاص! رنگ های برنامه هم قس علی هذا ..
• در هر زبان برنامه نویسی یک استایل برای نام گذاری ها وجود داره؛ که بهتر و زیبا تره که رعایت بشه. یعنی چی؟ مثلا میخوای به کلاسی که نوشتی اسم بدی باید به صورت UpperCamelCase باشه، به ثابت های میخوای اسم بدی lowerCamelCase طور اسم بده. شاید فکر کنین چه فرقی داره، مهم اینه کار کنه! درسته کار میکنه ولی تمیزز نیست دوست عزیز!? جهت کسب اطلاعات بیشتر به داکیومنت خود فلاتر مراجعه بنما!
• مطلب بعدی ترکیب چندین اصل هست؛ وقتی شما می خواهید تابعی رو بنویسید، به چندین نکته باید توجه کنید:
• اصل اول solid در مورد تک مسئولیتی صحبت میکنه؛ اما شما اگه عاقل باشی متوجه میشی که این اصل رو میتونی روی توابع هم پیاده کنی و تعمیم بدی؛ درکتاب کلین کد هم بهش پرداخته شده. که یک تابع باید یک کار مشخص انجام بده؛ همچنین نباید تابعی بنویسی که ۳۰ - ۴۰ خطه! عمو باب گفته حدود ۱۵ خط حداکثر باشه ?
• حالا ممكنه در این اثنا فاز خیلی clean بودن برداری و بیای موقع پیاده سازی ui به ازای هر ویجت یک متغیر تعریف کنی، مثلا:

var nameTextField = TextFiled();
var phoneTextField = TextFiled();
//and so on

بعدش بیای متد build رو پیاده سازی کنی و اینا رو بهش بدی. خدمتت عرض کنم که اینم اشتباهه ?! هیچ جا چنین کاری انجام نشده! کار عاقلانه اینه اون رو به صورت method یا یک ویجت extract کنید و تامام.

• در آخر، مقیاس نقد رو یکم بالاتر می برم .. در هر پروژه درست و حساب یک معماری وجود داره. مثلا اگه پروژه تون با Get نوشته شده با MVC میتونید مجلسی تر بنویسیدش. لزوم وجود معماری بر همگان واضحه و هدف این مقاله بیان اهمیت اون نیست! در ابتدایی ترین حالت یک، پروژه باید یک ساختار معقول و منطقی داشته باشه که مشخص باشه هرچیزی کجاست. چه معنى داره model هر صفحه کنار همون صفحه باشه! چرا ساخت مدل، ارسال رکوئست، دریافت پاسخ و مدیریتش همگی توی onPressed باشه ?؟! اون cubit هویجه پس؟! Datasource کشکه؟!

این طلب گر از تو و از من خطاست
گر بمیرم این دم از غم هم رواست
(عطار)

امیدوارم این نکات براتون مفيد باشه و کمک بکنه کدهایی بنویسید که عاقبت بخیر بشید ? مرسی از توجه تون؛ اشتراک گذاری فراموش تون نشه ?

یقیناً در این نشانه هایی است برای مردمی که می اندیشند
(سوره روم، آیه ۲۱)