من المؤكد أنكم جميعًا في مراحل مختلفة من حياتهم المهنية قد واجهتم مثل هذه المشكلة: لقد رأيت المهمة ، ويبدو أنها بسيطة والمتطلبات واضحة ، ثم تبين أنك بحاجة إلى تنفيذها بشكل مختلف. تم إنفاق الوقت على التنفيذ ، والموعد النهائي قد بدأ بالفعل ، والمهمة ليست جاهزة في الواقع. علينا إعادة الكتابة بسرعة ، ربما في انتهاك للموعد النهائي. تُهدر ساعات العمل ، وتكلف المال ، وإذا لم تكن هذه المشكلة لمطور واحد ، ولكن للشركة بأكملها ، فإن مجموعة من المهام المتأخرة تنمو ، وتزداد تكلفة التطوير ، ولا يمكن للشركة تنفيذ الاستراتيجية ، وتعاني الشركة من خسائر.
ما المشكلة؟
تنشأ مثل هذه المشكلة بسبب عدم كفاية الانغماس في المهمة. يمكن أن يكون هناك العديد من الأسباب ، وهنا بعض منها
- عدم وجود وثائق حديثة ؛
- سوء فهم العملية التجارية ؛
- وضع المتطلبات ليس بشكل كامل ؛
- العامل البشري (مصدر المعرفة ويتحدث المؤدي عن نفس الشيء ، لكنهما يفهمانه بشكل مختلف) ؛
- الإهمال الشخصي لفناني الأداء والعملاء ؛
- وآخرون (كل منهم داس على المجرفة بطريقته الخاصة).
نتيجة للانغماس غير الكافي في المهمة ، يقوم المطورون بالشيء الخطأ أو لا يفعلون ذلك بشكل كامل ، ويقوم المختبرين بالشيء الخطأ ، والمطورون يفعلون الشيء الخطأ ، ويراقب SRE المعلمات الخاطئة.
كيف يمكن إصلاح هذا؟
في أماكن العمل السابقة ، رأيت خوارزمية العمل التالية:
- جمع المعلومات وتكوين المتطلبات ؛
- الفريق يعتني ويفكر في حل مشترك ؛
- يتم تعيين المنفذ الذي ينفذ المهمة ؛
- مراجعة التعليمات البرمجية؛
- إصلاحات.
- اختبارات؛
- المزيد من الإصلاحات
...
- المزيد من الإصلاحات
- الانتهاء من المهمة الذي طال انتظاره.
, , ?
, , , , . 
يتم عمل وصف للحل التقني حتى قبل أن يبدأ التطوير ثم يراجعه الفريق بأكمله. من أجل الوضوح وتحسين الإدراك ، قررنا تخفيف النص بمخططات الرسوم. الغرض من هذا الإجراء هو تحديد المزالق واختيار الأدوات المناسبة والتفاعل بشكل صحيح مع العقد الأخرى في النظام والقدرة على غمر الفريق بأكمله في الحل. كانت النتيجة التي توقعناها هي انخفاض تكاليف العمالة والأخطاء في العمليات التجارية (بالنظر إلى المستقبل ، سأقول أن الأخطاء في منطق الأعمال قد اختفت عمليًا ، وتم تجنب العديد من الأخطاء الفنية ، وتم تقليل الإصلاحات ، وانخفض متوسط الوقت اللازم لإكمال المهمة بشكل جيد). اتضح أيضًا أنه من الأسهل والأسرع إجراء تعديلات على الوصف النصي أو الرسم التخطيطي مقارنةً بالتعليمات البرمجية المكتوبة بالفعل.
ثم ستكون خوارزمية العمل على النحو التالي:
- جمع المعلومات وتكوين المتطلبات ؛
- الفريق يستعد ويفكر في حل ؛
- تم تعيين مطور مسؤول ؛
- يصف المطور الحل التقني ؛
- ثم تتم مراجعة هذا الحل التقني من قبل الفريق وآخرين منغمسين في مجال الموضوع ؛
- وفقط بعد الاتفاق على الحل ، يكتب المطور الكود ؛
- مراجعة التعليمات البرمجية؛
- اختبارات.
لماذا من المهم جدًا وصف الحل التقني قبل التنفيذ الفعلي:
- مراجعة منطق الحل وتصحيح الأخطاء في مرحلة التصميم ؛
- يغوص المطور بشكل أعمق في المجال قبل التنفيذ ، مما يسمح بالتفكير في البنية مسبقًا ؛
- يمكن للأقسام المجاورة أن تفهم على الفور ما ستكون عليه واجهة برمجة التطبيقات وتكون جاهزة لبدء التطوير الموازي ؛
- يوضح احتياجات الزملاء حسب التنفيذ ؛
- ( , , ).
Exness?
بعد أن أتيت إلى Exness ، أردت التعود بسرعة على الفريق ، ودراسة البنية التحتية والبدء في حل المهام القتالية. في المهمة الأولى الشاقة ، قررت استخدام الخبرة المتراكمة وتقليل مخاطر حل المشكلة بشكل غير صحيح. لوصف تفاعل الخدمات ، قررت استخدام مخططات التسلسل ، مخطط كتلة لوصف تشغيل الخوارزميات ومخططات ER لوصف مخطط قاعدة البيانات.
في عملية رسم المخطط ، تعلمت من زملائي الخدمات التي قد تكون مطلوبة لحل مشكلتي ، وتحققت من الطلبات المقدمة إليهم والبيانات الموجودة في قاعدة البيانات ، لذلك فهمت بالفعل ماذا وكيف يعمل. لم يستغرق الأمر وقتًا طويلاً لتطوير الرسم التخطيطي ، وأثناء مراجعة المخطط ، تلقيت ملاحظات مفيدة:
- أراد مطور الواجهة الأمامية معرفة ما هي الحالات والبيانات والحالات التي سيحصل عليها من النهاية الخلفية ؛
- يحتاج ضمان الجودة إلى فهم مصدر البيانات في الخدمة من أجل تغطية أكبر عدد ممكن من الحالات.
في الرسم التخطيطي ، قمت بتفصيل الاستثناءات وكيفية خروجها ومصادر البيانات المستخدمة. وقد أتاح ذلك عرض الزملاء بصريًا كيف تعمل الوظيفة وما يمكن توقعه منها ، على التوالي ، يمكن للزملاء البدء في تنفيذ أجزائهم دون انتظار التنفيذ الخاص بي. عرف مطور الواجهة الأمامية كيف ستستجيب الخدمة ويمكنه البدء في كتابة عمليات الدمج ؛ كان لدى QA معلومات حول كيفية استجابة الخدمة للمواقف المختلفة وكيفية إعادة إنتاج هذه المواقف. ونتيجة لذلك ، تبين أن التطوير والانغماس في المهمة سريعان للغاية ، واستكمل المخطط المرسوم توثيق الخدمة قيد التطوير.
مثال
المثال الموضح أدناه مركب من المواقف المختلفة.
تلقى المطور الجديد مهمة بالصيغة " اكتب خدمة مصغرة جديدة لرفض الطلبات المتأخرة. أبلغ العملاء بتغيير الحالة. "
بعد توضيح التفاصيل الفنية ، يمكنك فهم المشكلة على النحو التالي:
- بناء خدمة مصغرة ، وإنشاء وظيفة POST واحدة فيها - طريقة API تسمى رفض_old_requests ؛
- في طريقة API هذه ، تحتاج إلى الحصول على البيانات من قاعدة البيانات وتحديد عوامل التصفية حسب المستخدم والحالة والتاريخ في الطلب ؛
- لكل طلب ، قم بتغيير الحالة في الخدمة التي تدير الطلبات ؛
- ثم أرسل طلبًا إلى خدمة الإعلام لإعلام المستخدمين بالتغيير في حالة التطبيق.
قد يبدو مخطط التسلسل لهذه المهمة كما يلي:
وما الأخطاء التي قد تواجهها:
- في ظل الخدمة المصغرة الجديدة ، يمكن للمحلل أن يقصد طريقة واجهة برمجة التطبيقات المعتادة في الخدمة المصغرة للعمل مع الطلبات ، ولكن من الصعب التعرف على مثل هذا السيناريو (في ممارستي كانت هناك حالة فهم فيها المحلل طريقة واجهة برمجة التطبيقات المعتادة كخدمة مصغرة ، بقدر ما أعرف أن المحلل لم يتكيف مع المصطلحات الصحيحة) ؛
- من الممكن أن يكون للتطبيق تطبيقات فرعية أو تطبيقات ذات صلة ، قد لا يعرفها المطور الجديد ، وقد ينسى المحلل الإبلاغ ويأمل أن يحصل المطور نفسه على المعلومات ؛
- ربما سيكون هناك الكثير من الطلبات ، وسيستغرق رفضهم في الإنتاج وقتًا طويلاً. في هذه الحالة ، سيكون من الأفضل الاستلقاء والسماح بالرفض في الخلفية ؛
- — , . , .
في المجموع ، اتضح أن مثل هذا الحل يجب إعادة كتابته من البداية ، لأن وجود مثل هذه الأخطاء يمكن أن يجعل التنفيذ غير قابل للتطبيق.
إذا كتبت حلاً تقنيًا قبل التطوير واستخدمت مخطط تسلسل للتوضيح ، فسيكون بمقدور المزيد من الزملاء المنغمسين في مجال الموضوع أثناء مراجعته رؤية الأخطاء والإشارة إليها. وربما يكون المطور نفسه قادرًا على رؤية بعض المشكلات وإصلاحها قبل المراجعة.
أؤكد لكم ، مجرد التحدث عن حل مشكلة ما لا يعني حل المشكلة بشكل صحيح ، فلن يعبر المرء عنها بشكل صحيح ، والآخر لن يفهمها بشكل صحيح ، ولن يتم تنفيذ المهمة بشكل صحيح. مخطط التسلسل ليس رصاصة فضية ، ولكنه سيساعد في كثير من الحالات في توضيح بعض التفاصيل.
كيف سيبدو الرسم البياني بعد التصحيحات:
ما هو استخدام الرسوم البيانية؟
ليس كل شخص قادرًا على نقل الفكرة إلى الورق جيدًا ، لذا من الأفضل أحيانًا تخفيف النص بوصف رسومي. سيكون الوصف الأكثر وضوحًا للمهمة مفيدًا ليس فقط للمطورين ، ولكن أيضًا للمختبرين ، حيث يواجهون نفس مشكلة الانغماس مثل المطورين. لا يحتاج المختبرين فقط إلى التحقق من النتائج الإيجابية ، ولكن للتأكد من أن النظام يستجيب بشكل صحيح ومتوقع في أي موقف ؛ لمحاكاة مثل هذه الحالات ، يحتاج المرء إلى فهم جيد لما تغير في النظام. بالنسبة للفريق ككل ، قد يكون من الأنسب تخزين الوثائق في شكل رسوم بيانية أو مخططات مختلفة ، لأنها مقتضبة ، مع التغييرات الكبيرة التي تستغرق وقتًا أقل في التحرير من الوصف النصي. في إعادة البناء الرئيسية ، لا غنى عن الرسوم البيانية لأنها تسمح لك بسرعة فهم من وكيف يعمل مع عقدة معينة في النظام.بالنسبة لقادة الفريق ، سيكون الشيء مفيدًا حيث يمكنك تقليل وقتك ووقت زملائك المبتدئين للانغماس ، وبالتالي التخطيط للمهام بدقة أكبر. عند نقل الحالات من مطور إلى آخر ، يتم تقليل تكاليف الوقت ، على التوالي ، يتحسن الوضع مع عامل الناقل.
ما هي الاستنتاجات التي يمكن استخلاصها؟
تعد مخططات التسلسل أداة قوية جدًا ومفيدة توفر وقتك أنت وزملائك. يبسط الوصف المرئي الإدراك ويسمح لك بالتركيز على الحل نفسه دون التعمق في التنفيذ الفني. لكن لا نقول بأي حال من الأحوال أن مثل هذا الوصف المرئي هو خلاص من جميع المشاكل ، لكنه سيساعد في حل جزء كبير منها.
ستساعد المخططات بالتأكيد في:
- جودة وسرعة الانغماس في المشروع / المهمة ؛
- تحسين الوضع مع عامل الحافلة ؛
- تقليل تكاليف العمالة للحفاظ على الوثائق الفنية ؛
- تبسيط نقل القضايا بين الزملاء ؛
- تقليل تكاليف العمالة للتنفيذ والاختبار ومراجعة الكود ، حيث تتم مراجعة منطق حل المشكلة حتى قبل بدء التنفيذ - ستتجنب الكثير من الأخطاء.
شخصيًا ، في ممارستي ، كانت الرسوم البيانية وما زالت أداة لا غنى عنها.
أتمنى لك أيضًا العثور على الأدوات التي من شأنها تحسين عملك. شكرا لك على القراءة حتى النهاية.
ملاحظة: اكتب في التعليقات ، هل تستخدم هذه الممارسة ، ما هي الأدوات التي تستخدمها؟