کد آشغال و به‌هم‌ریختگی در پروژه‌های موبایل — نشانه‌ها و بازآرایی

کد آشغال در توسعه چیست

کد آشغال (همچنین spaghetti code، به‌هم‌ریختگی، big ball of mud) — استعاره‌ای برای پایگاه کدی است که ساختار خود را از دست داده و به گره‌ای درهم از وابستگی‌ها تبدیل شده است. در چنین کدی هر تغییری در یک مکان جای دیگر را خراب می‌کند و افزودن قابلیت جدید به مأموریتی پرریسک تبدیل می‌شود.

در توسعه موبایل کد آشغال به ویژه بحرانی است: برنامه‌ای که بر روی «به‌هم‌ریختگی» ساخته شده شروع به کندی می‌کند، در دستگاه‌های قدیمی کرش می‌کند و به سختی از بازبینی کد عبور می‌کند. پروژه iOS بدون معماری ممکن است به دلیل ناپایداری از App Review عبور نکند.

بر اساس داده‌های Stripe، توسعه‌دهندگان تا ۴۲٪ از زمان کاری خود را صرف خواندن و درک کد موجود می‌کنند. در پروژه‌های با کد آشغال این شاخص از ۶۰٪ فراتر می‌رود که توسعه را بسیار ناکارآمد می‌کند.

ریشه اصطلاحات

Spaghetti code (کد اسپاگتی) — قدیمی‌ترین اصطلاح که در دهه ۱۹۷۰ ظهور کرد. این اصطلاح کدی با انتقال‌های کنترلی آشوبناک را توصیف می‌کند که یادآور ماکارونی درهم پیچیده است.

Big ball of mud (گلوله بزرگ گلی) — اصطلاحی که توسط برایان فوت و جوزف یودر در سال ۱۹۹۷ برای توصیف سیستم‌های بدون معماری مشخص که به طور آشوبناک «رشد» می‌کنند، معرفی شد.

چرا کد آشغال برای کسب‌وکار خطرناک است

کد آشغال عرضه قابلیت‌های جدید به بازار را کند می‌کند. تیم وقت خود را صرف ایجاد ارزش نمی‌کند، بلکه صرف تلاش برای فهمیدن نحوه کار کد موجود و نشکستن چیزی می‌کند.

بر اساس داده‌های McKinsey، شرکت‌های با کیفیت پایین کد ۲۰-۴۰٪ بیشتر برای نگهداری محصول هزینه می‌کنند و سرعت عرضه قابلیت‌های جدید ۲-۳ برابر کمتر از شرکت‌های با کیفیت بالای کد است.

نشانه‌های کد آشغال و چگونه آن را تشخیص دهیم

تشخیص کد آشغال از طریق مجموعه‌ای از نشانه‌های عینی امکان‌پذیر است که برخی از آنها به طور خودکار اندازه‌گیری می‌شوند. هر چه نشانه‌های بیشتری مطابقت داشته باشند — مشکل جدی‌تر است.

در صنعت از معیارهای کیفیت کد مانند Halstead Complexity، Maintainability Index و Technical Debt Ratio استفاده می‌شود. آگاهی از این معیارها به ارزیابی عینی وضعیت پایگاه کد کمک می‌کند.

کپی-پیست (تکرار کد)

رایج‌ترین نشانه کد آشغال — بلوک‌های تکراری کد. به جای استخراج تابع مشترک، توسعه‌دهندگان کد را با حداقل تغییرات از جایی به جای دیگر کپی می‌کنند.

سطح معمولی تکرار تا ۵٪ در نظر گرفته می‌شود. اگر تکرار از ۱۵٪ فراتر رود — این یک سیگنال جدی است. ابزارهایی مانند Simian و PMD Copy Paste Detector به شناسایی خودکار کپی-پیست کمک می‌کنند.

متدها و کلاس‌های طولانی

متدی با طول بیش از ۱۰۰ خط — نشانه آشکار کد آشغال. چنین متدی معمولاً کارهای زیادی انجام می‌دهد و اصل مسئولیت واحد (Single Responsibility) را نقض می‌کند.

کلاس‌های با بیش از ۱۰۰۰ خط کد نیز مشکل‌ساز هستند. آنها قابلیت‌های نامرتبطی دارند که تست، درک و تغییر کد را دشوار می‌کند.

پیچیدگی سیکلوماتیک بالا

پیچیدگی سیکلوماتیک مک‌کیب (Cyclomatic Complexity) — معیاری که تعداد مسیرهای مستقل در کد را نشان می‌دهد. مقدار بالای ۱۵ مشکل‌ساز در نظر گرفته می‌شود.

متدهای با پیچیدگی بالای ۳۰ — «منطقه فاجعه». آنها شامل شاخه‌های زیادی هستند و بدون تحلیل عمیق نمی‌توان آنها را تست یا درک کرد.

دلایل پیدایش کد آشغال

کد آشغال «خود به خود» به وجود نمی‌آید — همیشه نتیجه فرآیندها و تصمیم‌های خاص در تیم است. درک دلایل امکان جلوگیری از ظهور آن در آینده را فراهم می‌کند.

بر اساس داده‌های JetBrains Developer Ecosystem 2024، ۶۷٪ توسعه‌دهندگان اعتراف می‌کنند که به دلیل کمبود زمان کد بدتری از آنچه می‌توانند می‌نویسند. این دلیل اصلی انباشت بدهی فنی است.

عجله و مهلت‌های تحویل

رایج‌ترین دلیل — مهلت‌های فشرده. تیم کد را «هر طور شده» می‌نویسد، فقط برای رسیدن به مهلت تحویل. بازآرایی، تست‌ها و بازبینی کد به «بعد» موکول می‌شوند.

مشکل این است که «بعد» هرگز نمی‌آید — در اسپرینت بعدی مهلت‌های جدیدی ظاهر می‌شوند و بدهی فنی مانند گلوله برفی انباشته می‌شود.

نبود بازبینی کد

بدون بازبینی کد، هر توسعه‌دهنده به سبک خود می‌نویسد، از الگوهای خود استفاده می‌کند و «تله‌های» خود را به جا می‌گذارد. با گذشت زمان پایگاه کد یکپارچگی خود را از دست می‌دهد.

تیم‌هایی که بازبینی اجباری کد را برای هر درخواست ادغام تمرین می‌کنند، بر اساس تحقیقات SmartBear 2024، ۶۰٪ نقص‌های کمتری در محیط تولید دارند.

معماری ضعیف از ابتدا

اگر پروژه بدون معماری مشخص شروع شود، کد آشغال اجتناب‌ناپذیر است. اولین «راه‌حل‌های سریع» پایه‌ای می‌گذارند که بعداً ساختن چیزی با کیفیت روی آن دشوار است.

در توسعه موبایل انتخاب معماری (MVC، MVP، MVVM، Clean Architecture) باید تصمیمی آگاهانه باشد که قبل از شروع نوشتن کد گرفته شود، نه نتیجه تکامل.

روش‌های مقابله با کد آشغال

مقابله با کد آشغال نیازمند رویکرد سیستماتیک و انضباط کل تیم است. هیچ ابزار یا روش واحدی وجود ندارد که مشکل را حل کند — مجموعه‌ای از اقدامات لازم است.

اصل اصلی — جلوگیری از کد آشغال در مرحله نوشتن، نه اصلاح آن بعداً. پیشگیری همیشه ارزان‌تر از بازآرایی «به‌هم‌ریختگی» موجود است.

استانداردهای کدنویسی

سبک یکپارچه کد — پایه جلوگیری از کد آشغال. استانداردهای کدنویسی (Code Style) باید مستند شده و به طور خودکار توسط لینترها بررسی شوند.

برای iOS از SwiftLint استفاده می‌شود، برای Android — Ktlint و Detekt. تنظیم قوانین در فایل پیکربندی امکان رد خودکار درخواست‌های ادغام نقض‌کننده استانداردها را فراهم می‌کند.

بازآرایی منظم

بازآرایی — رفع باگ نیست، بلکه بهبود ساختار کد بدون تغییر رفتار آن است. باید بخشی منظم از فرآیند توسعه باشد، نه یک پروژه جداگانه.

توصیه می‌شود ۲۰٪ از زمان هر اسپرینت به بازآرایی و پرداخت بدهی فنی اختصاص یابد. این کار از انباشت «به‌هم‌ریختگی» جلوگیری می‌کند و سرعت تیم را در بلندمدت حفظ می‌کند.

بازبینی اجباری کد

هر درخواست ادغام باید حداقل توسط یک توسعه‌دهنده بازبینی شود. بازبینی کد نه تنها باگ‌ها، بلکه نقض معماری، سبک و منابع بالقوه کد آشغال را نیز شناسایی می‌کند.

یک روش خوب — چک‌لیست بازبینی کد شامل بررسی کپی-پیست، طول متدها، پیچیدگی سیکلوماتیک و پوشش تست. بدون چک‌لیست بازبینان تا ۵۰٪ مشکلات را از دست می‌دهند.

ابزارهای پاکسازی پایگاه کد

ابزارهای مدرن تحلیل کد امکان شناسایی خودکار کد آشغال، اندازه‌گیری بدهی فنی و کنترل کیفیت را فراهم می‌کنند. ادغام این ابزارها در خط لوله CI/CD نظارت مداوم را تضمین می‌کند.

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

تحلیلگرهای ایستا

• SonarQube — پلتفرم پیشرو تحلیل کیفیت کد، از ۳۰+ زبان پشتیبانی می‌کند و معیارهای Technical Debt Ratio را ارائه می‌دهد
• ESLint — استاندارد برای JavaScript و TypeScript، از طریق فایل‌های پیکربندی تنظیم می‌شود و در IDE ادغام می‌شود
• SwiftLint — ابزار اجباری برای پروژه‌های iOS، مطابقت با Swift Style Guide را بررسی می‌کند

بر اساس داده‌های SonarSource، تیم‌های استفاده‌کننده از تحلیل ایستا تعداد باگ‌های تولید را در سه‌ماهه اول پس از پیاده‌سازی ۳۰٪ کاهش می‌دهند.

ابزارهای اندازه‌گیری معیار

CodeClimate و Codacy — پلتفرم‌هایی که معیارهای کیفیت کد را تجمیع، پویایی را ردیابی و «نقاط داغ» — فایل‌های با بیشترین بدهی فنی را نشان می‌دهند.

برای پروژه‌های Android، Detekt بیش از ۱۰۰ قانون تحلیل داخلی از جمله بررسی پیچیدگی سیکلوماتیک، طول متدها و تکرار کد ارائه می‌دهد.