مرحبا اصدقاء. تحسبا لانطلاق الدورة ، يشاركونك تقليديًا ترجمة المواد المفيدة.
يحل البرنامج المزيد والمزيد من المهام اليومية ، بينما يزداد تعقيدًا. كما قال مارك أندرسن ذات مرة ، إنها تلتهم العالم.
نتيجة لذلك ، تغيرت طريقة تطوير التطبيقات وتقديمها بشكل كبير خلال السنوات القليلة الماضية. كانت هذه تحولات في النطاق التكتوني نتج عنها مجموعة من المبادئ. لقد أثبتت هذه المبادئ أنها مفيدة في بناء الفريق وتصميم وتطوير وتقديم تطبيقك إلى المستخدمين النهائيين.
يمكن تلخيص المبادئ على النحو التالي: يجب أن يكون التطبيق صغيرًا ومستندًا إلى الويب وله بنية تتمحور حول المطور. مع وضع هذه المبادئ الثلاثة في الاعتبار ، يمكنك إنشاء تطبيق قوي وشامل يمكن تسليمه بسرعة وأمان إلى المستخدم النهائي ، وقابل للتطوير والتوسيع بسهولة.
يحتوي كل مبدأ من المبادئ المقترحة على عدد من الجوانب التي سنناقشها لإظهار كيف يساهم كل مبدأ في الهدف النهائي ، وهو التسليم السريع للتطبيقات الموثوقة التي يسهل صيانتها واستخدامها. سننظر في المبادئ المتعلقة بأضدادها من أجل توضيح ما تعنيه ، قل ، "تأكد من استخدام مبدأ الصغر".
نأمل أن تشجعك هذه المقالة على استخدام المبادئ المقترحة لبناء تطبيقات حديثة ، والتي ستوفر نهجًا موحدًا للتصميم في سياق مجموعة تقنية متنامية باستمرار.
من خلال تطبيق هذه المبادئ ، ستجد نفسك تستفيد من أحدث الاتجاهات في تطوير البرامج ، بما في ذلك لتطوير وتسليم التطبيقات ، واستخدام الحاويات (على سبيل المثال ، ) وأطر تنظيم الحاويات (على سبيل المثال ، ) ، واستخدام الخدمات المصغرة (بما في ذلك بنية الخدمات المصغرة и لتطبيقات الخدمات المصغرة.
ما هو التطبيق الحديث؟
التطبيقات الحديثة؟ المكدس الحديث؟ ماذا تعني كلمة "حديث" بالضبط؟
لدى معظم المطورين فكرة عامة فقط عما يتكون منه التطبيق الحديث ، لذلك من الضروري تحديد هذا المفهوم بوضوح.
يدعم التطبيق الحديث العديد من العملاء ، سواء كانت واجهة مستخدم مكتبة React JavaScript ، أو تطبيق Android أو iOS للجوال ، أو تطبيق يتصل بواجهة برمجة تطبيقات أخرى. يشير التطبيق الحديث إلى عدد غير محدد من العملاء الذين يوفر لهم بيانات أو خدمات.
يوفر التطبيق الحديث واجهة برمجة تطبيقات للوصول إلى البيانات والخدمات المطلوبة. يجب أن تكون واجهة برمجة التطبيقات ثابتة وغير قابلة للتغيير ، وليست مكتوبة خصيصًا لطلب معين من عميل معين. API متاح عبر HTTP (S) ويوفر الوصول إلى جميع الوظائف المتاحة في واجهة المستخدم الرسومية أو CLI.
يجب أن تكون البيانات متاحة بتنسيق مقبول بشكل عام وقابل للتشغيل المتبادل مثل JSON. تعرض واجهة برمجة التطبيقات (API) الكائنات والخدمات بطريقة نظيفة ومنظمة ، مثل RESTful API أو GraphQL التي توفر واجهة مناسبة.
التطبيقات الحديثة مبنية على المكدس الحديث ، والمكدس الحديث هو المكدس الذي يدعم مثل هذه التطبيقات ، على التوالي. يسمح هذا المكدس للمطور بإنشاء تطبيق بسهولة باستخدام واجهة HTTP ونقاط نهاية API الواضحة. سيسمح النهج المختار لتطبيقك بتلقي البيانات وإرسالها بسهولة بتنسيق JSON. بمعنى آخر ، المكدس الحديث يتوافق مع عناصر تطبيق Twelve-Factor Application for .
الإصدارات الشائعة من هذا النوع من المكدس تعتمد على , , , , и . بنية الخدمات المصغرة يمثل مثالاً على مجموعة حديثة مطبقة في كل من اللغات المذكورة.
يرجى ملاحظة أننا لا ندافع عن نهج الخدمات المصغرة حصريًا. يعمل العديد منكم مع وحدات متجانسة تحتاج إلى التطور ، بينما يتعامل الآخرون مع تطبيقات SOA التي تتوسع وتتطور لتصبح تطبيقات خدمات مصغرة. لا يزال البعض الآخر يتجه نحو تطبيقات بدون خادم ، ويقوم البعض بتنفيذ مجموعات مما سبق. تنطبق المبادئ الموضحة في المقالة على كل نظام من هذه الأنظمة مع بعض التعديلات الطفيفة فقط.
مبادئ
الآن بعد أن أصبح لدينا فهم مشترك لما هو التطبيق الحديث والمكدس الحديث ، فقد حان الوقت للتعمق في مبادئ الهندسة المعمارية والتطوير التي ستخدمك جيدًا في تطوير تطبيق حديث وتطبيقه وصيانته.
أحد المبادئ يبدو مثل "إنشاء تطبيقات صغيرة" ، دعنا نسميها فقط مبدأ الصغر. هناك تطبيقات معقدة بشكل لا يصدق تتكون من العديد من الأجزاء المتحركة. في المقابل ، يؤدي إنشاء تطبيق من مكونات صغيرة منفصلة إلى تسهيل تصميمه وصيانته والعمل معه ككل. (لاحظ أننا قلنا "يبسط" لا "يجعله بسيطًا").
المبدأ الثاني هو أنه يمكننا زيادة إنتاجية المطورين من خلال مساعدتهم على التركيز على الميزات التي يطورونها ، مع تحريرهم من البنية التحتية ومخاوف CI / CD أثناء التنفيذ. إذن ، باختصار ، نهجنا تركز على المطورين.
أخيرًا ، يجب توصيل كل شيء يتعلق بتطبيقك بالشبكة. على مدار العشرين عامًا الماضية ، قطعنا خطوات كبيرة نحو مستقبل متصل بالشبكات حيث أصبحت الشبكات أسرع وتطبيقاتها أكثر تعقيدًا. كما رأينا بالفعل ، يجب استخدام تطبيق حديث عبر شبكة بواسطة العديد من العملاء المختلفين. إن تطبيق التفكير الشبكي على الهندسة المعمارية له فوائد كبيرة تتماشى معها مبدأ الصغر ومفهوم النهج ، موجه المطور.
إذا وضعت هذه المبادئ في الاعتبار عند تصميم تطبيق ما وتنفيذه ، فستتمتع بميزة لا يمكن إنكارها في تطوير منتجك وتسليمه.
دعونا نلقي نظرة على هذه المبادئ الثلاثة بمزيد من التفصيل.
مبدأ الصغر
يصعب على الدماغ البشري إدراك كمية كبيرة من المعلومات في نفس الوقت. في علم النفس ، يشير مصطلح الحمل المعرفي إلى المقدار الإجمالي للجهد العقلي المطلوب للاحتفاظ بالمعلومات في الذاكرة. يعد تقليل العبء المعرفي على المطورين أولوية لأنه يسمح لهم بالتركيز على حل المشكلة بدلاً من الاحتفاظ بالنموذج المعقد الحالي للتطبيق بأكمله والميزات التي يتم تطويرها في رؤوسهم.
تتحلل الطلبات للأسباب التالية:
- انخفاض الحمل المعرفي على المطورين ؛
- تسريع وتبسيط الاختبار ؛
- سرعة تسليم التغييرات في التطبيق.
هناك عدة طرق لتقليل العبء المعرفي على المطورين ، وهنا يأتي دور مبدأ الصغر.
إذن ، إليك ثلاث طرق لتقليل العبء المعرفي:
- قلل الإطار الزمني الذي يتعين عليهم مراعاته عند تطوير ميزة جديدة - فكلما كان الإطار الزمني أقصر ، انخفض الحمل المعرفي.
- قلل مقدار الكود الذي يتم تنفيذ العمل لمرة واحدة عليه - كود أقل - حمولة أقل.
- تبسيط عملية إجراء تغييرات تدريجية على أحد التطبيقات.
تقليص الإطار الزمني للتطوير
دعنا نعود إلى الأيام التي كانت فيها المنهجية waterfall هو المعيار لعملية التطوير ، وكانت الأطر الزمنية من ستة أشهر إلى سنتين لتطوير أو تحديث التطبيق ممارسة شائعة. عادةً ما يقرأ المهندسون المستندات ذات الصلة أولاً مثل متطلبات المنتج (PRD) ، والوثيقة المرجعية للنظام (SRD) ، ومخطط الهندسة المعمارية ، ويبدأون في دمج كل هذه الأشياء معًا في نموذج معرفي واحد ، وفقًا لترميزهم. مع تغير المتطلبات وبالتالي الهيكل ، كان لا بد من بذل جهد جاد لإبلاغ الفريق بأكمله عن تحديثات النموذج المعرفي. مثل هذا النهج ، في أسوأ الأحوال ، يمكن ببساطة أن يشل العمل.
كان التغيير الأكبر في عملية تطوير التطبيق هو إدخال منهجية أجايل. واحدة من السمات الرئيسية للمنهجية agile هو تطور تكراري. وهذا بدوره يؤدي إلى تقليل العبء المعرفي على المهندسين. بدلاً من مطالبة فريق التطوير بتنفيذ التطبيق في دورة واحدة طويلة ، agile يتيح لك الأسلوب التركيز على كميات صغيرة من التعليمات البرمجية التي يمكن اختبارها ونشرها بسرعة ، مع تلقي التعليقات أيضًا. لقد تحول الحمل المعرفي للتطبيق من إطار زمني مدته ستة أشهر إلى عامين مع قدر كبير من المواصفات لإضافة أو تغيير ميزة لمدة أسبوعين يستهدف فهمًا أكثر وضوحًا لتطبيق كبير.
يعد تحويل التركيز من تطبيق ضخم إلى ميزات صغيرة محددة يمكن إكمالها في سباق لمدة أسبوعين ، مع عدم وجود أكثر من ميزة واحدة قبل السباق التالي ، تغييرًا مهمًا. سمح لنا ذلك بزيادة إنتاجية التطوير مع تقليل العبء المعرفي الذي يتقلب باستمرار.
في المنهجية agile من المتوقع أن يكون التطبيق النهائي نسخة معدلة قليلاً من المفهوم الأصلي ، وبالتالي فإن نقطة نهاية التطوير غامضة بالضرورة. يمكن أن تكون نتائج كل سباق محدد فقط واضحة ودقيقة.
قواعد أكواد صغيرة
تتمثل الخطوة التالية في تقليل الحمل المعرفي في تقليل قاعدة الكود. كقاعدة عامة ، التطبيقات الحديثة ضخمة - يمكن أن يتكون تطبيق المؤسسة القوي من آلاف الملفات ومئات الآلاف من أسطر التعليمات البرمجية. اعتمادًا على كيفية تنظيم الملفات ، قد تكون الروابط والتبعيات بين الكود والملفات واضحة ، أو العكس. حتى تنفيذ التعليمات البرمجية لتصحيح الأخطاء نفسها يمكن أن يكون مشكلة ، اعتمادًا على المكتبات المستخدمة ومدى تميز أدوات التصحيح بين المكتبات / الحزم / الوحدات النمطية والرمز المخصص.
يمكن أن يستغرق بناء نموذج عقلي عملي لرمز التطبيق وقتًا مثيرًا للإعجاب ، ومرة أخرى يضع عبئًا معرفيًا كبيرًا على المطور. ينطبق هذا بشكل خاص على قواعد الكود المتجانسة ، حيث يوجد قدر كبير من التعليمات البرمجية ، والتفاعل بين المكونات الوظيفية التي لم يتم تحديدها بوضوح ، وغالبًا ما يكون الفصل بين كائنات الانتباه غير واضح بسبب عدم احترام الحدود الوظيفية.
تتمثل إحدى الطرق الفعالة لتقليل العبء المعرفي على المهندسين في الانتقال إلى بنية الخدمات المصغرة. في نهج الخدمات المصغرة ، تركز كل خدمة على مجموعة واحدة من الميزات ؛ في حين أن معنى الخدمة عادة ما يكون محددًا ومفهومًا. حدود الخدمة واضحة أيضًا - تذكر أن الاتصال بالخدمة يتم عبر واجهة برمجة التطبيقات ، لذلك يمكن بسهولة تمرير البيانات التي تم إنشاؤها بواسطة خدمة إلى أخرى.
عادةً ما يقتصر التفاعل مع الخدمات الأخرى على عدد قليل من خدمات المستخدم وعدد قليل من خدمات الموفر التي تستخدم مكالمات واجهة برمجة تطبيقات بسيطة ونظيفة ، مثل استخدام REST. هذا يعني أن العبء المعرفي على المهندس قد انخفض بشكل خطير. يظل التحدي الأكبر هو فهم نموذج تفاعل الخدمة وكيف تحدث أشياء مثل المعاملات عبر خدمات متعددة. نتيجة لذلك ، يقلل استخدام الخدمات المصغرة العبء المعرفي عن طريق تقليل كمية الكود ، وتحديد حدود خدمة واضحة ، وتوفير فهم للعلاقة بين المستخدمين ومقدمي الخدمات.
تغييرات صغيرة تزايدي
العنصر الأخير في المبدأ صغر هي إدارة التغيير. إنه إغراء خاص للمطورين للنظر في قاعدة الكود (حتى الشفرة القديمة الخاصة بهم) والقول ، "هذا هراء ، نحتاج إلى إعادة كتابته كلها." أحيانًا يكون هذا هو القرار الصحيح ، وأحيانًا لا يكون كذلك. إنه يضع عبء تغيير النموذج العالمي على فريق التطوير ، مما يؤدي بدوره إلى عبء معرفي هائل. من الأفضل للمهندسين التركيز على التغييرات التي يمكنهم إجراؤها أثناء العدو ، حتى يتمكنوا من طرح الوظائف الضرورية في الوقت المناسب ، وإن كان ذلك تدريجيًا. يجب أن يكون المنتج النهائي مشابهًا للمنتج المخطط مسبقًا ، ولكن مع بعض التعديلات والاختبارات ليناسب احتياجات العميل.
عند إعادة كتابة أجزاء كبيرة من التعليمات البرمجية ، يتعذر أحيانًا تقديم التغيير بسرعة لأن تبعيات النظام الأخرى تدخل حيز التنفيذ. للتحكم في تدفق التغييرات ، يمكنك استخدام إخفاء الميزات. من حيث المبدأ ، هذا يعني أن الوظيفة قيد الإنتاج ، ولكنها غير متاحة باستخدام إعدادات متغير البيئة (env-var) أو بعض آليات التكوين الأخرى. إذا اجتاز الكود جميع عمليات مراقبة الجودة ، فقد ينتهي به الأمر في الإنتاج في حالة كامنة. ومع ذلك ، لا تعمل هذه الإستراتيجية إلا إذا تم تمكين الميزة في النهاية. خلاف ذلك ، سيؤدي فقط إلى تشويش الكود وإضافة عبء معرفي سيتعين على المطور التعامل معه من أجل أن يكون منتجًا. تساعد إدارة التغيير والتغييرات الإضافية نفسها في الحفاظ على العبء المعرفي للمطورين عند مستوى معقول.
يتعين على المهندسين التغلب على العديد من الصعوبات حتى مع الإدخال البسيط للوظائف الإضافية. من جانب الإدارة ، سيكون من الحكمة تقليل العبء غير الضروري على الفريق حتى يتمكن من التركيز على العناصر الوظيفية الرئيسية. هناك ثلاثة أشياء يمكنك القيام بها لمساعدة فريق التطوير الخاص بك:
- منهجية الاستخدام
agileللحد من الإطار الزمني الذي يجب أن يركز فيه الفريق على الميزات الرئيسية. - تنفيذ تطبيقك كخدمات مصغرة متعددة. سيحد هذا من عدد الميزات التي يمكن تنفيذها ويعزز الحدود التي تحافظ على العبء المعرفي في العمل.
- تفضل التغييرات المتزايدة على الأجزاء الصغيرة من التعليمات البرمجية الكبيرة وغير العملية. استخدم ميزة إخفاء الميزة لتنفيذ التغييرات حتى إذا لم تكن مرئية على الفور بعد إضافتها.
إذا قمت بتطبيق مبدأ الصغر في عملك ، فسيكون فريقك أكثر سعادة ، ويركز بشكل أفضل على تنفيذ الميزات الضرورية ، ومن المرجح أن يطرح التغييرات النوعية بشكل أسرع. لكن هذا لا يعني أن العمل لا يمكن أن يصبح أكثر تعقيدًا ، ففي بعض الأحيان ، على العكس من ذلك ، يتطلب إدخال وظيفة جديدة تعديل العديد من الخدمات ، ويمكن أن تكون هذه العملية أكثر صعوبة من مماثلة في بنية متجانسة. على أي حال ، فإن فوائد اتباع نهج الصغر تستحق العناء.
نهاية الجزء الأول.
قريباً سننشر الجزء الثاني من الترجمة ، والآن ننتظر تعليقاتكم وندعوكم لها ، والتي ستقام اليوم في الساعة 20.00.
المصدر: www.habr.com