سؤال

أنا أبدأ أطروحتي للدراسات العليا وسيكون الموضوع "الهندسة المعمارية الرشيقة"

في الأساس، سيبدأ بوصف منهجيات تطوير البرمجيات التقليدية، والولادة اللاحقة لمنهجيات رشيقة، وينتهي بالتوصيات وتصميم بنية تطبيقات مرنة قابلة للتكيف بسهولة مع التغييرات الكامنة في بناء البرمجيات.

سؤالي هو، ما هي الأنماط وممارسات التصميم التي توصي بها لمثل هذه الهندسة المعمارية؟أنا مهتم بالأنماط التي تسمح بتعظيم فصل الفصل مثل حقن التبعية، وقابلية الصيانة العالية، والحد الأقصى من التجريد من مشكلة محددة.

هل كانت مفيدة؟

المحلول

أوصي بما يلي:

  1. نمط المستودع
  2. نمط المواصفات
  3. حقن التبعية
  4. تصميم يحركه المجال

في الأساس كل ما يدعو إليه جمهور ALT.NET.

نصائح أخرى

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

نوع من ردود الفعل حول عملية التطوير الخاصة بك - سواء كانت اختبارات الوحدة أو التكامل المستمر و/أو اجتماعات "سكرم".أدرك أن هذا لا يندرج حقًا في نطاق "البنى المعمارية" الرشيقة، ولكن إذا لم يكن لديك عملية رشيقة، فلن تكون هناك أهمية لأي درجة من الهندسة المعمارية "الموجهة نحو الرشاقة".

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

وهذا ما يشير إليه المبرمجون العمليون باسم "الرصاصات التتبعية"، ويطلق عليه أليستير كوكبيرن "هيكل عظمي يمشي".

هل يمكنك أيضًا تحديد ما هو التطبيق في سياق أطروحتك؟هل تعتبر فقط تطبيق البرمجيات أو هل تتعامل أيضًا مع أنظمة أكثر تعقيدًا؟

إنه سؤال مثير للاهتمام، هذا.هل يمكن إنشاء بنية رشيقة بمعزل عن غيرها؟إذا كنا ننظر إلى شيء مثل XP فأنا متشكك بعض الشيء.أو ربما أسأت الفهم، لكن هذا لم يمنعني من التوسع...

في XP، لنتبع نهجًا أعرف المزيد عنه، سيكون لدينا نوع من البنية خلال فترة زمنية قصيرة جدًا بعد أن نبدأ المشروع؛في الواقع، في الوقت الذي اكتملت فيه القصة الأولى.أثناء كتابة القصة الأولية، سنكون قد بدأنا في الحصول على فكرة عما يمكن أن نبنيه - إنه أمر لا مفر منه:يميل المبرمجون إلى التفكير فيما يتعلق بالكود.لكن التفكير في المستقبل البعيد يأخذنا إلى هذا الحد ياجني إِقلِيم.

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

لذا ربما يكون السؤال هو تقييم ما إذا كانت هناك خصائص معينة - أو فئات من الخصائص - التي تطورت البنيات نتيجة لعملية رشيقة تميل إلى عرضها.وبعد ذلك أعتقد أن الأمر سيعتمد على نوع التطبيق الذي نبنيه، على الرغم من أن بعض المبادئ المذكورة بالفعل (والتي أفهم بعضها) يجب أن تكون محتملة.

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

يمكن استخدام جميع أنماط البرامج المذكورة هنا باستخدام عملية شلالية قوية تعتبر لعنة على التطوير الرشيق.

أن تكون رشيقًا يعني أنك تتقبل التغيير، أي أنك تتبنى التغيير.اعتماد التغيير في المتطلبات وقرارات التصميم وقبول إعادة البناء وما إلى ذلك.العديد من الأشياء بالطريقة "التقليدية" قد تستهجنها، لأنك تلمس شيئًا ناجحًا/متفق عليه مسبقًا.

في أساليب مثل XP يحاول الحفاظ على الجودة العالية عن طريق كتابة اختبارات الوحدة.لنتظاهر بأننا جميعًا متفقون على كتابة اختبارات الوحدة.

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

إذا كان لدى روبرت مارتن أي شيء ليقوله حول هذا الموضوع (وقد أطلق على بيان Agile الأصلي اجتماع IIRC)، فمن المؤكد أن الهندسة المعمارية لها كل ما يتعلق بـ Agile.الجزء الأول من كتابه كاملاً تطوير البرمجيات الرشيقة والمبادئ والأنماط والممارسات هو حول صلب المبادئ المعمارية.لقد كان هذا مثيرًا للجدل إلى حد ما في بعض الأوساط ولكني لا أفهم السبب.إذا كانت قاعدة التعليمات البرمجية الخاصة بك هشة ومقترنة بشكل كبير، فلا يمكن أن تكون مفتوحة جدًا للتغيير، وهي السمة المميزة لخفة الحركة.يعد فصل العملية من الناحية النظرية عن ممارسة التعليمات البرمجية أمرًا غير مرن للغاية.

المبدأ 1 من البيان:"نحن نقدر الأفراد والتفاعلات أكثر من العمليات والأدوات."

إن تعريف "عملية" Agile باعتبارها تجريدًا منفصلاً عن بنية قاعدة التعليمات البرمجية بالنسبة لي ينتهك روح هذا المبدأ الأول.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top