تبعيات الكود هي الشيطان.

"التغيير هو الثابت الوحيد ..." - هيراكليتس (فيلسوف)

الأدوات والمكتبات والأطر التي نستخدمها لبناء تطبيقات الويب الخاصة بنا اليوم تختلف اختلافًا جذريًا عن تلك التي استخدمناها قبل سنوات قليلة فقط.

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

نحن نستورد ونستخدم ونرث من أطر عمل نكهة الشهر كما لو كانت جميعها ستظل موجودة ولن تتغير إلى الأبد. حسنًا ... ليسوا كذلك. وهذه مشكلة.

بعد أكثر من 20 عامًا من تطوير تطبيقات الويب وتصميمها وهندستها ، أصبحت أقدر حقيقتين مهمتين:

  1. تشكل التبعيات الخارجية تهديدًا كبيرًا لاستقرار وصلاحية أي تطبيق على المدى الطويل.
  2. من الصعب بشكل متزايد - إن لم يكن من المستحيل - إنشاء أي نوع من التطبيقات غير التافهة دون الاستفادة من التبعيات الخارجية.

تتناول هذه المقالة التوفيق بين هاتين الحقيقتين بحيث تتمتع تطبيقاتنا بأكبر فرصة للبقاء على المدى الطويل.

إن حفرة الأرانب عميقة جدًا بالفعل.

إذا بدأنا في التفكير في كل الأشياء التي تعتمد عليها تطبيقات الويب الخاصة بنا ، فمن السهل التفكير في عشرات أو أكثر قبل أن نصل إلى الكود:

  • قوة
  • الاتصال
  • جدار الحماية
  • DNS
  • أجهزة الخادم (وحدة المعالجة المركزية ، القرص ، ذاكرة الوصول العشوائي ، ...)
  • تبريد
  • منصة المحاكاة الافتراضية
  • منصة الحاويات
  • نظام التشغيل
  • منصة خادم الويب
  • منصة خادم التطبيقات
  • متصفح الإنترنت

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

في الكود ، هناك ثلاثة أنواع من التبعيات:

1. التبعيات التي نسيطر عليها

هذا رمز مكتوب ومملوك لنا أو لمنظمتنا.

2. التبعيات التي لا نتحكم فيها

هذا رمز مكتوب بواسطة بائع خارجي أو مجتمع برامج مفتوح المصدر.

3. إزالة التبعيات مرة واحدة

هذه هي تبعيات الكود التي تعتمد عليها تبعيات رمز الطرف الثالث. (يقول ذلك ثلاث مرات بسرعة!)

سنتحدث بشكل أساسي عن التبعيات التي لا نتحكم فيها .

تبعيات ونحن السيطرة و التبعية إزالة مرة واحدة لا يزال سبب الصداع، ولكن في حالة من التبعية ونحن السيطرة، ينبغي أن نكون قادرين على التدخل مباشرة وتخفيف أي مشاكل.

في حالة التبعيات بمجرد إزالتها ، يمكننا عادةً الاعتماد على طرف ثالث لرعايتنا ، نظرًا لأنها تعتمد عليها أيضًا.

لماذا تبعيات رمز الطرف الثالث جيدة

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

بغض النظر عن مجموعة التكنولوجيا التي تستخدمها ، هناك فرصة جيدة لوجود حلول مشتركة لهذه المشكلات ، ومتاحة كمكتبات يمكنك الحصول عليها بسهولة وتوصيلها بقاعدة التعليمات البرمجية الخاصة بك. تعد كتابة أي من هذه الأشياء تمامًا من نقطة الصفر مضيعة للوقت بشكل عام.

تريد التركيز على الكود الذي إما يحل مشكلة غير شائعة أو يحل مشكلة شائعة بطريقة غير شائعة. هذا ما يجعل تطبيقك ذا قيمة: الكود الذي ينفذ قواعد العمل الفريدة لتطبيقك وحده - "الخلطة السرية".

خوارزمية بحث Google وترتيب الصفحة ، تصفية الجدول الزمني على Facebook ، قسم "موصى به لك" في Netflix وخوارزميات ضغط البيانات - الرمز وراء كل هذه الميزات هو "الخلطة السرية".

يسمح لك رمز الجهة الخارجية - في شكل مكتبات - بتنفيذ هذه الميزات السلعية لتطبيقك بسرعة ، بحيث يمكنك الاستمرار في التركيز على "الخلطة السرية".

لماذا تبعيات كود الطرف الثالث سيئة

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

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

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

قام عميل سابق لي ببناء تطبيقه باستخدام مزود Backend-as-a-Service المملوك لـ Facebook ، والذي يسمى Parse. استخدموا مكتبة عميل JavaScript مقدمة من Parse لاستهلاك خدمة التحليل. في هذه العملية ، قاموا بربط كل شفراتهم بإحكام - بما في ذلك كود "الصلصة السرية" - بهذه المكتبة.

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

الآن بدلاً من التركيز على التكرار على منتجهم وتنمية قاعدة عملائهم ، كان على عميلي معرفة كيفية الانتقال إلى إصدار مستضاف ذاتيًا ومفتوح المصدر من Parse أو استبدال Parse تمامًا.

كان الاضطراب الذي تسبب فيه هذا التطبيق الشاب والناشئ ضخمًا لدرجة أن عميلي ألغى التطبيق بالكامل في النهاية.

الموازنة بين الخير والشر

منذ عدة سنوات ، كان الحل الذي أستخدمه للتغلب على المخاطر مع الاحتفاظ بمزايا مكتبات الطرف الثالث هو لفها باستخدام نمط المحول.

بشكل أساسي ، تقوم بلف رمز الجهة الخارجية في فئة أو وحدة محول قمت بكتابتها. يعمل هذا بعد ذلك على عرض وظائف مكتبات الطرف الثالث بطريقة تتحكم فيها.

باستخدام هذا النمط ، إذا تغيرت مكتبة أو إطار عمل تابع لجهة خارجية ، أو اختفت ، فما عليك سوى إصلاح القليل من رمز المحول. يبقى باقي التطبيق الخاص بك كما هو.

هذا يبدو جيدا على الورق عندما يكون لديك تبعيات قائمة بذاتها توفر فقط بعض الوظائف ، فإن هذا سيفي بالغرض. لكن الأمور يمكن أن تصبح قبيحة بسرعة.

هل يمكنك تخيل الاضطرار إلى التفاف مكتبة React بالكامل (بما في ذلك JSX) قبل استخدام أي منها؟ ماذا عن التفاف إطار عمل jQuery أو Angular أو Spring في Java؟ سرعان ما يصبح هذا كابوسًا.

أوصي هذه الأيام باتباع نهج أكثر دقة ...

لكل تبعية تريد إضافتها إلى قاعدة التعليمات البرمجية الخاصة بك ، قم بتقييم مستوى المخاطرة التي ستعرضها عن طريق ضرب عاملين:

  1. احتمالية أن تتغير التبعية بطريقة مادية.
  2. مقدار الضرر الذي قد يلحقه التغيير المادي في التبعية بتطبيقك.

من غير المرجح أن تتغير مكتبة أو إطار عمل تابع لجهة خارجية عندما يكون بعض أو كل الأشياء التالية صحيحة:

  • لقد كان موجودًا منذ عدة سنوات وكان له العديد من الإصدارات الرئيسية.
  • يستخدم على نطاق واسع في العديد من التطبيقات التجارية.
  • يحظى بدعم نشط من منظمة كبيرة - ويفضل أن تكون شركة أو مؤسسة ذات اسم مألوف.

ستلحق مكتبة أو إطار عمل تابع لجهة خارجية ضررًا أقل للتطبيق الخاص بك عندما تكون بعض أو كل الأشياء التالية صحيحة:

  • يتم استخدامه فقط بواسطة جزء صغير من التطبيق الخاص بك ، بدلاً من استخدامه طوال الوقت.
  • الكود الذي يعتمد عليه ليس جزءًا من تلك "الصلصة السرية" التي تحدثت عنها سابقًا.
  • تتطلب إزالته إجراء تغييرات طفيفة على قاعدة التعليمات البرمجية الخاصة بك.
  • تطبيقك بأكمله صغير جدًا ويمكن إعادة كتابته بسرعة. (كن حذرًا مع هذا - نادرًا ما يكون هذا صحيحًا لفترة طويلة جدًا.)

الشيء الأكثر خطورة هو أنه من المرجح أن تقوم بلفه أو تجنبه تمامًا.

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

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

بالحديث عن المتعة ، ألق نظرة على هذا ...

الصورة أعلاه هي الرسم البياني للتبعية لتطبيق يسمى TinyTag Explorer.

يعد إنشاء رسم بياني للتبعية لتطبيقاتك الحالية طريقة رائعة لفهم مستوى المخاطرة التي تسببها تبعياتك. لقد جمعت قائمة بالأدوات المجانية لإنشاء رسوم بيانية مشابهة لما ورد أعلاه في مجموعة متنوعة من اللغات بما في ذلك JavaScript و C # و Java و PHP و Python. يمكنك الحصول عليه هنا.

ساعدني في مساعدة الآخرين

أرغب في مساعدة أكبر عدد ممكن من المطورين من خلال مشاركة معرفتي وخبرتي معهم. الرجاء مساعدتي بالضغط على زر التوصية (القلب الأخضر) أدناه.

أخيرًا ، لا تنسَ الحصول على قائمة مولدات الرسوم البيانية التبعية المجانية هنا.