چرا درگیر کد کثیف و پروژه اسپاگتی میشیم!!؟

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

در ادامه به این چندتا سوال میخوایم جواب بدیم:

• کد کثیف به چه کدی گفته میشه؟
• پروژه نرم‌افزاری اسپاگتی؟
• راه حل چیه؟

کد کثیف به چه کدی گفته میشه؟

• غیرقابل فهم بودن: پیچیدگی غیرضروری و معماری نامناسب
• کدهای تکراری: عدم توجه به قابل استفاده بودن کدها(متدها، کلاس‌ها، ...)
• نبود تست: امکان نوشتن تست وجود نداشته باشه یا زمانی برای تست نویسی گذاشته نشود.
• غیرقابل اعتماد: وجود اشکالات مختلف و سخت بودن دیباگ و رفع مشکل.

خیلی از برنامه‌نویس‌ها زمانی که یک پروژه جدید رو شروع میکنن، حساسیت خیلی زیادی برای نوشتن کدهای تمیز، قابل نگه داری و قابل توسعه دارن، ولی چی میشه که اون حساسیت‌ها به مرور کم میشه و به یکسال نکشیده پروژه تبدیل به یک اسپاگتی بزرگ میشه؟

متاسفانه دلایل زیادی وجود داره که منجر به این اتفاقات میوفته که به بعضی از اون موارد اشاره میکنم:

• کمبود مهارت برنامه‌نویس: کمبود مهارت یا عدم درک کافی به اندازه و آینده پروژه نرم‌افزاری(نمیدونیم قراره چقدر بزرگ بشه این پروژه).
• عدم مدیریت مناسب زمان: انتخاب ددلاین‌های نزدیک بدون توجه به عمق کار و نادیده گرفتن نقاط تاریک هر پروژه یا تسک.
• عدم وجود قرارداد برای سبک کدنویسی: وقتی یک استاندارد یا قرارداد تیمی برای یک پروژه وجود نداشته باشه احتمال زیادی وجود داره که هر برنامه‌نویس به سبک شخصی خودش کد بنویسه و این باعث بی نظمی و یکپارچه نبودن کدهای پروژه میشه.
• تغییرات زیاد: خیلی مواقع درگیر پروژه‌هایی میشیم که خود مدیر محصول هم تعریف درستی از پروژه نداره و شفاف نیست براش، بخاطر این موضوع، ناخواسته مجبور به تغییرات زیاد با بازه زمانی کم میشیم که باعث بوجود اومدن بدهی‌های فنی زیادی میشیم.
• مدیریت ضعیف: عدم وجود مستندات کافی، عدم وجود ارتباطات مناسب بین هم تیمی و بین تیمی

پروژه نرم‌افزاری اسپاگتی؟

خروجی موارد بالا میشه یک پروژه نرم‌افزاری به شکل اسپاگتی که ساختار درستی نداره و اجزای پروژه در هم و بر هم و پیچیده شده.

اشکالات پروژه‌های اسپاگتی:

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

راه حل؟

اولین و آسون‌ترین تصمیم معمولا ایجاد یک پروژه دیگه‌س که خیلی از برنامه‌نویس‌ها این تصمیم رو میگیرن.

ولی آیا راه حل بهتری هم هست؟ بنظر من بله هست، طبق تجربه‌های مختلفی که توی پروژه‌های نرم‌افزاری داشتم راه حل ساخت یک پروژه مجدد با رویکرد کد تمیز بدون در نظر گرفتن نقاط ضعف پروژه قبلی هم منجر به شکست شده(تبدیل شدن به اسپاگتی در طولانی مدت)، تاکید من روی زمان طولانی مدته چون در کوتاه مدت هم باز حساسیت زیادی به خرج میدیم، تو ریویوها سختگیری بیشتری داریم، ولی به مرور زمان باز شاهد کدهای کثیف هستیم که گاهی این حس به وجود میاد که باز برگشتیم سر نقطه اول.

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

راه حل دوم تمیز کردن پروژه کثیف فعلی میتونه چالش های زیادی برامون داشته باشه بعلاوه هزینه زمانی و مالی زیادی برای صاحب پروژه، ولی مزیت‌هایی داره که بد نیست مرور کنیم:

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

جمع‌بندی:

بدهی‌های فنی، کد کثیف و پروژه‌های اسپاگتی جز مواردی هستن که باهاشون به صورت روزانه سرکار داریم، این خوبه بشناسیم و بدونیم که چه مشکلاتی تو پروژه داریم و مطمئن بشیم که همه تیم در جریان هستن، برنامه کوتاه و بلند مدت برای رفع این مشکلات داشته باشیم، چون اگه برنامه‌ای برای حل این مشکلات وجود نداشته باشه، هم تیم درگیر توسعه فرسایشی میشه که در طولانی مدت آثار مخربی مانند جدا شدن برنامه‌نویس از تیم و عقب افتادن فرد از رشد فنی میشه و هم صاحب محصول یا پروژه هزینه‌های گذافی رو باید متقبل بشه برای توسعه و نگهداری پروژه.

در مورد بدهی‌های فنی اینجا بیشتر توضیح دادم: نگاهی به بدهی فنی پروژه های نرم‌افزاری

منابع:

https://en.wikipedia.org/wiki/Technical_debt

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

https://en.wikipedia.org/wiki/Code_smell

https://stackoverflow.blog/2023/12/27/stop-saying-technical-debt/

https://en.wikipedia.org/wiki/Spaghetti_code