إعادة هيكلة كود Swift: متى تكون ضرورية وكيفية القيام بها بشكل صحيح

كودك يعمل، لكن هذا ليس سببًا لعدم لمسه

لقد كتبت تطبيقًا، وهو يعمل، والعملاء راضون، ولا تتعطل عمليات البناء. قد يبدو أنك تستطيع التنفس والانتقال إلى الميزات الجديدة. ولكن داخل قاعدة الكود يوجد وحش فرانكنشتاين: دوال بطول 300 سطر، نسخ ولصق، منطق معقد، وأرقام سحرية متناثرة في جميع أنحاء المشروع. إذا كنت قد أمسكت بنفسك يومًا تفكر "من الأفضل عدم لمس هذه الفئة وإلا سينهار كل شيء" — فإن إعادة هيكلة كود Swift ليست مجرد توصية لك، بل ضرورة حياتية.

في هذه المقالة، سنناقش متى يستحق الأمر حقًا البدء في إعادة الهيكلة، ومتى يكون من الأفضل ترك الكود كما هو. سأعرض أمثلة محددة بلغة Swift يمكنك تطبيقها اليوم. ونعم، لا ماء — فقط ممارسة.

ما هي إعادة الهيكلة وما ليست كذلك

لنبدأ بالأساسيات. إعادة هيكلة كود Swift هي عملية تغيير البنية الداخلية للبرنامج دون تغيير سلوكه الخارجي. أنت لا تضيف وظائف جديدة، ولا تصلح الأخطاء (على الرغم من أنك غالبًا ما تجدها على طول الطريق). أنت فقط تجعل الكود أنظف وأكثر وضوحًا وأسهل للصيانة.

من المهم أن تفهم: إعادة الهيكلة ≠ إعادة الكتابة من الصفر. إذا كنت ترغب في التخلص من المشروع بأكمله والبدء من جديد باستخدام SwiftUI مع بنية TCA — فهذه ليست إعادة هيكلة، بل إعادة كتابة. وإعادة الكتابة، كما تظهر التجربة، تنتهي بالفشل في 80% من الحالات.

متى يتم إعادة هيكلة كود Swift: ثلاث إشارات مؤكدة

1. قاعدة الثلاثة (Rule of Three)

إذا كنت تنسخ نفس الجزء من الكود للمرة الثالثة — فهذه إشارة. ليس في المرة الثانية، بل في الثالثة تحديدًا. المرة الأولى — حسنًا، لقد حللت المشكلة. المرة الثانية — مشكوك فيها بالفعل، ولكن يمكن تبريرها بالعجلة. المرة الثالثة — كفى، اكتب حلاً عامًا.

// سيء: نسخ ولصقfunc formatUserName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

func formatProductName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

// جيد: دالة موحدةfunc formatDisplayName(_ name: String) -> String {    return name.trimmingCharacters(in: .whitespaces).capitalized}

2. "رائحة" الدوال الطويلة

إذا كانت الدالة لا تتناسب مع شاشة الهاتف — فهذه مشكلة. في مجتمع Swift، من المعتاد استهداف 15-20 سطرًا لكل دالة. بالطبع، هناك استثناءات (حسابات معقدة)، ولكن في 95% من الحالات، الدالة الطويلة هي علامة على أنها تفعل الكثير.

3. الاختبار يتحول إلى جحيم

عندما تحتاج لاختبار دالة واحدة إلى محاكاة 5 خدمات، وإعداد قاعدة بيانات، وقراءة ملف من القرص — فهذه علامة حمراء. إعادة هيكلة كود Swift يجب أن تجعل قاعدة الكود الخاصة بك أكثر قابلية للاختبار. إذا كانت كتابة الاختبارات مؤلمة الآن — فهذا يعني أن البنية تطلب التغيير.

أمثلة عملية لإعادة هيكلة Swift

دعونا نلقي نظرة على المواقف الحقيقية التي يواجهها كل مطور iOS.

مثال 1: التخلص من الأرقام السحرية

الأرقام السحرية هي قيم رقمية حرفية لا يُفهم معناها بدون سياق. إنها تجعل الكود هشًا وغير قابل للقراءة.

// قبل إعادة الهيكلةfunc calculateDiscount(price: Double) -> Double {    if price > 1000 {        return price * 0.15    } else if price > 500 {        return price * 0.1    } else {        return price * 0.05    }}

// بعد إعادة الهيكلةprivate struct DiscountConstants {    static let premiumThreshold: Double = 1000    static let standardThreshold: Double = 500    static let premiumRate: Double = 0.15    static let standardRate: Double = 0.10    static let basicRate: Double = 0.05}

func calculateDiscount(price: Double) -> Double {    switch price {    case _ where price > DiscountConstants.premiumThreshold:        return price * DiscountConstants.premiumRate    case _ where price > DiscountConstants.standardThreshold:        return price * DiscountConstants.s