لقد أعددنا ترجمة لمقالة بقلم نيل فورد ، مهندس النظم والمدبر العقائدي في ThoughtWorks ، وهي شركة تطوير برمجيات تقوم بأتمتة اختبار البرمجيات وعمليات النشر.
نيل هو خبير تطوير برامج معروف يعمل على مفترق طرق التصميم الرشيق وهندسة النظم. وهو مؤلف العديد من المقالات والكتب وعشرات عروض الفيديو ، ويتحدث في المؤتمرات الرائدة للمطورين. يمكنك أن ترى عمله على
nealford.com .
الخدمات الدقيقة مثل العمارة التطورية
هندسة الخدمات الصغيرة تغزو العالم بسرعة. في مارس ، نظمت شركة النشر O'Reilly مؤتمرها الأول للهندسة المعمارية O'Reilly. وتم تخصيص 60٪ من التقارير تقريبًا لجوانب معينة من استخدام الخدمات الدقيقة. لماذا أصبح هذا النمط المعماري الخاص فجأة شائعًا جدًا؟
إن بنية Microservice هي نمط تصميم معماري جديد ظهر بعد DevOps ويتضمن ممارسات توصيل البرامج المستمرة. وهو أيضًا مثال على الهندسة التطورية التي تتبع مبدأ التغييرات التدريجية المستمرة في عدة أبعاد على المستوى الهيكلي للتطبيق. تتناول هذه المقالة بعض السمات والمبادئ البارزة لهذه الأسرة من الأساليب المعمارية.
العمارة التطورية
كان يعتقد في السابق أن عناصر الهندسة المعمارية "من الصعب جداً تغييرها بعد إنشائها". التغيير التدريجي هو المبدأ الرئيسي للعمارة التطورية. يجذب الانتباه العام على وجه التحديد لأنه كان من الصعب دائمًا توقع التغييرات في الهندسة المعمارية ومكلفة للغاية. إذا كانت إمكانية حدوث تغييرات تطورية مدمجة في البنية نفسها ، فإن تنفيذها يصبح أبسط وأرخص بكثير ، مما يساهم في التغييرات في تطوير البرمجيات وممارسات الإصدار ، بالإضافة إلى زيادة مستوى مرونة العملية الإجمالية.
تتوافق بنية Microservice تمامًا مع هذه الفكرة لأنها تحتوي على
سياقات محدودة مخصصة بشكل منطقي وفقًا للتصميم القائم على المجال من Eric Evans ويتم تنفيذها كمكونات منفصلة ماديًا. يتم تحقيق هذا الفصل من خلال تنفيذ ممارسات DevOps مثل توفير الآلة الافتراضية والاختبار والنشر التلقائي. نظرًا لأن كل خدمة يتم فصلها عن جميع الخدمات الأخرى (على المستوى الهيكلي) ، فإن استبدال إحدى الخدمات الصغيرة بأخرى أمر سهل مثل تبديل مكعبات ليغو.
ملامح العمارة التطورية
تتميز البنى التطورية بعدد من الخصائص المشتركة. سيتم وصف كل هذه الميزات في كتاب قادم عن العمارة التطورية. في هذه المقالة نعطي بعضها فقط.
النموذجية والاتصال
تمنح القدرة على مشاركة المكونات داخل حدود محددة جيدًا للمطورين ميزة التغيير المستمر إذا لزم الأمر. إذا لم يتم تصميم الهندسة المعمارية وكان النظام يبدو مثل كرة كبيرة من الطين (
بنية الكرة الكبيرة من الطين ) ، فإن التغييرات التطورية مستحيلة ، حيث لا توجد أجزاء مميزة في مثل هذا الهيكل.
[العلاقة بين الصفوف (النقاط المحيطة بالمحيط) في جزء كبير من التراب من مشروع عميل لم يذكر اسمه.]إن التوصيل البيني غير الصحيح للمكونات يعوق تطور النظام بسبب حقيقة أن إجراء التغييرات يمكن أن يؤثر بشكل غير متوقع على أجزاء أخرى من النظام. توفر جميع البنى التطورية مستوى معينًا من الوحدات النمطية ، عادة على مستوى الهندسة التقنية (على سبيل المثال ، الهندسة المعمارية الطبقية).
منظمة حول فرص الأعمال
تأثرًا بمبادئ التصميم الموجه نحو الموضوع في البنيات الحديثة الناجحة ، يتم استخدام الوحدات النمطية على مستوى المجال بشكل متزايد. تختلف البنية القائمة على الخدمة عن البنية التقليدية الموجهة نحو الخدمة (SOA) في المقام الأول في استراتيجية توزيع الخدمة. تنقسم البنية الموجهة نحو الخدمة بشكل صارم إلى مستويات فنية ، في حين يتم بناء الهياكل القائمة على الخدمة بشكل أساسي في أجزاء من مجال الموضوع المحدد بواسطة الخدمات الدقيقة.
التجارب
يعد إجراء التجارب أحد المزايا المهمة التي تمنحها العمارة التطورية للأعمال. توفر القدرة على إجراء تغييرات صغيرة بسهولة على التطبيقات استخدام ممارسات النشر المستمر الشائعة مثل اختبار أ / ب ، واختبار مجموعة محدودة من المستخدمين (إصدار كناري) وغيرهم. غالبًا ما يتم بناء بنى الخدمات الصغيرة على أساس مكالمات خدمة التوجيه ، مما يجعل من الممكن استخدام عدة إصدارات من الخدمة داخل نظام بيئي بأكمله. وهذا بدوره يفتح فرصًا كبيرة للتجربة والتغييرات في الوظائف الحالية. في نهاية المطاف ، عند تطوير تطبيقات الأعمال ، يتم قضاء وقت أقل في مناقشة الخطط والتراكم ، ويتم التطوير بشكل رئيسي في وضع اختبار الفرضيات السريعة.
مبادئ العمارة التطورية
يمكن الحصول على صورة أكثر اكتمالاً للعمارة التطورية من خلال التعرف على مبادئها الأساسية. تتعلق هذه المبادئ بالخصائص المختلفة لكل من العمارة نفسها وأساليب تصميمها. يتعلق جزء من المبادئ باختيار لحظة اتخاذ القرارات المعمارية في عملية تصميم النظام.
دالة اللياقة
من الضروري التمييز بين الناشئة (التي تكونت نتيجة لعملية التصميم) والعمارة التطورية - وهذا أمر مهم للغاية. مثل طرق الحساب التطوري (مثل الخوارزميات الجينية) ، تحدد وظيفة اللياقة المعمارية هدفًا في التصميم المعماري. بالنسبة لبعض الأنظمة ، فإن المتطلب الرئيسي هو وقت تشغيل طويل ، بالنسبة للأنظمة الأخرى ، أداء عالي أو أمان.
[يستخدم مخطط الرادار لإبراز وظائف اللياقة البدنية المهمة ذات الصلة بهذا النظام البرمجي.]
إذا حددت مسبقًا وظيفة اللياقة البدنية لنظام معين ، فسيساعد ذلك في المستقبل على اتخاذ القرارات الصحيحة في الوقت المناسب. بالنسبة للحلول المعمارية المختلفة ، يمكنك حساب وظائف اللياقة البدنية ، وإذا أصبحت قيمتها أفضل ، فهذا يعني أن العمارة تتطور في الاتجاه الصحيح.
الانتباه إلى نقاط الألم
تستند العديد من أساليب العمل المستخدمة في الإمداد المستمر للبرمجيات وتطوير بنية متطورة إلى مبدأ "الانتباه إلى نقاط الألم" التي صاغها مجتمع البرمجة الإلكترونية. عندما تظهر لحظات في أعمال التصميم التي يمكن أن تصبح مصادر للمشاكل (نقاط الألم) ، فمن الضروري الانتباه إليها في أقرب وقت ممكن. سيساعد ذلك على تحديد المشاكل المحتملة مسبقًا وإزالتها في نظام عمل. ممارسات التسليم المستمر الشائعة ، مثل خط أنابيب النشر ، والتوفير التلقائي للأجهزة الافتراضية ، وترحيل قاعدة البيانات ، عند تصميم بنية تطورية ، تبسط إلى حد كبير إزالة نقاط الألم أثناء مرحلة التغيير.
نقطة القرار
الفرق الرئيسي بين العمارة التقليدية والتطورية هو عندما يتم اتخاذ قرارات مهمة. قد تتعلق هذه القرارات ببنية التطبيق أو مجموعة التكنولوجيا أو الأدوات الفردية أو أنماط الاتصال. في حالة تصميم بنية تقليدية ، يتم اتخاذ مثل هذه القرارات في المرحلة الأولية ، قبل كتابة الرمز. في عملية تطوير العمارة التطورية ، يتم اتخاذ أي قرارات في وقت متأخر قدر الإمكان ، في اللحظة الأخيرة ، عندما تكون مقبولة. وتتمثل ميزة اتخاذ القرار في وقت لاحق في أنه قد تتوفر معلومات إضافية في هذه المرحلة. تشمل تكاليف هذه الطريقة تكاليف التحسين المحتمل للهندسة المعمارية بعد اتخاذ القرار. يمكن تقليل هذه التكاليف باستخدام الملخصات المناسبة ، ولكن لا يزال من الممكن حدوثها. ومع ذلك ، فإن تكاليف اتخاذ القرارات في المرحلة الأولية حقيقية للغاية. خذ ، على سبيل المثال ، قرار اختيار أداة المراسلة. أدوات مختلفة تدعم وظائف مختلفة. إذا اخترنا أداة أكثر قوة من الضرورة ، نحصل على بنية خاطئة التصور تتطلب حتمًا مزيدًا من التطوير. هذا "الدين التقني" ، الناتج عن اختيار الأداة الخاطئة ، سيكون عبئًا إضافيًا على المطورين.
بطبيعة الحال ، فإن المشكلة الرئيسية في آخر لحظة ممكنة لاتخاذ القرار هي تحديد متى يأتي. للقيام بذلك ، ركز على وظيفة اللياقة البدنية. بادئ ذي بدء ، من الضروري اتخاذ قرارات يمكن أن يكون لها تأثير كبير على اختيار الهندسة المعمارية أو عناصر التصميم ، وكذلك القرارات التي تؤثر بشكل كبير على النجاح العام للمشروع. غالبًا ما يفوق الأثر السلبي لتأخير مثل هذا القرار الفوائد المحتملة لقرار لاحق.
الخلاصة
يجب على مهندسي البرمجيات شرح القرارات المتخذة بشأن تصميم الأنظمة الجاري تطويرها ، كقاعدة ، باستخدام أنواع مختلفة من الرسوم البيانية. غالبًا ما يقع مطورو الهندسة المعمارية في فخ تقديم هندسة البرمجيات كمعادلة يحتاجون إلى حلها. تتيح لك العديد من الأدوات التجارية التي يقدمها مهندسو البرامج وصف البنية بشكل رسمي في شكل مربعات وخطوط وسهام. على الرغم من أن هذه الرسوم البيانية قد تكون مفيدة ، إلا أنها تقدم عرضًا ثنائي الأبعاد فقط ، لقطة للعالم المثالي ، لكننا نعيش في واقع رباعي الأبعاد.
لملء مثل هذا المخطط ثنائي الأبعاد بالحياة ، من الضروري تحديده. تصبح تسمية
ORM في رسم تخطيطي ثنائي الأبعاد هي
السبات v4.2.17 ، مما يجعل العالم
موضع تساؤل ثلاثي الأبعاد. عندما يكون لديك خطة لتطبيقها في الإنتاج والتحديثات بعد ستة أشهر من الإصدار الحتمي من
Hibernate v4.3.0.1 ، ستكون جاهزًا للعالم رباعي الأبعاد. لا يدرك العديد من المهندسين المعماريين أن النظرة الثابتة للعمارة لها عمر قصير. إن عالم البرامج موجود في حالة تيار ؛ فهو ديناميكي وليس ثابتًا. العمارة ليست معادلة ، بل لقطة من عملية مستمرة.
أظهرت ممارسات التسليم المستمر للبرامج و DevOps مشاكل تتزايد بسبب عدم فهم الجهود المطلوبة لتنفيذ ودعم الهيكل. تنفيذ الهندسة هو الخطوة الأولى فقط.
تبقى العمارة مجرد تجريد حتى يتم تفعيلها. بمعنى آخر ، لا يمكن الحكم على صلاحية أي بنية على المدى الطويل إلا عندما تقوم بتنفيذها ، ولكن أيضًا تعديلها مرة واحدة على الأقل. وربما تمكنوا من التعامل مع المفاجآت على طول الطريق.
إن فهم مهندس البرمجيات للقدرات التشغيلية أمر بالغ الأهمية لتطوير بنية تطورية. يؤثر التطور التطوري للهندسة المعمارية على ميزات تنفيذه ، وبالتالي يجب أن تؤخذ في الاعتبار في عملية الإنجاز. تهدف متطلبات عملية التسليم المستمر للهندسة المعمارية إلى تحسين التصور وتبسيط التغييرات. بهذه الطريقة ، يعزز التسليم المستمر قدرات العمارة التطورية.
في 19 نوفمبر ، وصل نيل فورد إلى موسكو مع فصل دراسي
عن إنشاء هندسة برمجيات تطورية .