هناك بعض الأشياء الجيدة حقًا عن الطريقة التي يعمل بها البرنامج على الإنترنت. للبدء ، هناك شبكة ضخمة غير رسمية تضم ملايين الأشخاص الذين يساهمون في مستودع ضخم لأجزاء التعليمات البرمجية التي تساعد على تشغيل ملايين أخرى من التطبيقات.
في كل مرة ترى رابطًا صغيرًا في الجزء السفلي من صفحة الويب يقول "مدعوم من So-And-So" ، فإنك تشهد هذا التأثير التعاوني في العمل.
وبالطبع السبب الرئيسي الذي يجعل الناس يحبون المشاركة والتعاون من طرف ثالث هو أنه يمكن أن يوفر عليك ساعات عديدة من وقت التطوير، لأنك لا تعيد اختراع شيء موجود بالفعل.
ولكن حتى مع هذه المزايا الرائعة لنظام مشاركة التعليمات البرمجية لجهة خارجية، هناك الكثير من الأسباب التي قد تجعلك ترغب في تجنب استخدام أجزاء التعليمات البرمجية هذه، كما نحن على وشك أن نرى...
1. المخاطر الأمنية المحتملة
نظرًا لأن جميع الكودات التي تحرك أي شيء على الويب هي عبارة عن مصدر مفتوح ، فهذا رهان جيد أنه في حالة وجود أي حمولة ضارة في تطبيق معين ، سيتم اكتشافه سريعًا بواسطة مجتمع المطورين وتصحيحه بسرعة.
ولكن يتم تنزيل العديد من أجزاء التعليمات البرمجية هذه مئات أو حتى آلاف المرات يوميًا ، وليس كل فريق إداري يقوم بعمل جيد في الحفاظ على نظام آمن لمشاركة الشفرة.
كلما كان التطبيق أكبر وأكثر تعقيدًا ، كان من الأسهل إصابته عن طريق إضافة بضعة أسطر من التعليمات البرمجية في مكان غامض. يكاد لا أحد يأخذ وقتًا في التدقيق في كل سطر من التعليمات البرمجية في تطبيق ما ، لأنهم يفترضون عمومًا أن الرمز يمكن الوثوق به.
عادةً ما يقوم المبرمج ذو المهارات العالية بعمل جيد للتعتيم على الطبيعة الخبيثة للشفرة ، ولن يكتشف سوى مبرمج آخر عالي المهارة ما هو الغرض منه ... إذا تم اكتشاف جزء الكود الضار.
2. أنت لا تملكها
هذا هو في الواقع مزيج من المشاكل. الأول هو أنك قد تخضع لشروط الترخيص المختلفة. عندما يكون لديك أجزاء متعددة من الشفرات مستخدمة في صفحة ويب أو تطبيق واحد ، فقد تكون في الواقع خاضعًا لشروط وأحكام ترخيص متعددة مختلفة ، وقد تتعارض بعضها مع بعضها البعض.
بالطبع لا يكاد أي شخص يكلف نفسه عناء قراءة هذه القوائم المملة من الشروط والأحكام، ولكن من المحتمل أن يكون ذلك خطأً.
على وجه الخصوص، سيكون من الخطأ أن يتسبب بعض الشروط في اتفاقية الترخيص في انتهاك بعض القوانين في بلدك الأصلي أو في البلد الذي يوجد به الخادم الخاص بك.
المشكلة الأخرى هي أنه إذا لم تكن تمتلك كودًا برمجيًا، فلن يكون لديك أي سيطرة عليه، وقد لا تفهم بالضرورة كل ما يفعله أو كيف يعمل.
وهذا يعني أنه إذا قام شخص ما بإجراء بعض التغييرات على التعليمات البرمجية، فقد تظل عالقًا مع هذا التغيير، خاصة إذا قمت بتثبيت التحديثات والتصحيحات والترقيات والإصدارات الجديدة بأمانة بمجرد إصدارها باعتبارها مستقرة، أو إذا كنت تعتمد كليًا على تسليم المحتوى شبكات لحلول الطرف الثالث الخاص بك.
3. غالبا ما تحصل على أكثر بكثير مما تحتاج
عادةً ما تعمل تعليمات برمجية خارجية للقيام بالمهمة التي تريدها، ولكنها تحتوي في بعض الأحيان على جميع أنواع الميزات الإضافية التي لا تحتاج إليها وربما لن تستخدمها أبدًا.
في بعض الحالات، لا يمكنك إزالة هذه الميزات الإضافية بسهولة أو حتى على الإطلاق. قد تضطر أيضًا إلى تقديم تنازلات. قد تفعل الميزة شيئًا قريبًا جدًا مما تنويه، ولكن ليس بالضبط ما تنويه. أنت تتاجر بالذهول من أجل الحصول على قدر أقل من العمل للقيام به، وهذه ليست تجارة جيدة دائمًا.
4. يمكن أن تؤدي مستويات متعددة من تبعية الجهات الخارجية إلى مشكلة حقيقية
تستخدم العديد من المشاريع مفتوحة المصدر نفس أجزاء التعليمات البرمجية لجهة خارجية بطرق مختلفة لإنتاج برامجها. في معظم الأحيان، لا يكون هذا أمرًا سيئًا، ولكنه قد يؤدي إلى مشاكل.
في هذه الأيام، لا يقوم العديد من المطورين حتى بتثبيت الأجزاء التي يستخدمونها، ولكنهم يسحبونها في وقت التشغيل من شبكات توصيل المحتوى حسب الطلب. وقد تجلى خطر ذلك بشكل مذهل من خلال حادثة الوسادة اليسرى في عام 2016.
كل سلسلة تكون قوية بقدر قوة أضعف حلقاتها. ويعني تسلسل التبعيات هذا أنه إذا تم كسر أو اختراق أي رابط في أي مكان على طول السلسلة، فإن السلسلة بأكملها معرضة لخطر الخلل. في بعض الحالات قد يكون ذلك مكلفًا للغاية.
لم يكن أحد يشك في القوة الموجودة في 11 سطرًا من التعليمات البرمجية الموجودة في تلك الوظيفة الصغيرة الحميدة التي تسمى Left-Pad، ولكن عندما فشل هذا الارتباط المتسلسل المحدد، أدى إلى توقف العديد من المواقع الكبيرة.
كان الجزء الأكبر منه هو أن معظم الأشخاص الذين كانوا يستخدمون Left-Pad لم يكن لديهم أي فكرة عن أنهم يستخدمونه، أو ما يفعله، أو كيفية حل المشكلة. كما هو مذكور في البند 2، إذا لم تكن تملكه، فقد لا تفهمه بالضرورة.
كانت Left-Pad وظيفة بسيطة جدًا تقوم فقط بإضافة بضع مسافات إلى الجانب الأيسر من الخط للتأكد من أن الخط هو الطول الصحيح. المشكلة الآن هي أن أي مبرمج مختص يمكنه تكرار هذه الوظيفة بسهولة.
ليست هناك حاجة مطلقًا لأن يعتمد أي تطبيق على وظيفة الطرف الثالث هذه، ومع ذلك كانت آلاف مواقع الويب تستخدم البرامج التي تتضمن هذه الوظيفة، بما في ذلك Netflix وFacebook وReddit. لقد كانت مجرد ضربة حظ جيدة، ففي هذه الحالة كانت وظيفة بسيطة جدًا هي التي كسرت السلسلة، وليست وظيفة معقدة حقًا لها سلسلة من التبعيات الخاصة بها.
خلاصة القول هي أنه إذا كنت تستطيع أن تبنيها بنفسك ، فربما يجب عليك ذلك!
في نهاية المطاف ، يعود القرار بشأن استخدام كتل أكواد الطرف الثالث في مشروعك إلى سلسلة من القرارات المعقدة التي لا ينبغي أن تُتخذ على محمل الجد. العوامل التي تحتاج إلى أخذها في الاعتبار هي الأمن والشرعية والتكلفة والوقت والاستقرار.
لجعل عملية اتخاذ القرار أكثر بساطة ، من المحتمل أن تساعد حالة الاختبار التالية.
إذا كان أي من هذه العوامل صحيحًا:
- الوظيفة التي تريدها بسيطة
- لديك (أو فريقك) القدرة على إنشاء الوظيفة
- هناك متسع من الوقت لإنشاء الوظيفة
- يحتاج التطبيق الخاص بك إلى أمان جيد
- لديك مخاوف بشأن المشاكل القانونية المحتملة المرتبطة بترخيص الطرف الثالث
- من المهم ألا يفشل تطبيقك أبدًا
يجب أن تبنيها بنفسك ،
عدا ذلك ، قد يكون استخدام وظائف الطرف الثالث أكثر فعالية ، شريطة أن تكون على دراية بالمشاكل المحتملة وأن يكون لديك استراتيجية مطبقة لما ستفعله إذا نشأت هذه المشاكل.
التعليقات الردود 0