إزاي تكتب أكواد تعيش سنين من غير ما تعقدك في التعديل والصيانة

سهل الثلاثاء,14 يوليو 2026

1. صدمة العودة

أكبر اختبار حقيقي لأي مبرمج مش إنه يكتب كود يشتغل دلوقتي حالا، الاختبار الفعلي هو إنه يرجع يقرأ الكود ده بعد ست شهور أو سنة ويفهم هو كان كاتب إيه أصلاً! الموقف الشهير لما تفتح مشروع قديم وتتساءل بغضب: "مين الغبي اللي كتب العك ده؟" وتكتشف في النهاية إنه إنت، هو النتيجة الطبيعية للكتابة السريعة العشوائية. الكود اللي بيتكتب بهدف "إنه يشتغل وخلاص" بيتحول مع الوقت لبيت من الكروت؛ لو عدلت فيه سطر واحد في شاشة، بتلاقي شاشتين تانيين باظوا تماماً، وعشان كده الاستثمار في جودة الكود من أول يوم بيوفر عليك شهور من الصداع والتعقيد قدام.

2. لغة البشر لا الطلاسم

أول قاعدة في كتابة كود يعيش سنين هي إنك تكتب كود للقراءة مش مجرد كود يفهمه الكمبيوتر. الكمبيوتر في النهاية هيترجم أي حاجة لـ 0 و 1 وهيشتغل، لكن زميلك في الفريق (أو أنت مستقبلاً) محتاج يفهم المنطق وراء الكتابة دي. ابعد تماماً عن تسمية المتغيرات والدوال بحروف مبهمة زي x أو y أو data؛ خلي الاسم واضح وبيشرح وظيفته بالتفصيل حتى لو كان طويل شوية. بدلاً من تسمية دالة بـ calc()، سميها calculateDiscountedPrice()؛ الاسم ده بيخلي الكود يتفرأ كأنه قصة واضحة مش طلاسم محتاجة فك شفرات.

3. سر الـ SOLID

المبادئ الخمسة الشهيرة (SOLID Principles) مش نظريات بنحفظها عشان نعدي بيها الإنترفيو، دي هي الأساس الهندسي اللي بيضمن إن مشروعك يتوسع بأمان ومن غير ما يتهد على دماغك. أهم مبدأين فيهم تقدر تبدأ بيهم فوراً هما:

• مبدأ المسؤولية الفردية (Single Responsibility): الملف أو الكلاس بتاعك لازم يكون بيعمل حاجة واحدة بس وبإتقان. لو عندك كلاس بيسحب بيانات من السيرفر، وبيحسب الضرايب، وبيطبع الفاتورة، فده لغم موقوت؛ قسمه لثلاثة كلاسات منفصلة.
        

• مبدأ المفتوح/المغلق (Open/Closed): كودك لازم يكون مفتوح للتوسيع ومغلق للتعديل. يعني لو حبيت تضيف طريقة دفع جديدة في تطبيقك، المفروض تضيف كود جديد مش تعدل وتكسر الكود القديم اللي شغال ومستقر بقاله سنين.

4. التخلص من التكرار

قاعدة (DRY - Don't Repeat Yourself) هي العدو الأول لعمليات الـ "Copy-Paste" اللي بتدمر المشاريع البرمجية. لو لقيت نفسك بتكرر نفس الأكواد أو المعادلات الحسابية في كذا مكان جوه الأبلكيشن، اعرف فوراً إن تصميمك فيه مشكلة. التكرار بيعني إنك لو حبيت تعدل في المنطق ده مستقبلاً، هتضطر تلف على كل الملفات دي تعدلها يدوي، وتنسى ملف فيهم فيحصل خطأ كارثي. اعزل أي كود متكرر جوه دالة مستقلة أو كلاس مخصص، واستدعيه في أي مكان تحتاجه بمرونة وأمان.

5. التعليقات الذكية

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

6. شبكة الأمان

مهما كنت مبرمج عبقري وبتكتب كود نظيف، البشر بيغلطوا، ومع توسع المشروع وتداخل الميزات، مستحيل تتوقع تأثير كل تعديل صغير بتعمله. هنا بييجي دور الاختبارات التلقائية (Automated Tests) وخاصة الـ (Unit Tests) كشبكة أمان جبارة بتحميك من نفسك. لما تكتب اختبارات بتغطي الأجزاء الحيوية في كودك، بتقدر تعدل، وتطور، وتنظف الكود القديم بمنتهى الثقة والشجاعة؛ لأنك عارف إن لو تعديلك بوظ أي حاجة قديمة، الاختبارات هتصرخ فوراً وتعرفك المشكلة فين قبل ما ترفع النسخة للعملاء.

7. قانون الكشافة

في معسكرات الكشافة فيه قانون ذهبي بيقول: "اترك مكان التخييم أنظف مما وجدته". طبق القانون ده حرفياً على كودك (Boy Scout Rule). كل ما تدخل تعدل ميزة أو تصلح ثغرة في ملف قديم، وتلاقي سطر كود مش واضح أو دالة محتاجة تحسين، نظمها ونظفها قبل ما تمشي، حتى لو مكنتش أنت اللي كاتبها. التحسينات الصغيرة والمتراكمة دي بتمنع تراكم ما يسمى بـ "الديون التقنية" (Technical Debt)، وبتخلي المشروع دايماً في حالة شباب ونضارة برمجية، وقابل للتطوير لسنوات طويلة وبمنتهى السلاسة.