- هر یک از مفاهیم زیر را در حد یک خط توضیح دهید.
- کد تمیز: کدی که به راحتی قابل خواندن، فهمیدن و تغییر است. ما از best practice ها برای داشتن کد تمیز استفاده می کنیم.
- بدهی فنی: توضیح می‌دهد که وقتی کدی را با کمبود منابع (مانند زمان، نیروی فنی و دانش کافی) توسعه می‌دهیم، چه نتایجی حاصل می‌شود و باید بعداً آن کد را اصلاح کنیم تا کد تمیز داشته باشیم.
- بوی بد: هر مشخصه ای در source code یک برنامه که احتمالاً مشکل جدی تری را نشان می دهد.
- طبق دسته‌بندی وبسایت refactoring.guru، بوهای بد کد به پنج دسته تقسیم می‌شوند. در مورد هر کدام از این پنج دسته توضیح مختصری دهید.
این بوها معمولاً زمانی به وجود می‌آیند که ما کلاسها یا داده‌هایی داریم که کار با آنها به دلیل مسائل مختلف مانند توابع طولانی، کلاسهای بیش از حد بزرگ و ... بسیار سخت است. معمولاً این نوع مسائل زمانی ایجاد می‌شوند که ما به refactoring دوره‌ای روی کدها توجه نمی‌کنیم یا تغییرات را به روشی کارآمد مدیریت نمی‌کنیم، این رویکرد به انباشت منطق و پیچیدگی ختم می‌شود. بنابراین بعداً نمی توانیم از کدهای پیاده سازی شده به صورت کارآمد و ساده استفاده کنیم. همچنین باید به release and reuse granulation توجه کنیم؛ به این معنی که باید در نظر داشته باشیم که چه چیزی را اجرا می کنیم و بعداً چگونه از آن استفاده می کنیم.
این بوها معمولاً زمانی که قوانین شی گرایی را به درستی رعایت نمی کنیم بوجود می‌آیند. مانند فیلدهای موقت، فرض کنید از برخی فیلدهای موقت در داخل کد استفاده می کنیم که فقط در شرایط خاص مقادیر را می پذیرند. بنابراین وقتی سعی می کنیم از آنها خارج از محدوده آنها استفاده کنیم، ممکن است با مقدار null روبرو شویم. یا از سوی دیگر ممکن است از switch-case به عنوان حالت هایی استفاده کنیم که از الگوها به روشی نامناسب استفاده می کنند. یا ممکن است دو کلاس مجزا داشته باشیم که کارهای یکسانی را انجام می دهند اما در تعریفشان مجزا هستند.
این نوع بوها زمانی ایجاد می شوند که ما نیاز به تغییر بسیاری از قسمت های کد پس از تغییر یک قسمت خاص داریم. مانند Shotgun Surgery، زمانی اتفاق می افتد که ما یک قسمت از یک کد را تغییر می دهیم، لازم می‌شود که چندین مکان را در کلاس های مختلف تغییر دهیم تا کد ثابت بماند. یا Divergent Change داریم به این معنی که وقتی باید یک تغییر را در یک کلاس ایجاد کنیم، متقاعد می شویم که کارهای اضافی مانند تعریف چندین متد در آن کلاس انجام دهیم.
گاهی اوقات ما برخی از practice ها را دنبال می‌کنیم که به کدهای ناپاک ختم می‌شوند و به گونه‌ای برنامه‌نوسیس می‌کنیم که کدهای بی‌فایده‌ای داریم که می‌توان آنها را مجدداً اصلاح کرد یا ممکن است به طور کامل حذف کرد. مانند گذاشتن comment که نباید نحوه پیاده سازی کد را توضیح دهد و کد باید self explainer باشد. یا ممکن است duplication داشته باشیم که باعث می شود کدها به سختی خوانده شوند. یا گاهی اوقات ما کلاس هایی داریم که می توان آنها را در کلاس دیگری ادغام کرد زیرا از همان منطق پیروی می کنند اما کلاس های جداگانه از آنها یک کلاس lazy و useless ایجاد می‌کند.
وقتی متوجه می‌شویم که در کد ما کلاس‌هایی وجود دارد که بین دو کلاس دیگر قرار دارند و بدون هیچ تأثیری از داده‌های انتقالی استفاده می‌کنند، باید مشکوک شویم که coupler در کد ما وجود دارد. یکی از معروف ترین آنها، Message Chaining است؛ چندین کلاس داریم که مانند یک زنجیره روی یک منطق ترتیبی عمل می کنند. اما کلاس وسط به جای برگرداندن آنچه که کلاس اول نیاز دارد، کل شیء کلاس اول را به کلاس سوم منتقل می کند. بنابراین، نیازی به آن نیست و فقط باعث پیچیدگی در کد می شود.
- یکی از انواع بوهای بد، Lazy Class است.
- این بوی بد در کدام یک از دسته‌بندی‌های پنج‌گانه قرار می‌گیرد؟
Dispensables
- برای برطرف‌کردن این بو، استفاده از کدام بازآرایی‌ها پیشنهاد می‌شود؟
Inline Class and Collapse Hierarchy
- در چه مواقعی باید این بو را نادیده گرفت؟
در برخی مواقع از این کلاسها برای پیاده‌سازی در آینده استفاده می‌شود.
- در وبسایت 29 بوی بد کد نامبرده شده است. سعی کنید 10 بوی بد را در پروژه تبدیل کننده مدل به سی پیدا کنید و به آن اشاره کنید.
تابع generatePhase2 از کلاس Phase2CodeFileManipulator تعداد خطهای زیادی دارد و بنظر switch-case آن می‌توانست بهتر هندل شود.