من خلال الاطلاع على مقالات حول تصميم البرمجيات ، قابلت دائمًا سحابة من الاختصارات غير المسبوقة وممارسات التطوير المذكورة بشكل عرضي.

• TDD - حسنًا ، يعلم الجميع ذلك أولاً نكتب الاختبارات ، ثم بقية الكود.
• BDD شيء مألوف ، نوعا ما مثل الاختبارات ، ولكن اختبارات خاصة.
• TDD - مرة أخرى؟ لذا توقف ، هنا لا يتعلق بالاختبارات على الإطلاق. ولكن لماذا يطلق عليه نفس الشيء؟
• DDD - السياقات المنضمة ، اللغة في كل مكان ، المجال ...
• FDD - نعم ، كم هو ممكن؟
• MDD - على محمل الجد ، الرسم البياني؟
• PDD - ...

تنقسم مناهج التطوير حسب التعقيد ومجالات التطبيق والأهداف.
أعتقد أن الوقت قد حان لمعرفة سبب الحاجة إليها ، ولماذا يوجد الكثير منها ، وكيف يمكن أن تكون مفيدة لنا.

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

TDD - اختبار يحركها التنمية

TDD هي منهجية لتطوير البرامج تعتمد على تكرار دورات التطوير القصيرة: في البداية يتم كتابة اختبار يغطي التغيير المطلوب ، ثم يتم كتابة رمز البرنامج الذي ينفذ سلوك النظام المرغوب ويسمح لك باجتياز الاختبار المكتوب. ثم يتم إعادة تشكيل الكود المكتوب من خلال الاختبارات المستمرة للاختبارات.

يبدو بسيطا وواضحا. كثيرون على دراية بهذا النهج في التنمية ، وحتى العم بوب نفسه يروج له بنشاط.

يعتبر TDD شكلاً من أشكال البناء المناسب للتطبيق. تتمثل فلسفة التطوير التي تعتمد على الاختبار في أن اختباراتك تعد بمثابة تحديد لكيفية تصرف برنامجك. إذا كنت تعتبر مجموعة الاختبار الخاصة بك جزءًا إلزاميًا من عملية الإنشاء ، وإذا فشلت اختباراتك ، فلن يتم إنشاء البرنامج لأنه غير صحيح. بطبيعة الحال ، فإن القيد هو أن صحة البرنامج الخاص بك محددة فقط على أنها اكتمال الاختبارات الخاصة بك. ومع ذلك ، فقد أظهرت الدراسات أن التطوير على أساس الاختبار يمكن أن يقلل من الأخطاء بنسبة 40-80 ٪ في الإنتاج.

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

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

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

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

يمكنك معرفة المزيد حول مبادئ TDD من خلال قراءة كتاب Kent Beck's Extreme Programming. Development من خلال الاختبار.

TDD - نوع التنمية مدفوعة

يتم اختصار "التطوير المدفوع بالنوع" بالإضافة إلى التطوير من خلال الاختبار ، لذلك عادةً ما يتم كتابة الاسم الكامل.

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

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

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

من السلبيات ، فقط التعقيد المتزايد للغات مع الكتابة الديناميكية. على سبيل المثال ، بالنسبة إلى JavaScript ، فإن هذا النهج أصعب من تطبيق TypeScript.

على habr هناك مقال ممتاز حول الكتابة.

BDD - التنمية مدفوعة السلوك

نظرًا لبعض أوجه التشابه المنهجية ، غالبًا ما يتم الخلط بين TDD (التطوير المدفوع بالاختبارات) و BDD (التنمية المدفوعة بالسلوك) حتى من قبل المتخصصين. ما هو الفرق؟ تتشابه مفاهيم كلا النهجين ، ويتم إجراء الاختبارات الأولى وبعد ذلك فقط يبدأ التطوير ، ولكن الغرض منه مختلف تمامًا. تدور TDD حول البرمجة والاختبار على مستوى التنفيذ التقني للمنتج ، عندما يتم إنشاء الاختبارات بواسطة المطورين أنفسهم. يتضمن BDD اختبارًا أو محللًا يصف البرامج النصية المعرفة من قبل المستخدم بلغة طبيعية - إذا جاز لي القول ، بلغة العمل.

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

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

تتم كتابة النصوص النصي في شكل معين.

بعد (تقريبًا - معطى) بعض السياق ،

عندما (لاحظ متى) حدث ما ،

ثم (تقريبا. ثم) تحقق من النتيجة.

قد يحدث شيء مثل هذا:

أو مثال آخر باللغة الروسية:

السيناريو 1: هناك أموال في الحساب +

الحصول على حساب مع المال

وبطاقة صالحة

وأجهزة الصراف الآلي مع النقدية

عندما يطلب العميل النقدية

ثم تأكد من أن الحساب مدين

وتأكد من إصدار النقد

وتأكد من إعادة البطاقة

أتاح لنا نهج BDD ، إلى جانب الممارسات الهندسية ، التخلي عن الوثائق القديمة التي تحتوي على معلومات غير ذات صلة ، وتلقي وثائق جديدة على الطاير ، وتخزينها مع المشروع ، مما جعل المحللين والمختبرين أقرب إلى الشفرة.

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

ما هي ميزة BDD؟

• اختبارات قابلة للقراءة لغير المبرمجين.
• فهي سهلة التغيير. وغالبًا ما يتم كتابتها بلغة إنجليزية صافية تقريبًا
• يمكن كتابتها بواسطة مالك المنتج أو الأطراف المعنية الأخرى.
• نتائج الاختبار أكثر إنسانية.
• الاختبارات مستقلة عن لغة البرمجة المستهدفة. الهجرة إلى لغة أخرى مبسطة إلى حد كبير.

سلبيات:

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

قد يكون المخرج من هذا الموقف هو اختيار إطار عمل BDD مناسب وعمليات تطوير مبنية بشكل صحيح.

اقرأ المزيد عن BDD هنا .

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

DDD - تصميم المجال مدفوعة

التصميم الموجه نحو الموضوع ليس تقنية أو منهجية محددة. DDD هي مجموعة من القواعد التي تسمح لك باتخاذ قرارات التصميم الصحيحة. يمكن لهذا النهج تسريع عملية تصميم البرامج بشكل كبير في مجال غير مألوف.

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

يعد نهج DDD مفيدًا بشكل خاص في الحالات التي لا يكون فيها المطور متخصصًا في مجال المنتج المطور. على سبيل المثال: لا يمكن للمبرمج معرفة جميع المناطق التي يُطلب منها إنشاء برامج ، ولكن بمساعدة التمثيل الصحيح للهيكل ، من خلال نهج موجه نحو الموضوع ، يمكنه بسهولة تصميم تطبيق يستند إلى النقاط الرئيسية ومعرفة مساحة العمل.

أحاول في هذه المقالة أن أنقل جوهر كل مقاربة لتطوير البرمجيات ، لكن بخصوص DDD يمكنك كتابة أكثر من مقال واحد وتغطية جميع الفروق الدقيقة في عدة فقرات ، لن ينجح الأمر بالنسبة لي. لذلك ، عند التوضيح ، سأقدم روابط توضيحية لأكثر المصادر جدارة.

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

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

المفهوم التالي هو "نموذج المجال". هذا النموذج هو مسرد للمصطلحات من اللغة في كل مكان. يقتصر كل من طراز المجال واللغة في كل مكان على السياق الذي يسميه التصميم الذي يحركه النطاق السياق المحيط به. إنه يقيد نموذج المجال بطريقة تجعل كل المفاهيم الموجودة فيه غير واضحة ، والجميع يفهم ما هو على المحك.

مثال: خذ الكيان "الشخص" ووضعه في سياق "التحدث أمام الجمهور". في هذا السياق ، وفقًا لـ DDD ، يصبح متحدثًا أو متحدثًا. وفي سياق "الأسرة" - الزوج أو الأخ.

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

إذا كنت تستخدم لغة المشروع في التعبير "تمت إضافة المنتج" ، فإن الخيار التالي ليس DDD:

فار منتج = منتج جديد ('تفاحة')

product.save ()

لماذا؟ يقول الرمز أننا أنشأنا المنتج بطريقة غريبة وحفظناه. كيفية إضافة منتج كل نفس؟ تحتاج لإضافته . هنا هو رمز DDD:

المنتج :: add ('apple')؛

العمارة:

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

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

هناك أيضًا مقالات حول DDD أوصي بشدة بقراءتها بعناية - هنا وهنا .

ماذا يعطينا هذا في النهاية:

• يمكن لجميع أعضاء الفريق تقريبًا قراءة رمز المشروع ؛
• بيان المهام يصبح أكثر وضوحا ؛
• الأخطاء في منطق الأعمال أصبحت أسهل للبحث عنها ؛
• من الأسهل على اختصاصيي ضمان الجودة فحص الرمز والبحث عن الأخطاء المنطقية والأخطاء.

سلبيات:

• مطلوب مطورين مؤهلين تأهيلا عاليا ، وخاصة في بداية المشروع ؛
• ليس كل العملاء على استعداد لدفع مثل هذه التكاليف ، يحتاج DDD إلى دراستها من قبل جميع المشاركين في عملية التطوير.

FDD - ميزات مدفوعة التنمية

FDD - تم تطوير هذه المنهجية (يشار إليها باختصار باسم FDD) بواسطة Jeff De Luca والمعلم المعترف به في مجال التقنيات الموجهة للكائنات ، Peter Coad. FDD هي محاولة للجمع بين أكثر التقنيات المعروفة في صناعة تطوير البرمجيات والتي تأخذ أساسًا الوظائف (الخصائص) المهمة للبرنامج المطور للعميل. الهدف الرئيسي من هذه المنهجية هو تطوير برامج حقيقية تعمل بشكل منتظم في الوقت المحدد.

مثل المنهجيات التكيفية الأخرى ، فإنه يركز على التكرارات القصيرة ، كل منها يعمل على إيجاد جزء معين من وظائف النظام. وفقا لقوات الدفاع عن الديمقراطية ، واحد التكرار يستمر أسبوعين. FDD لديه خمس عمليات. تتعلق الثلاثة الأولى ببداية المشروع:

• تطوير نموذج مشترك ؛
• تجميع قائمة بخصائص النظام المطلوبة ؛
• التخطيط للعمل على كل الممتلكات ؛
• تصميم كل الممتلكات ؛
• بناء كل الممتلكات.

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

دعونا نتناول كل عنصر بمزيد من التفاصيل.

تطوير نموذج مشترك.

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

قائمة الميزات

يتم استخدام المعلومات التي تم جمعها أثناء بناء النموذج العام لتجميع قائمة من الوظائف. يتم دمج الوظائف في ما يسمى "المجالات" (المجال الإنجليزي) ، وهي بدورها تنقسم إلى مناطق فرعية (مجالات مواضيع إنجليزية) وفقًا لسمة وظيفية.

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

خطة خصائص (وظائف)

المرحلة التالية هي توزيع الوظائف بين أبرز المبرمجين أو الفرق.

ميزة التصميم

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

تنفيذ وظيفة

نكتب الرمز ، وإزالة الرهانات ، اختبار.

بعد اختبار الخاصية ودخولها في المنتج ، نأخذ خاصية الأولوية التالية ، ونكرر دورة التصميم / التنفيذ.

المجموع ، نتيجة لذلك ، حصلنا على:

• وثائق خصائص النظام ؛
• تصميم دقيق.
• أسهل لتقييم المهام الصغيرة ؛
• تركز الاختبارات على مهام العمل ؛
• عملية إنشاء المنتجات المتطورة.
• تتيح لك دورات التطوير التكراري القصيرة زيادة الوظائف بسرعة وتقليل الأخطاء.

سلبيات:

• FDD هو أكثر ملاءمة للمشاريع الكبيرة. لن تتمكن فرق التطوير الصغيرة من تجربة كل فوائد هذا النهج ؛
• تكاليف التنفيذ والتدريب كبيرة.

MDD - نموذج التنمية المدفوعة

في الآونة الأخيرة ، تم إيلاء الكثير من الاهتمام في المنشورات لموضوع الهندسة المعمارية والتنمية على أساس نماذج MDA (نموذج الهندسة المعمارية) و MDD (نموذج التنمية المدفوعة). دون الخوض في التفاصيل ، فإننا نسلط الضوء على النقاط الرئيسية فقط.

التطوير المدفوع بالنماذج هو نمط من تطوير البرمجيات حيث تصبح النماذج من أدوات التطوير الرئيسية التي تنشأ منها الشفرات والتحف الأخرى.

ببساطة ، الهدف الأساسي من التطوير هو بناء المخططات اللازمة ، والتي من خلالها نقوم بإنشاء كود العمل للمشروع.

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

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

«», . ( ).

MDD ‑ . , , . MDD-, . Unified Modeling Language – UML 2.0.

Object Management Group (OMG) :

• c , ;
• - ;
• , .

MDD, , — . .

:

• (Minimum Viable Product) ;
• : , , ;
• ;
• .

:

• MMD , Rational Software Architect, Simulink Sirius;
• ;
• .

PDD — Panic Driven Development

agile , PDD. , .

.

, , . . , ? , .

, , .

. . UX . ? , . , .

.

, , , . , . . , .

.

— . . . . . .

.

, , , — , . . , , , .

, .

, . . , , .

:

• ;
• ;
• , - .

:

• .

PDD , , , .

استنتاج

agile . , , .

- Driven Development , DDD, BDD, MDD , .