مبدأ إعادة استخدام الكود

السلام عليكم ورحمة اللهwebcode

إعادة استخدام الكود- في هندسة البرمجيات- هي من المباديء الصحيحة للبرمجة، وهي تقلل من زمن تكلفة تطوير البرامج وبالتالي تقليل التكلفة، وتساعد في تسهيل وتبسيط البرامج المعقدة، ومن ثم سهولة اﻹستمرار في تطويرها وزيادة إمكاناتها. وقد تكلمنا في مقالة سابقة عن التجريد باعتباره أحد الوسائل المستخدمة لتسهيل أو تحقيق إعادة استخدام الكود.

تعريف إعادة استخدام الكود هو كتابة إجراء أو مجموعة إجراءات يمكن اﻹستفادة منها في أكثر من موضع. وسوف نتكلم عنها في هذه المقالة بإذن الله من ناحية عملية.

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

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

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

المستوى الثاني: الوحدات والمكتبات: وهي كتابة وحدة أو مكتبة كاملة بطريقة مجردة ليس فيها أي ارتباط بوحدات خاصة في مشروع معين ، فيتم كتابتها بصورة عامة ليتم استخدامها في أي مشروع، ويوجد نوعان: النوع اﻷول هي الوحدات المصدرية الخاصة بلغة برمجة معينة، مثل header files في لغة سي، و units في لغة باسكال، وclass library في لغة جافا: في هذه الحال يحتاج المبرمج المستفيد من هذه الوحدة لمصدر هذا الكود ليقوم بتضمينه داخل البرنامج المستفيد، وفي حالة إنتاج برامج طبيعية Native يتم تضمين هذه الوحدات داخل الملف التنفيذي. النوع الثاني: وهو استخدام مكتبة، حيث تتم ترجمتها إلى مكتبة بصورة ثنائية حسب نظام التشغيل ويتم استدعائها بصورة خارجية من أي برنامج، ويتم الربط في وقت التنفيذ ولا يتم تضمينها ضمن الملف التنفيذي للبرنامج المستفيد. هذا المستوى يحقق إعادة استخدام الكود بأفضل الطرق، حيث يمكن الإستمرار في تطور تلك المكتبات بصورة منفصلة، أحياناً يكون المطور لهذه المكتبات طرف ثالث كما يُسمى هدفه هو فقط تطوير هذه المكتبة، وكمثال لها: مكتبات التشفير، والربط مع قواع البيانات، أو الربط مع البريد. أما المبرمجون فيقومون بتحميل هذه المكتبة سواءً في شكل ملف مصدري أو ثنائي لإستخدامها في برامجهم المختلف. وهي تُمثل أعلى درجات التجريد وذلك حسب نجاحها في اﻹستخدام في أغراض مختلفة. يُمكن استخدام هذه الطريقة كذلك لتقسيم المشروع الواحد إلى عدة أقسام : قسم متخصص في إجراءات البيانات، وقسم آخر للربط مع اﻷنظمة اﻷخرى، وقسم  متخصص في واجهة المستخدمة، وبذلك يمكن إيكال كل مبرمج لتطوير جزئية معينة بناءً على تخصصه والمجال الذي يتميز فيه. من عيوب هذا المستوى هو الحاجة لإعادة ترجمة كل البرنامج التي تستخدم تلك الوحدة في حال تغيير صفة ما في احد اﻹجراءات، أما إذا كان التغيير في صفة في مكتبة تم ربطها خارجياً فلا تتطلب إعادة الترجمة إلا إذا تم تغيير واجهة نداء اﻹجراء procedure interface.

المستوى اﻷول: اﻹجراءات البعيدة، مثل خدمات الويب: ومن أهم أشكالها خدمات ويب يمكن نداءها من أي برنامج مكتوب بأي لغة برمجة. ويتم نداءها تُستخدم هذه الطريقة لربط اﻷنظمة مع بعضها البعض. ويتم توفير الإجراءات بصورة حية online من أي برنامج مستفيد، كذلك يتم تعديل ويتم تطوير اﻹجراءات في هذه الخدمات دون الحاجة إلى إعادة ترجمة البرامج المستفيدة، واحياناً لا نحتاج حتى لإغلاق تلك البرامج، بل  لا يتم إخبار مطور البرنامج المستفيد بهذه التغييرات في بعض اﻷحيان. وتُمسى هذه الطريقة بنداء اﻹجراءات البعيدة و تصبح خدمة الويب هذه مورد تتم صيانتها ودعمها من قبل جهة أخرى أو مبرمج آخر مسؤوليته هذا الإجراء. هذه الطريقة تمثل نقطة مركزية حية لكافة البرامج، فإذا تم أي تعديل لا نحتاج لإعادة ترجمة كما في المستوى الثاني. وهو يُمثل البرمجة متعددة الطبقات، ويحقق سرية وعزل كبيرين في تطوير البرامج – وهذا موضوع آخر ليس ضمن حديثنا اليوم- إلا أنه أقل تجريداً من المستوى الثاني، حيث أن مطور خدمات الويب لا يكون طرف ثالث في معظم اﻷحيان، بل هو مطور النظام الذي نريد التخاطب معه، كذلك فأن خدمات الويب لا تُمثل إجراءات عامة، بل هي خاصة بمؤسسة معينة يتم تطوير خدمة الويب لها فقط، أو يمكن أن تكون خاصة بمشروع معين يتم تطويرها لصالح هذا النظام فقط، مثل أنظمة ERP. وبخلاف المكتبات والوحدات في المستوى الثاني فإن خدمات الويب تعتمد على مكتبات أو أجزاء كود خاصة وليست عامة. توجد أشكال أخرى غير خدمات الويب تحقق نفس اﻷهداف لكنها أكثر قدما وأقل استخداماً ومن تقنياتها: CORBA, RMI, COM+

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

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

Advertisements

فكرتان اثنتان على ”مبدأ إعادة استخدام الكود

  1. السلام عليكم

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

    اخي لديك طريقة في عرض المعلومات اسأل الله أن يبارك لك فيها ويزيدك من فضله.

    لا تعلم كم من الفائدة الكبيرة التي يحصل عليها المبرمج من قراءة مقالاتك فاستمر اخي.

    وياليت لو تتطرق للنقطة المشارة في الموضوع بخصوص العزل والسرية في خدمات الويب وطرح أمثلة شائعة لها.

    وشكراً.

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

اترك رد

إملأ الحقول أدناه بالمعلومات المناسبة أو إضغط على إحدى الأيقونات لتسجيل الدخول:

WordPress.com Logo

أنت تعلق بإستخدام حساب WordPress.com. تسجيل خروج   / تغيير )

صورة تويتر

أنت تعلق بإستخدام حساب Twitter. تسجيل خروج   / تغيير )

Facebook photo

أنت تعلق بإستخدام حساب Facebook. تسجيل خروج   / تغيير )

Google+ photo

أنت تعلق بإستخدام حساب Google+. تسجيل خروج   / تغيير )

Connecting to %s