مرحبا اصدقاء تحسبا لإطلاق دورة
"Backend PHP Developer" ، فإننا نشارككم تقليديا في ترجمة المواد المفيدة.
يحل البرنامج المهام اليومية أكثر وأكثر ، بينما يصبح أكثر وأكثر صعوبة. كما قال مارك أندريسن ذات مرة ، إنه يبتلع العالم.
نتيجة لذلك ، تغيرت أساليب تطوير التطبيقات وتسليمها بشكل كبير خلال السنوات القليلة الماضية. كانت هذه تحولات على نطاق تكتوني ، مما أدى إلى ظهور مجموعة من المبادئ. لقد أثبتت هذه المبادئ أنها مفيدة في بناء الفريق وتصميمه وتطويره وتقديمه للمستخدمين النهائيين.
يمكن تلخيص المبادئ على النحو التالي:
يجب أن يكون التطبيق صغيرًا ، وموصل شبكيًا ، وأن يكون له بنية موجهة للمطورين . بناءً على هذه المبادئ الثلاثة ، يمكنك إنشاء تطبيق موثوق وشامل يمكن تسليمه بسرعة وأمان إلى المستخدم النهائي ، ويمكن زيادته وتوسيعه بسهولة.
يحتوي كل مبدأ من المبادئ المقترحة على عدد من الجوانب التي سنناقشها لإظهار كيف يساهم كل مبدأ في تحقيق الهدف النهائي ، وهو التسليم السريع للتطبيقات الموثوقة التي يسهل صيانتها واستخدامها. سننظر في المبادئ بالمقارنة مع الأضداد من أجل توضيح ما يعنيه ، قل ، "تأكد من أنك تستخدم
مبدأ الصغر ".
نأمل أن يشجعك هذا المقال على استخدام المبادئ المقترحة لبناء التطبيقات الحديثة التي ستوفر نهجًا موحدًا للتصميم في سياق تكدس التكنولوجيا المتزايد باستمرار.
من خلال تطبيق هذه المبادئ ، ستجد
نفسك تستفيد من أحدث اتجاهات تطوير البرمجيات ، بما في ذلك نهج
DevOps لتطوير وتقديم التطبيقات ، وذلك باستخدام الحاويات (مثل
Docker ) والأطر
لتنسيق الحاويات (مثل
Kubernetes ) ، واستخدام خدمات microservices (بما في ذلك
NGINX Microservice Architecture)
وهندسة الاتصالات على شبكة الإنترنت لتطبيقات microservice.
ما هو التطبيق الحديث؟التطبيقات الحديثة؟ كومة الحديثة؟ ماذا تعني كلمة "حديث" بالضبط؟
ليس لدى معظم المطورين سوى فكرة عامة عما يتكون عليه التطبيق الحديث ، لذلك تحتاج إلى تقديم تعريف واضح لهذا المفهوم.
يدعم التطبيق الحديث العديد من العملاء ، سواء كان واجهة مستخدم في مكتبة JavaScript React ، أو تطبيق جوال لنظام Android أو iOS ، أو تطبيقًا يتصل بآخر عبر واجهة برمجة التطبيقات. يتضمن التطبيق الحديث وجود عدد غير محدد من العملاء الذين يقدم لهم بيانات أو خدمات.
يوفر التطبيق الحديث واجهة برمجة تطبيقات للوصول إلى البيانات والخدمات المطلوبة. يجب أن تكون واجهة برمجة التطبيقات ثابتة وغير ثابتة ، ولا تتم كتابتها خصيصًا لطلب معين من أي عميل معين. يمكن الوصول إلى API عبر HTTP (S) ويوفر الوصول إلى جميع الوظائف الموجودة في واجهة المستخدم الرسومية أو CLI.
يجب أن يكون الوصول إلى البيانات بتنسيق مقبول عمومًا ، مثل JSON. توفر واجهة برمجة التطبيقات (API) كائنات وخدمات بطريقة واضحة ومنظمة ، على سبيل المثال ، توفر واجهة برمجة تطبيقات RESTful أو GraphQL واجهة مناسبة.
التطبيقات الحديثة مبنية على مكدس حديث ، والمكدس الحديث هو المكدس الذي يدعم مثل هذه التطبيقات ، على التوالي. تسمح هذه المجموعة للمطور بإنشاء تطبيق بسهولة من خلال واجهة HTTP ومسح نقاط النهاية لواجهة برمجة التطبيقات. سيسمح النهج الذي تم اختياره للتطبيق الخاص بك بسهولة استلام وإرسال البيانات بتنسيق JSON. بمعنى آخر ، المكدس الحديث يتوافق مع عناصر تطبيق Twelve-Factor للخدمات
الميكروية .
تعتمد الإصدارات الشائعة من هذا النوع من المكدس على
Java و
Python و
Node و
Ruby و
PHP و
Go .
يمثل NGINX Microservice Architecture مثالاً على مكدس حديث تم تنفيذه في كل من اللغات المذكورة.
يرجى ملاحظة أننا لا ندافع حصريًا عن نهج الخدمات المجهرية. يعمل الكثير منكم مع متجانسات تحتاج إلى التطور ، بينما يتعامل الآخرون مع تطبيقات الخدمية التي تتوسع وتتطور لتصبح تطبيقات خدمات ميكروية. لا يزال البعض الآخر يتجه نحو التطبيقات بدون خادم ، والبعض الآخر يقدم مجموعات مما سبق. تنطبق المبادئ الواردة في المقالة على كل نظام من هذه الأنظمة مع بعض التغييرات الطفيفة فقط.
مبادئالآن بعد أن أصبح لدينا فهم مشترك لماهية التطبيق الحديث والمكدس الحديث ، فقد حان الوقت لتنغمس في مبادئ الهندسة المعمارية والتنمية التي ستخدمك جيدًا في تطوير وتطبيق ودعم تطبيق حديث.
أحد المبادئ هو "إنشاء تطبيقات صغيرة" ، دعنا فقط نسميها
مبدأ الصغر . هناك تطبيقات معقدة بشكل لا يصدق تتكون من عدد كبير من المكونات المتحركة. بدوره ، فإن بناء تطبيق من مكونات منفصلة صغيرة يبسط تصميمه وصيانته والعمل معه ككل. (لاحظ ، قلنا "يبسط" ، وليس "يجعل الأمر بسيطًا.")
المبدأ الثاني هو أنه يمكننا زيادة إنتاجية المطورين من خلال مساعدتهم على التركيز على الميزات التي يطورونها ، مع تحريرهم من المخاوف بشأن البنية التحتية و CI / CD أثناء التنفيذ. لذلك ، باختصار ،
يركز نهجنا
على المطورين .
أخيرًا ، يجب توصيل كل شيء عن التطبيق الخاص بك بالشبكة. على مدار العشرين عامًا الماضية ، قطعنا خطوات كبيرة نحو مستقبل متصل بالشبكة ، حيث أن الشبكات أسرع والتطبيقات أكثر تعقيدًا. كما اكتشفنا بالفعل ، يجب استخدام تطبيق حديث عبر الشبكة من قبل العديد من العملاء المختلفين. يتميز استخدام التفكير الشبكي في الهندسة المعمارية بمزايا كبيرة تتوافق مع
مبدأ الصغر ومفهوم النهج
الموجه للمطور .
إذا كنت ستدرك هذه المبادئ أثناء تطوير التطبيق وتنفيذه ، فسيكون لديك ميزة لا يمكن إنكارها في تطوير منتجك وتسليمه.
دعونا نلقي نظرة على هذه المبادئ الثلاثة بمزيد من التفصيل.
مبدأ الصغرمن الصعب على الدماغ البشري أن يدرك في الوقت نفسه كمية كبيرة من المعلومات. في علم النفس ، يعني مصطلح الحمل المعرفي المبلغ الإجمالي للجهد العقلي المطلوب لتخزين المعلومات في الذاكرة. يعد تقليل الحمل المعرفي للمطورين أولوية ، لأنه في هذه الحالة يمكنهم التركيز على حل المشكلة ، بدلاً من مراعاة النموذج المعقد الحالي للتطبيق بأكمله والوظائف المطورة.
يتم تحليل الطلبات للأسباب التالية:
- انخفاض في الحمل المعرفي على المطورين ؛
- تسريع وتبسيط الاختبار ؛
- تسليم سريع للتغييرات في التطبيق.
هناك عدة طرق لتقليل العبء المعرفي على المطورين ، وهنا يأتي دور مبدأ الصغر.
لذلك ، هناك ثلاث طرق لتقليل الحمل المعرفي:
- قلل من الإطار الزمني الذي يجب أن يأخذوه في الاعتبار عند تطوير وظيفة جديدة - كلما كان الإطار الزمني أقصر ، انخفض الحمل المعرفي.
- قلل من مقدار الشفرة التي يتم تنفيذ العمل لمرة واحدة بها - رمز أقل - حمل أقل.
- تبسيط عملية إجراء تغييرات تدريجية على التطبيق.
تقليل الجداول الزمنية للتنميةدعنا نعود إلى الأيام التي كانت فيها منهجية
waterfall هي المعيار لعملية التطوير ، وكان الإطار الزمني من ستة أشهر إلى سنتين لتطوير أو تحديث التطبيق ممارسة شائعة. عادةً ما يقوم المهندسون أولاً بقراءة المستندات ذات الصلة ، مثل متطلبات المنتج (PRD) ، ووثيقة مرجع النظام (SRD) ، وخطة الهندسة المعمارية ، وبدأوا في الجمع بين كل هذه الأشياء معًا في نموذج إدراكي واحد ، وفقًا لكتابة التعليمات البرمجية. مع تغير المتطلبات ، وبناءً على ذلك ، تغيرت الهندسة المعمارية ، يجب بذل جهود جادة لإبلاغ الفريق بأكمله بالتحديثات إلى النموذج المعرفي. في أسوأ الحالات ، يمكن لمثل هذا النهج ببساطة أن يشل العمل.
كان أكبر تغيير في عملية تطوير التطبيق إدخال منهجية رشيقة. واحدة من السمات الرئيسية للمنهجية
agile هو التطور التكراري. وهذا بدوره يؤدي إلى انخفاض في الحمل المعرفي على المهندسين. بدلاً من مطالبة فريق التطوير بتنفيذ التطبيق في دورة واحدة طويلة ، يسمح لك النهج
agile بالتركيز على الكميات الصغيرة من الكود التي يمكن اختبارها ونشرها بسرعة ، مع تلقي الملاحظات أيضًا. لقد تحول العبء المعرفي للتطبيق من الإطار الزمني من ستة أشهر إلى عامين ، مع مراعاة العدد الهائل من المواصفات لإضافة تغييرات أو ميزات لمدة أسبوعين ، بهدف فهم أكثر غموضًا للتطبيق الكبير.
يعد تغيير التركيز من تطبيق كبير إلى وظائف صغيرة محددة يمكن إكمالها في سباق لمدة أسبوعين ، بالنظر إلى ما لا يزيد عن وظيفة واحدة من العدو التالي في الرأس ، تغييرًا كبيرًا. هذا سمح لنا بزيادة إنتاجية التطوير مع تقليل الحمل المعرفي ، الذي يتقلب باستمرار.
تفترض المنهجية
agile أن التطبيق النهائي سيكون نسخة معدلة قليلاً من المفهوم الأصلي ، وبالتالي فإن نقطة التطوير النهائية غامضة بالضرورة. فقط نتائج كل سباق معين يمكن أن تكون واضحة ودقيقة.
codebases الصغيرةالخطوة التالية في تقليل الحمل المعرفي هي تقليل قاعدة الكود. كقاعدة عامة ، تعتبر التطبيقات الحديثة ضخمة - يمكن أن يتألف التطبيق المؤسسي الموثوق من آلاف الملفات ومئات الآلاف من أسطر التعليمات البرمجية. بناءً على تنظيم ملفات الاتصال وتبعيات التعليمات البرمجية والملفات ، قد تكون واضحة أو العكس. حتى تصحيح الكود نفسه يمكن أن يسبب مشاكل ، اعتمادًا على المكتبات المستخدمة ومدى التمييز بين أدوات التصحيح بين المكتبات / الحزم / الوحدات النمطية ورمز المستخدم.
يمكن أن يستغرق بناء نموذج عقلي يعمل لرمز التطبيق قدراً هائلاً من الوقت ، ويضع مرةً أخرى عبءًا إدراكيًا كبيرًا على المطور. ينطبق هذا بشكل خاص على قواعد الشفرة المتجانسة ، حيث يوجد مقدار كبير من الشفرة ، والتفاعل بين المكونات الوظيفية التي لم يتم تعريفها بوضوح ، وغالبًا ما يتم فصل الفصل بين أشياء الاهتمام ، نظرًا لعدم احترام الحدود الوظيفية.
تتمثل إحدى الطرق الفعالة لتقليل الحمل المعرفي على المهندسين في الانتقال إلى بنية الخدمات المصغرة. في نهج microservice ، تركز كل خدمة على مجموعة واحدة من الوظائف ؛ عادة ما يتم تعريف معنى الخدمة ومفهومة. حدود الخدمة واضحة أيضًا - تذكر أن التواصل مع الخدمة يتم باستخدام واجهة برمجة التطبيقات ، بحيث يمكن بسهولة نقل البيانات التي تم إنشاؤها بواسطة خدمة إلى خدمة أخرى.
عادةً ما يقتصر التفاعل مع الخدمات الأخرى على العديد من خدمات المستخدم والعديد من خدمات الموفر التي تستخدم مكالمات API بسيطة ونظيفة ، على سبيل المثال ، باستخدام REST. هذا يعني أن الحمل المعرفي على المهندس قد انخفض بشكل خطير. تتمثل المهمة الأكثر صعوبة في فهم نموذج التفاعل بين الخدمات وكيف تحدث أشياء مثل المعاملات في العديد من الخدمات. ونتيجة لذلك ، يقلل استخدام الخدمات المصغرة من الحمل المعرفي ، ويقلل من حجم الكود ، ويشير إلى حدود واضحة للخدمة ويوفر فهمًا للعلاقة بين المستخدمين ومقدمي الخدمات.
تغييرات تدريجية صغيرةالعنصر الأخير من مبدأ
الصغر هو إدارة التغيير. إنه لإغراء خاص للمطورين أن ينظروا إلى قاعدة الشفرة (حتى ، ربما ، من تلقاء أنفسهم ، رمز أقدم) ويقولون: "هذا هراء ، نحتاج إلى إعادة كتابته بالكامل." في بعض الأحيان هذا هو القرار الصحيح ، وأحيانا لا. يضع عبء تغيير النموذج العالمي على فريق التطوير ، الأمر الذي يؤدي بدوره إلى عبء إدراكي كبير. من الأفضل للمهندسين أن يركزوا على التغييرات التي يمكنهم إجراؤها أثناء العدو ، من أجل طرح الوظيفة اللازمة في وقت لاحق في الوقت المناسب ، وإن كان ذلك تدريجياً. يجب أن يذكرنا المنتج النهائي بمنتج مُخطط مسبقًا ، ولكن مع بعض التعديلات والاختبارات لتلبية احتياجات العملاء.
عند إعادة كتابة أجزاء كبيرة من الشفرة ، يكون من المستحيل أحيانًا تقديم التغييرات بسرعة ، نظرًا لأن التبعيات الأخرى للنظام تعمل هنا. للتحكم في تدفق التغييرات ، يمكنك استخدام إخفاء الميزة. من حيث المبدأ ، هذا يعني أن الوظيفة قيد الإنتاج ، ولكنها غير متوفرة باستخدام إعدادات متغيرات البيئة (env-var) أو بعض آليات التكوين الأخرى. إذا اجتاز الرمز جميع عمليات مراقبة الجودة ، فقد يكون قيد الإنتاج في حالة مخفية. ومع ذلك ، تعمل هذه الاستراتيجية فقط إذا تم تمكين الميزة في النهاية. خلاف ذلك ، لن يؤدي إلا إلى تناثر الشفرة وإضافة الحمل المعرفي ، والذي سيتعين على المطور التعامل معه من أجل العمل المنتج. إدارة التغيير والتغييرات الإضافية في حد ذاتها تساعد في الحفاظ على الحمل المعرفي للمطورين في مستوى بأسعار معقولة.
يتعين على المهندسين التغلب على العديد من الصعوبات حتى مع التنفيذ البسيط للوظائف الإضافية. من جانب الإدارة ، سيكون من المعقول تقليل العبء الإضافي على الفريق حتى يتمكن من التركيز على العناصر الأساسية للوظيفة. هناك ثلاثة أشياء يمكنك القيام بها لمساعدة فريق التطوير لديك:
- استخدم منهجية
agile للحد من الإطار الزمني الذي يجب أن يركز الفريق ضمنه على الوظائف الرئيسية. - تنفيذ التطبيق الخاص بك كما microservices متعددة. سيؤدي ذلك إلى الحد من عدد الميزات التي يتم تنفيذها وتعزيز الحدود التي تحمل الحمل المعرفي أثناء العمل.
- تفضل التغييرات الإضافية على الضخمة والكبيرة ، وتغيير قطع صغيرة من التعليمات البرمجية. استخدم ميزة إخفاء الميزة لتنفيذ التغييرات ، حتى إذا لم تكن مرئية بعد الإضافة مباشرةً.
إذا قمت بتطبيق مبدأ الصغر في عملك ، فسوف يصبح فريقك أكثر سعادة ، وسوف يركز بشكل أفضل على تنفيذ الوظائف الضرورية وعلى الأرجح سيؤدي إلى طرح التغييرات النوعية بشكل أسرع. لكن هذا لا يعني أن العمل لا يمكن أن يكون معقدًا ، بل على العكس في بعض الأحيان ، يتطلب إدخال وظائف جديدة تعديل العديد من الخدمات وهذه العملية يمكن أن تكون أكثر تعقيدًا من تلك المشابهة في بنية متجانسة. في أي حال ، فإن فوائد النهج الصغيرة تستحق العناء.
نهاية الجزء الاول.
قريباً سننشر الجزء الثاني من الترجمة ، ونحن الآن في انتظار تعليقاتكم ، ونحن ندعوك
لفتح اليوم ، الذي سيعقد اليوم في الساعة 20:00.