المطوّر 1: "ألا ترى أن هذه الدالة تشبه الأخرى؟ أظن أن علينا تجريد بعض أجزائها..." المطوّر 2: "لا أظن ذلك ضروريًا، فليس لدينا إلا هاتان الدالتان" المطوّر 1: "صحيح... لكن لنحاول على الأقل اتباع مبدأ DRY" المطوّر 2: "لكننا لا نحتاج فعلًا إلى تجريد الكود..."

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

"الآراء هي تمثيل لما يدركه الفرد من وجوده" - مجهول

DRY: لا تكرر نفسك (Don't Repeat Yourself)

"نحن مطوري البرمجيات ننشغل كثيرًا بإتقان العمل ونظافته من المرة الأولى، فننسى أن ما نسلّمه ليس كودًا، بل حلًا لمشكلة" fancy-quote

هذا أول مبدأ سنتناوله، لأنه موضوع نقاش شائع في مجالنا. صاغ هذا المبدأ Andrew Hunt وDavid Thomas في كتابهما The Pragmatic Programmer، وينص على أن "كل معلومة يجب أن يكون لها تمثيل واحد واضح وموثوق داخل النظام". وبكلماتي أنا، يعني ذلك أن بعض السلوكيات أو الوظائف المتكررة عند بناء الأنظمة يجب أن تنبع من جزء واحد من الكود. وعدم الالتزام بهذا المبدأ يقود إلى نهج آخر يُسمّى "WET"، أي "Write Everything Twice" (اكتب كل شيء مرتين). أعلم، أعلم، ربما تقولون في أنفسكم: "هذا مبدأ بديهي يا هذا!" لكن اسمعوني حتى النهاية، فإذا تأملنا هذا المبدأ جيدًا ستبرز بعض الأسئلة:

• هل نعتبر أجزاء الكود المتشابهة في الشكل تكرارًا؟
• هل نعتبر أجزاء الكود التي تتصرف بالطريقة نفسها تكرارًا؟
• متى يجب أن نجرّد الكود فعلًا؟
• كيف نتأكد أن التجريد نفسه ليس مجرد تكرار آخر؟ (وقعتم في الفخ!!!)

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

function (param) {
  // insert repeatable function here
}

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

function (param) {
 if (new behavior) {
    // insert new repeatable behaviour
  } else {
    // insert repeatable function here
  }
}

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

YAGNI: لن تحتاج إليه (You Aren't Gonna Need It)

"الخط الفاصل بين الكسل والكفاءة رفيع جدًا" - شخص ذكي fancy-quote

آه نعم!!! هذا مبدئي المفضل، لأنني مطوّر كسول، لا... أقصد كفؤ. فنحن المطورين تدرّبنا في معظم الأحيان على التفكير النقدي ومراعاة كل حالة حدّية وكل سيناريو، وهذا يدفعنا إلى التفكير في سيناريوهات مستقبلية (بعيدة أحيانًا).

"هل تحتاجون فعلًا إلى kubernetes؟" "هل من الضروري فعلًا إعادة بناء مكتبة إدارة الحالة تلك من الصفر؟" "هل نحتاج فعلًا إلى microservice؟" "هل أحتاج فعلًا إلى حبيبة يا أمي؟"

شطحت قليلًا مع السؤال الأخير، لكنكم فهمتم المقصود. فأحيانًا نفكر في مستقبل قد لا يأتي أبدًا، فنبني تعقيدات لا داعي لها في أنظمتنا (وهناك مبدأ لهذا أيضًا). ومن الطرق التي أرى أنها تساعدنا على تجنب ذلك أن نطرح على أنفسنا دائمًا هذا السؤال عند التنفيذ: هل هذا أبسط شيء يمكن أن ينجح؟ فهذا السؤال يقطع شوطًا طويلًا في تجنيب تطبيقاتنا هذه التعقيدات. وتذكروا: حين تكتبون جزءًا من الكود ويكون مبرركم الوحيد لكتابته في تلك اللحظة أنكم ستحتاجون إليه يومًا ما، فتوقفوا. وإذا احتجتم إليه فعلًا في المستقبل، فلا تترددوا في مراسلة زملائكم وقول: "ألم أقل لكم!!!!"، ثم ابنوه حينها، عندما تكون الحاجة إليه حقيقية. **KISS: اجعلها بسيطة يا غبي (Keep It Simple, Stupid)**أول من ذكر هذا المبدأ هو Kelly Johnson، وينص ببساطة على أن **_معظم الأنظمة تعمل بأفضل شكل حين تبقى بسيطة بدلًا من جعلها معقدة، لذلك يجب أن تكون البساطة هدفًا أساسيًا في التصميم، وأن يُتجنب التعقيد غير الضروري. _**ومن بين كل هذه الآراء، كان هذا المبدأ دائمًا الأصعب عليّ في الالتزام به، وأظن أن السبب أنني جزء من منظومة تفخر بتقديم حلول تبدو بسيطة في البداية، لكنها تنتهي بتعقيدات لا داعي لها (نعم، أقصدك يا Redux-saga)، ولذلك كانت أنماط تفكيري تقودني دائمًا إلى تقديم هذا النوع من الحلول. وقد تعلمت من التجربة أن أبسط الحلول عادةً هي تلك الموجودة أمام أعيننا، والتي تبدو بديهية بعد تنفيذها. وإليكم قاعدة عامة قد تنفعكم وقد لا تنفعكم: إذا قدّمتم حلًا لمشكلة ولم ينبهر به زملاؤكم، وقالوا إنه "بديهي"، فقد طبقتم هذا المبدأ كما ينبغي. لا أقول إن كل حل سيكون بسيطًا، لكن الأرجح أن معظمها سيكون كذلك. والحقيقة أنني ما زلت أتعلم الالتزام بهذا المبدأ، فلا أزال أحيانًا أضيف تعقيدات دون قصد إلى الحلول التي أبتكرها. ولحسن الحظ لدينا CTO رائع يقدّر هذا المبدأ مثلي، وكثيرًا ما يحاول توعيتنا به. وإذا كان لديكم رأي وتريدون مشاركة أفكاركم حول بعض هذه المواضيع، فلا تترددوا في كتابة تعليق أدناه.