البرمجة المعيارية هي مفهوم عام في البرمجة يقوم فيه المطورون بفصل وظائف البرنامج إلى أجزاء مستقلة. تعمل هذه الأجزاء كقطع بناء، يحتوي كل منها على جميع العناصر اللازمة لتنفيذ جانب معين من الوظيفة.
عند تجميع القطع، أو الوحدات، معًا، تشكل البرنامج القابل للتنفيذ.
ملاحظة: الوحدات هي أيضًا مفهوم في JavaScript يمكن استخدامه لتنفيذ هيكلية معيارية، على الرغم من أنك لست مقيدًا بتطبيق الهيكلية المعيارية في JavaScript فقط.
في حين أن معظم الأشخاص يتحدثون عن المعيارية على مستوى الملفات/المجلدات/المستودعات، فإن المعيارية تعمل على مستويات متعددة:
- وظائف داخل الملفات
- ملفات داخل المستودعات/المكتبات
- مكتبات/مستودعات داخل المشاريع
المعيارية تتعلق بصنع قطع بناء، وقطع بناء مكونة من قطع بناء أصغر. كل قطعة منفصلة، قوية، وقابلة للاختبار، مما يتيح لك تجميعها في النهاية لإنشاء تطبيقك. التفكير في المعيارية بهذه الطريقة يعني أيضًا أنه يمكنك دمجها في أسلوبك البرمجي وهيكليتك البرمجية.
محتوي المقال
أنواع الوحدات Modules Types
يمكنك إنشاء قواعد وإرشادات حول ما تعنيه المعيارية على كل مستوى وكيفية التعامل مع أشياء معينة، مثل كيفية تعريف كل جزء وتحديد موقعه داخل الملفات والمجلدات والمكتبات. من المهم أن تقرر منذ البداية ما هي قيود كل نوع من أنواع الوحدات، وهذا يجعل التخطيط أفضل.
نوعان مهمان من أنواع الوحدات يجب مراعاتهما هما:
وحدات التحكم بالبرنامج – Program control modules
صُممت لتوصيل وتنسيق وحدات أخرى، أو وحدات تعمل معًا.
وحدات المهام المحددة – Specific task modules
صُممت لإنجاز مهمة محددة، وغالبًا ما تتعلق بنقل البيانات بين الوحدات.
الوحدات وواجهات البرمجة
إحدى الطرق المفيدة التي يمكن أن تتفاعل بها الوحدات هي من خلال واجهات البرمجة أو APIs. مع واجهة البرمجة، تعرض فقط أجزاء الكود التي يحتاج المطورون لاستخدامها في الوحدة، بينما تخفي الباقي.
بهذه الطريقة، يمكن أن يعمل API كعقد يحدد ما تفعله الوحدة أو المكتبة وكيف يمكن استخدامها من خلال الأكواد الخارجية. على سبيل المثال، قد يقول API “هذه الوحدة تحتوي على هذه الوظيفة التي تقوم بهذا وتعيد ذلك”.
مع واجهات البرمجة، يمكنك أن تكون واثقًا من الأجزاء التي يمكن أو لا يمكن تغييرها دون سابق إنذار. بهذه الطريقة، حتى عندما تحتاج إلى تغيير أو إصلاح أشياء تحت الغطاء في المكتبة، يمكن للأشياء الأخرى الاستمرار في استخدام API والاعتماد على أن لا شيء سيتغير بشكل غير متوقع. بالإضافة إلى ذلك، من الأسهل بكثير الاطلاع على وحدة ومعرفة ما يمكن استخدامها من أجله (المزيد عن ذلك لاحقًا).
مزايا البرمجة المعيارية
المزايا الرئيسية للبرمجة المعيارية هي أن تقسيم برنامج برمجي كبير إلى أجزاء أصغر يجعل تطوير تلك المشاريع الكبيرة وصيانتها أسهل. ويأتي هذا مع عدد من الفوائد، منها:
- سهولة قراءة الكود
البرمجة المعيارية تجعل قراءة الكود أسهل لأنها تفصل البرنامج إلى وظائف منفصلة، بحيث يتعامل كل جزء مع جانب واحد من الوظيفة الإجمالية. بالمقارنة مع الأكواد المتكاملة، يمكن أن يجعل ذلك ملفاتك أصغر وأسهل للفهم.
ومع ذلك، قد تصبح البرمجة المعيارية غير منظمة إذا قمت بتقسيم الأمور إلى وظائف صغيرة جدًا، أو إذا كنت تمرر البيانات أو الوظائف بين العديد من الملفات. ولكن إذا قسمت الوحدات بشكل منطقي، فإنها تعمل بشكل أفضل من وظيفة تحتوي على مئات الأسطر!
بشكل مختصر – الوظيفة الصغيرة ذات الاسم الوصفي الجيد يمكن أن تساعدك على فهم كتلة الكود دون الحاجة إلى تعليق.
- سهولة اختبار الكود
البرامج التي تقسم إلى وحدات مستقلة تكون مثالية للاختبار. ذلك لأن الاختبارات يمكن أن تكون أكثر صرامة وتفصيلًا عندما تختبر وظائف صغيرة تؤدي مهام قليلة، مقارنة بوظائف كبيرة تؤدي العديد من المهام. وهذا صحيح بشكل خاص إذا كان بإمكانك اختبار مخرجات الوظيفة فقط، وليس الخطوات التي تتبعها.
بالإضافة إلى ذلك، قد تعني الاختبارات الأسهل الحاجة إلى تعليقات كبيرة ومفصلة أقل، حيث يمكن للاختبارات أن تعمل كأمثلة على كيفية عمل الكود. إذا لم تفهم كتلة من الكود، فإن مراجعة الاختبارات يمكن أن تكون طريقة سهلة للحصول على فهم أفضل.
- سهولة العثور على الأشياء لاحقًا
تنطوي المعيارية على تجميع أنواع الوظائف المشابهة في ملفاتها ومكتباتها الخاصة، وتقسيم الوظائف المساعدة ذات الصلة إلى ملفاتها الخاصة بدلاً من تركها مختلطة مع الكود الرئيسي.
- إعادة الاستخدام دون تضخم
غالبًا ما تحتاج إلى استخدام نفس الكود أو الوظيفة في أماكن متعددة. بدلاً من نسخ ولصق الكود، تتيح لك المعيارية سحب الكود من مصدر واحد عن طريق استدعائه من الوحدة أو المكتبة التي يوجد فيها.
هذا يقلل من التضخم والحجم لأننا لا نمتلك نسخًا متعددة من كل جزء من الكود الذي يؤدي وظيفة معينة.
- مصدر واحد لإصلاحات أسرع
مع توفير كل وحدة مصدرًا واحدًا للحقيقة لوظائفك المحددة، يتم تقليل عدد الأماكن التي قد تحدث فيها الأخطاء، مما يجعل الإصلاح أسرع عندما تحدث الأخطاء. هذا يقلل من خطر المشاكل الناجمة عن اعتماد جزءين من الكود على تنفيذين مختلفين قليلاً لنفس الوظيفة.
وإذا كان هناك خطأ في الكود أو كنت بحاجة إلى تحديث وظيفة معينة، عليك فقط إصلاحه في وحدة واحدة، وكل ما يستخدمه يتم تحديثه على الفور. في حين أنه إذا قمت بنسخ ولصق الكود في أماكن مختلفة، قد يفوتك تحديث واحدة أو اثنتين من الحالات.
- تحديثات أسهل وأقل خطرًا
مع البرمجة المعيارية، يكون لكل مكتبة طبقة واجهة برمجة تطبيقات (API) محددة، والتي تحمي الأشياء التي تعتمد عليها من التغييرات داخل المكتبة. طالما أنك لا تغير واجهة برمجة التطبيقات، يكون هناك خطر أقل بكثير لكسر الكود الذي يعتمد على التغيير الذي قمت به.
بالطبع، يجب عليك توخي الحذر دائمًا، لكن واجهات برمجة التطبيقات تساعد بالتأكيد على توضيح الأمور عند الاقتراب من تغيير وظيفة عامة. على سبيل المثال، إذا لم تكن لديك واجهات برمجة تطبيقات واضحة وقام شخص ما بتغيير وظيفة اعتقد أنها تستخدم فقط داخل المكتبة نفسها (لكنها كانت تستخدم في مكان آخر)، فقد يتسبب ذلك في كسر شيء ما بشكل غير متعمد.
- إعادة هيكلة أسهل
مع البرمجة المعيارية، قد يكون إعادة الهيكلة أسهل. هناك العديد من الأسباب لذلك، ولكن كمثال، يمكن لكل من واجهات برمجة التطبيقات واتباع هيكل ملف/مجلد صارم أن يساعدك إذا كنت ترغب في كتابة سكريبت أو أتمتة إعادة الهيكلة.
ثم تمكنا من الاستفادة من هذه المعيارية المتزايدة (خاصة هيكل واجهة برمجة التطبيقات الذي قدمناه) عند أتمتة أجزاء من تحويل TypeScript. كما ساعدنا ذلك في العمل اليدوي اللاحق، حيث كنا نعمل على أقسام مختلفة، مكونًا بمكون ومكتبة بمكتبة. وبعد سنوات لا تزال هذه الهيكلية تساعدنا في تأهيل المطورين الجدد، والعثور على الأخطاء وإصلاحها، وإضافة ميزات جديدة، والعديد من الأمور الأخرى.
قيمة ومستقبل البرمجة المعيارية
البرمجة المعيارية ليست بجديدة، لكنها لا تزال شائعة جدًا، ولهذا من المهم أن يتعلم المطورون ما هي ولماذا هي مفيدة. لماذا؟ لأن الطريقة التي تم بها إعداد العديد من المكتبات والإطارات والمدراء الحزميين اليوم لمشاركة الأكواد وإدارة الاعتماديات، تجعل البرمجة المعيارية خيارًا طبيعيًا.
على سبيل المثال، هناك العديد من مكتبات NPM التي تقوم بعمل واحد فقط. كما يستخدم المزيد والمزيد من المطورين إطارات تقوم بأشياء محددة فقط، مثل Bulma، وهو إطار عمل CSS بسيط مقارنة ببعض الإطارات الأخرى الشهيرة في CSS.
قد لا تبدو المكتبات الأصغر إثارة للإعجاب بسبب توفرها على وظائف أقل، لكن هناك أيضًا تعلم أقل مطلوب قبل أن تتمكن من استخدامها، وعادة ما تكون أصغر حجمًا، لذا يكون هناك أقل تشبعًا بالأكواد مقارنة بالمكتبات الأكبر.
من المهم أن يدرك المطورون أن تطوير البرمجيات لا يتعلق فقط بكتابة الأكواد، خاصة في بيئة JavaScript. بل يتعلق أيضًا بالقدرة على العثور على الكتل البنائية الصحيحة وتحليلها واستخدامها، مع كتابة تطبيقات قوية وقابلة للصيانة. المعيارية هي الخلفية لكل هذه الجوانب، وهذا هو السبب في أنها قيمة جدًا.
