منذ أكثر من عام حتى الآن ، في MyStore ، نقوم بإنشاء وظائف تساعد مستخدمينا على شراء وبيع السلع ذات العلامات التجارية. لقد تراجعت أخبار الملصقات عدة مرات على Habré ، لفترة وجيزة: منذ عام 2019 ، تم وضع علامة على البضائع بالضرورة. ليس كل ذلك في وقت واحد ، ولكن الآن تحتاج إلى تسمية السجائر والأحذية والعطور وإطارات السيارات. في الوقت نفسه ، نحن نعمل في حالة من عدم اليقين عندما تتغير API للأنظمة الحكومية باستمرار.
لذلك ، لدينا طريقتان فقط للتكامل مع الوكالات الحكومية: الانتظار حتى يستقر كل شيء ويفتقد قيادة السوق أو تطوير نظام في عالم من المتطلبات المتغيرة.
اخترنا الثانية - فقط بروح المنهجيات المرنة. أعتقد أن Agile يمكن أن تساعد حقًا في حل المشكلات التطبيقية. والحياة في عالم من المتطلبات المتغيرة باستمرار هي المجال الذي يمكنك فيه الدوران.
اسمي مكسيم سوخارينكو ، أنا قائد فريق منصة خدمة MySklad. واليوم سوف أخبرك كيف نعمل مع المتطلبات المتغيرة.
من الكلاسيكية إلى سكروم
تم تحديد الموعد النهائي الأولي لتطوير النظام من قبل السلطات التنظيمية في أبريل 2019 ، لكنك تفهم كل شيء. نتيجة لذلك ، تم نقل المواعيد النهائية إلى أكتوبر. وحيث توجد مواعيد نهائية جديدة ، هناك متطلبات وتنسيقات جديدة. لم نتمكن من الانتظار حتى يتم إصلاح واجهة برمجة التطبيقات - فلن يكون لدينا وقت لتنفيذ التكامل. لذلك ، قرروا "تتردد في خط الحزب".
فكرنا في الطريقة الكلاسيكية التي تقدم لنا لعمل محول لنظام خارجي. قم بتزويده بقابس بمفتاح ومن وقت لآخر ، قم بسحب وظيفة القابس والمحول إلى الحالة الحالية للنظام الخارجي.
يشير المنطق إلى أنه من أجل تطوير نظام بواجهة متغيرة باستمرار ، تحتاج إلى إصلاح المتطلبات في وقت ما. لكن فقط على ماذا؟ حتى نطور بعض جزء من وظائف؟
يجب أن تعترف أنه من غير السار أن تترك وظيفة غير مكتملة لا تمر عليها الاختبارات ، وأن تبدأ أيضًا في كسرها على واحدة جديدة. يمكنك إصلاح متطلبات فترة تطوير الميزة. ولكن ماذا تفعل مع الميزات الكبيرة التي يمكن أن تعيش في التنمية لعدة أشهر؟ من المستحيل ببساطة إصلاح متطلبات هذه الفترة الطويلة.
لذلك تحولنا إلى سكروم. يخبرنا أنه بحلول نهاية السباق ، يجب أن نوفر منتجًا جديدًا بوظيفة جديدة. لكن كيف يتصارع هذا مع متطلبات التثبيت والميزات الكبيرة؟ هناك نكتة جيدة حول هذا الموضوع:
"يا دكتور ، عندما أفعل مثل هذا ، يؤلمني".
"أنت فقط لا تفعل ذلك من هذا القبيل."
الذي لا يفهم ، لا تجعل ميزات كبيرة . يمكنك إصلاح المتطلبات لمدة أسبوع أو أسبوعين لتتوافق مع العدو ، وتعيين تنفيذ الوظيفية وفقًا لمتطلبات العدو. ويجب ضرب الوظيفة في مثل هذه القطع بحيث تنسجم مع واحد أو اثنين من سباقات السرعة. اعتقد صعبة للغاية؟ وبعد ذلك! أنت فقط لا تعرف كيفية خفض التذاكر. المنشار ، الشورى ، المنشار ، هم ذهبيون.
بالطبع ، هذا ليس بهذه البساطة ، نحن بحاجة إلى التحرك نحو هذا الهدف - من أجل ترك التطوير من "سنقوم بذلك لمدة ستة أشهر ، ثم سنطرح نسخة جديدة للاختبار".
السر هو الحصول على نسخة مستقرة في نهاية كل سباق . بالطبع ، قد يبدو أن هذا سيزيد من وقت التطوير بسبب نمو التكاليف العامة لتحقيق الاستقرار في الفرع وأن التطوير سيكون دون المستوى الأمثل. لكن الموقف هنا هو نفسه تقريبا كما هو الحال مع الاختبارات ، دعنا نتحدث عن ذلك أدناه.
لمكافحة المهام
والآن لمواقف حقيقية. كانت مهمتنا هي تكوين التشفير بين نظامنا وواجهة برمجة التطبيقات بحيث يقوم المستخدم بتوقيع جميع الطلبات باستخدام مفتاح. أعتقد أن العديد منكم قد صادف CryptoPro ، لذلك كان علينا القيام بذلك.
إذا كنت تستخدم النهج القياسي ، سيتم تشكيل مهمة معزولة واحدة - إعداد تشفير للخدمة. سنعلقها على شخص واحد ولمدة شهر سنقوم بإزالة الحالة والاستياء من سبب عدم انتهائها بأي شكل من الأشكال. وسوف يتحول المطور تدريجياً إلى مخلوق بري من العالم الآخر ، مع وجود رغوة في الفم وعينين برية.
نحن نقطعها إلى مهام صغيرة ومتناثرة في جميع أنحاء الفريق. أقارن التشفير مع الكحول: في الشركة وفي جرعة معتدلة ، إنه أفضل بكثير من الكثير وحده.
نظرًا لأننا نعمل على تطوير خدمة سحابية ، فقد كان من الأسهل بالنسبة لنا استخدام المكون الإضافي CryptoPro EDS Browser (هذا ليس إعلانًا ، هذا هو اليأس). يسمح CryptoPro CSP بتوسيع المفاتيح وطرق التشفير إلى صفحة ويب.
أولاً ، يختار المستخدم المفتاح الذي سيستخدمه في العمل مع الخدمة ، ثم تتم المصادقة للحصول على رمز مميز. وعندها فقط بمساعدة التشفير ومكالمات API الرمزية. يبدو أن كل شيء بسيط (لا).
بادئ ذي بدء ، لقد فعلنا MVP بمعزل عن خدمتنا - لتكوين تفاعل المكون الإضافي مع API. هل تعرف مقدار الوثائق الموجودة حول المكون الإضافي لمتصفح cryptoPro من الشركة المصنعة؟ لا على الاطلاق! عكس الأمثلة الهندسية فقط ، المتشددين فقط. ليال بلا نوم ومحاولات لتحديد تأثير هذه المعلمات أو غيرها.
وعندها فقط تمكنا من محاولة بنائه في نظامنا البيئي. يقوم شخص واحد بإضفاء مظهر مكون النموذج الأولي في نموذج إنساني ، والثاني يربطه بمنطق العمل ، بينما يكتب الثالث تعليمات للأجيال القادمة لتكوينه. كل مهمة لها هدف محدد وهي معزولة نسبيا عن المهام الأخرى. والناس لديهم شيء للمناقشة ومع من يشارك الألم.
وبالتالي فإن الوضع أصبح مستقرا تماما. في تكرارات صغيرة ، نضيف وظائف جديدة ، من وقت لآخر نقوم بتحديث الواجهة الخارجية ونشر التغييرات في عمق نظامنا. ولكن السؤال الذي يطرح نفسه: العيش في فرع منفصل حتى آخر ، أو محاولة للحفاظ على الميزات الصغيرة باستمرار في السيد؟
وظيفة الاختبار
أقترح معرفة ما يجب القيام به مع الاختبار وماذا أفعل إذا أضفنا التكامل إلى مشروع مباشر.
لنبدأ مع الاختبار. بادئ ذي بدء ، سوف نحدد ما يمكن أن نسميه وظيفة اختبار. أقترح تسمية الوظيفية التي اجتازت اختبارات القبول ، بما في ذلك اختبارات الانحدار. سنتفق فقط على أننا لن نلجأ إلى اختراق الحياة "لا توجد اختبارات - وهذا يعني أن كل شيء تم اختباره". نحن بحاجة إلى الحفاظ على الكود الخاص بنا في المنتج ، وكلما زادت تغطية الاختبار ، كان ذلك أفضل. كلما زادت النسبة المئوية لأتمتة مثل هذه الاختبارات ، كلما كان كل تكرار لاختبار الوظيفة أقل ، وكلما كان ذلك ممكنًا.
لدينا مجموعة معينة من اختبارات القبول والانحدار ، بعضها آلي ، وبعضها يتم باليد.
إذا اقتربنا رسميًا ، فيجب إجراء الاختبار بعد تغيير كل رمز. على سبيل المثال ، قاموا بتقسيم الميزة إلى ستة تذاكر وخلال عملية الاختبار وجدت عشرة أخطاء. ودع كل اختبار يستغرق أربع ساعات: لا يتم الاعتماد تلقائيًا ، ولكن لا يستغرق الإعداد اليدوي سوى أربع ساعات. اتضح أنه مع طريقة العمل الأساسية والرسمية ، سنقضي 64 ساعة.
الآن دعونا نحاول اختبار ليس بعد كل رمز التغيير ، ولكن بعد واحد. يشير المنطق إلى أننا نقضي 32 ساعة فقط. وإذا قمت بإجراء الاختبار فقط بعد تطوير الوظيفة وبعد إصلاح جميع العيوب. ولكن هذا شريطة أن تكون جميع العيوب معزولة عن بعضها البعض ، وهو ما لا يحدث في الحياة.
في الحياة ، اتضح أنه بعد تطوير الوظيفة ، يتم إجراء الاختبار ويتم تنفيذ الموجة الأولى من الأخطاء. ثم يتم إصلاح الخلل ، وظيفة مكسورة ، يتم اختبارها من قبل علة علة. يقومون بإجراء اختبار عالمي ثانٍ ، وتظهر موجة جديدة من الأخطاء. تم إخفاء هذه الأخطاء وظهرت عند تصحيح الموجة الأولى وتغيير الوظيفة. و عدة مرات.
عادةً ما تحصل على ثلاث إلى خمس دورات كاملة من الاختبارات - اعتمادًا على درجة تعقيد الوظيفة ودرجة توجيه اليدين. ولكن يمكن تسريع العملية أكثر - إذا تغلبت على الميزات الصغيرة.
على سبيل المثال ، إذا قسمت إحدى الميزات مع الاختبار في أربع ساعات إلى ساعتين مع الاختبار في ثلاث ساعات ونصف الساعة ، فستحصل على خمس ساعات بدلاً من أربع ساعات. يبدو أنه لا يوجد ربح. لكنه يتجلى في انخفاض في تعقيد الوظائف التي تم إصدارها وانخفاض في احتمال وجود سلاسل من العيوب ذات الصلة. نتيجة لذلك ، تصبح التكرار للاختبار الكامل أقل.
أضف إلى المشروع
سنقوم الآن بتحليل الموقف عند إنشاء ميزة في مشروع ما زال المطورين يعملون عليه. لنفترض أننا نستخدم مفهوم فرع لكل ميزة (فرع لكل تذكرة) المعياري نسبياً في الكود المصدري.
من الواضح أن مقدار تكلفة الحفاظ على أهمية الغداء المتأخر يتناسب مع حياته. كلما قلت تقاطعات الرموز في التذاكر الحالية ، قلت المشاكل عند الاندماج. هذا يعتمد بشكل غير مباشر على العمر: كلما مر الوقت ، كلما زادت فرص ظهور التذاكر ذات الصلة. وفقًا لذلك ، كلما كان أقل وقتًا في الحياة ، قل الجهد الذي نبذله على أهميته.
يبقى لفهم كيفية طرح وظيفة وظيفية جزئيا على همز. الجواب بسيط للغاية: يجب ألا يكون في متناول المستخدم. إذا كنت تريد أن تسأل عن سبب قيامك بذلك ، يمكنك إرجاع بضع فقرات أعلاه.
يبدو أن الاحتفاظ بالكود الميت في المعالج ليس جيدًا جدًا. هذا صحيح ، لكنه لم يمت. يمكنك إنشاء صفحة سرية تحتوي على أقلام تشمل هذه الوظيفة. أو سلسلة من الإجراءات الخاصة ، والتي ، مثل بيض عيد الفصح في الألعاب ، سوف تجلب لك هذه الوظيفة. بالإضافة إلى ذلك ، يمكنك اختباره على الفور.
بالطبع ، هناك طرق أخرى للتعامل مع تقلب المتطلبات. وهذا النهج له حدود وشروط الاستخدام. كما تعلمون ، لا يوجد حتى الآن رصاصة فضية.