البنية التحتية كرمز: كيفية التغلب على مشاكل XP

يا هبر! اعتدت أن أشتكي من الحياة في البنية التحتية كنموذج رمز ولم أعرض أي شيء لحل الوضع الحالي. عدت اليوم لأخبرك ما هي الأساليب والممارسات التي ستساعدك على الهروب من هاوية اليأس وتوجيه الوضع في الاتجاه الصحيح.

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

من نحن وأين نحن وما هي المشاكل التي نواجهها

نحن الآن في فريق Sre Onboarding ، والذي يتكون من ستة مبرمجين وثلاثة مهندسي بنية تحتية. نحاول جميعًا كتابة البنية التحتية كرمز (IaC). نقوم بذلك لأننا ، من حيث المبدأ ، نعرف كيف نكتب الكود وفي سوابقنا ، نحن مطورون للمستوى "فوق المتوسط".

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

مجموعة التقنيات التي نستخدمها في IaC الخاص بنا.

• Terraform لإنشاء الموارد.
• باكر لبناء الصور. هذه صور Windows ، CentOS 7.
• Jsonnet للقيام بعمليات بناء قوية في drone.io بالإضافة إلى إنشاء packer json ووحدات terraform الخاصة بنا.
• اللازوردية.
• Ansible عند طبخ الصور.
• Python للخدمات المساعدة ، وكذلك توفير البرامج النصية.
• وكل هذا في VSCode مع الإضافات المشتركة بين أعضاء الفريق.

الإخراج من بلدي المقال الأخير كنت على هذا النحو: حاولت أن ألهم (أولاً وقبل كل شيء في نفسي) التفاؤل ، أردت أن أقول إننا سنحاول الأساليب والممارسات المعروفة لدينا من أجل التعامل مع الصعوبات والصعوبات الموجودة في هذا المجال.

نحن نكافح حاليًا مع مشكلات IaC التالية:

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

البرمجة المتطرفة (XP) للإنقاذ

جميع المطورين على دراية بالبرمجة المتطرفة (XP) والممارسات التي تكمن وراءها. لقد عمل الكثير منا على هذا النهج ، وكان ناجحًا. فلماذا لا تستفيد من المبادئ والممارسات الموضوعة هناك للتغلب على صعوبات البنية التحتية؟ قررنا اتباع هذا النهج ونرى ما سيحدث.

التحقق من قابلية تطبيق نهج XP على مجالكفيما يلي وصف للبيئة التي يناسبها نظام XP ، وكيف يرتبط بنا:

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

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

3,4. فريق تطوير موسع صغير ومشترك في الموقع. تسمح التقنية التي تستخدمها باختبارات الوحدة والاختبارات الوظيفية المؤتمتة. هاتان النقطتان لا تناسبنا تمامًا. أولاً ، لسنا فريقًا مشتركًا في الموقع ، وثانيًا ، هناك تسعة منا ، ويمكن اعتبارهم فريقًا كبيرًا. على الرغم من أنه وفقًا لعدد من التعريفات الخاصة بالفريق "الكبير" ، فإن الكثير منهم يزيد عن 14 شخصًا.

لنلقِ نظرة على بعض الممارسات من XP وكيف تؤثر على سرعة التعليقات وجودتها.

مبدأ حلقة التغذية الراجعة في XP

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

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

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

هام: يمكن أن تكون التعليقات حلاً لجميع المشكلات المذكورة أعلاه. إلى جانب ممارسات XP ، يمكن أن تخرجك من هاوية اليأس.

كيف تخرج نفسك من هاوية اليأس: ثلاث ممارسات

اختبارات

تم ذكر الاختبارات مرتين في حلقة ملاحظات XP. الأمر ليس كذلك فقط. إنها ضرورية لجميع تقنيات البرمجة المتطرفة.

من المفترض أن يكون لديك اختبارات الوحدة والقبول. يمنحك البعض ملاحظات في بضع دقائق ، والبعض الآخر في غضون أيام قليلة ، لذلك يستغرقون وقتًا أطول للكتابة وتشغيل أقل.

يوجد هرم اختبار كلاسيكي يوضح أنه يجب إجراء المزيد من الاختبارات.

كيف ينطبق هذا المخطط علينا في مشروع IaC؟ في الواقع ... لا على الإطلاق.

• اختبارات الوحدة ، على الرغم من حقيقة أنه يجب أن يكون هناك الكثير منها ، لا يمكن أن يكون هناك الكثير. أو أنهم يختبرون شيئًا ما بشكل غير مباشر للغاية. في الواقع ، يمكننا القول إننا لا نكتبها على الإطلاق. ولكن فيما يلي بعض التطبيقات لمثل هذه الاختبارات التي ما زلنا قادرين على القيام بها:
  1. اختبار الكود على jsonnet. هذا ، على سبيل المثال ، خط أنابيب البناء لدينا في الطائرات بدون طيار ، وهو معقد للغاية. تمت تغطية الكود الموجود على jsonnet جيدًا من خلال الاختبارات.
     نحن نستخدم هذا إطار اختبار الوحدة لـ Jsonnet.
  2. اختبارات البرامج النصية التي يتم تنفيذها عند بدء تشغيل المورد. نصوص بلغة بايثون ، مما يعني أنه يمكن كتابة الاختبارات عليها.
• من المحتمل التحقق من التكوين في الاختبارات ، لكننا لا نفعل ذلك. من الممكن أيضًا تكوين التحقق من قواعد تكوين الموارد من خلال tflint. ومع ذلك ، هناك عمليات تحقق أساسية للغاية فقط من أجل terraform ، ولكن العديد من نصوص الشيكات مكتوبة لـ AWS. ونحن على Azure ، لذلك لا يتناسب ذلك مرة أخرى.
• اختبارات تكامل المكونات: تعتمد على كيفية تصنيفك لها ومكان وضعها. لكنهم يعملون في الأساس.

  هذا ما تبدو عليه اختبارات التكامل.

  
  
  هذا مثال عند إنشاء الصور في Drone CI. للوصول إليهم ، عليك الانتظار 30 دقيقة حتى يتم تجميع صورة Packer ، ثم 15 دقيقة أخرى للانتظار حتى يمروا. لكن هم!

  خوارزمية التحقق من الصورة

  1. أولاً ، يجب على Packer تحضير الصورة بأكملها.
  2. بجانب الاختبار ، يوجد تضاريس مع حالة محلية ، والتي ننشر بها هذه الصورة.
  3. عند النشر ، يتم استخدام وحدة صغيرة ، ملقاة بجانبها ، لتسهيل العمل مع الصورة.
  4. عندما يتم نشر الجهاز الظاهري من الصورة ، يمكنك البدء في التحقق. في الأساس ، يتم إجراء الفحوصات على الجهاز. يتم التحقق من كيفية عمل البرامج النصية عند بدء التشغيل ، وكيفية عمل الشياطين. للقيام بذلك ، عبر ssh أو winrm ، نذهب إلى الجهاز الذي تم رفعه حديثًا ونتحقق من حالة التكوين أو ما إذا كانت الخدمات قد ارتفعت.

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

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

يشجع عدم وجود اختبارات الوحدة عند إنشاء الصور أو وحدات التضاريس على تحويل العمل إلى خدمات منفصلة يمكن سحبها ببساطة عبر REST أو إلى نصوص Python.

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

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

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

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

برمجة الزوج

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

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

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

فيما يلي أنماط البرمجة الزوجية وإمكانية تطبيقها في العمل على IaC:

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

ضع في اعتبارك توافق مشاكلنا مع الأسلوب:

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

المشكلة الرئيسية في تطبيق هذا النمط في IaC هي وتيرة العمل غير المتكافئة. في تطوير البرمجيات التقليدية ، لديك حركة موحدة للغاية. يمكنك أن تأخذ خمس دقائق لكتابة N. خذ 10 دقائق لكتابة 2N و 15 دقيقة لكتابة 3N. هنا يمكنك قضاء خمس دقائق وكتابة N ، ثم قضاء 30 دقيقة أخرى وكتابة عُشر N. هنا لا تعرف أي شيء ، لديك قابس ، أيها الغبي. يستغرق الإعراب وقتًا ويشتت الانتباه عن البرمجة الفعلية.

الخلاصة: في شكله النقي لا يناسبنا.

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

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

الخلاصة: للأسف ، سرعة العمل لا تسمح باستخدام تنس الطاولة كممارسة برمجة زوجية في IaC.

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

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

الخلاصة: من المحتمل أن تكون قابلة للتطبيق ، نحن لا نتخلى عن المحاولة.

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

النتائج العامة لاستخدام البرمجة الزوجية:

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

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

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

التخطيط والاتصال

آخر مجموعة من الممارسات التي يتم من خلالها حل مشكلات نظام التشغيل هي تنظيم العمل مع المهام نفسها. وهذا يشمل أيضًا تبادل الخبرات ، الذي هو خارج العمل الثنائي. ضع في اعتبارك ثلاث ممارسات:

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

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

مزايا الرؤية البصرية للمهام:

• السببية. كل مهمة تؤدي إلى بعض الأهداف العالمية. يتم تجميع المهام في أهداف أصغر. مجال البنية التحتية نفسه تقني تمامًا. ليس من الواضح دائمًا ما هو تأثيره المحدد على الأعمال التجارية ، على سبيل المثال ، كتابة كتاب تشغيل حول الانتقال إلى nginx آخر. وجود البطاقة المستهدفة بجانبها يجعل هذا أكثر وضوحًا.
  
  السببية هي خاصية مهمة للمشاكل. يجيب مباشرة على السؤال: "هل أفعل هذا؟"
• تماثل. هناك تسعة منا ، ومن المستحيل جسديًا مهاجمة الجميع في مهمة واحدة. قد لا تكون المهام من منطقة واحدة كافية دائمًا أيضًا. نحن مجبرون على موازاة العمل بين مجموعات العمل الصغيرة. في الوقت نفسه ، تجلس المجموعات على مهمتها لبعض الوقت ، ويمكن تقويتها بواسطة شخص آخر. من مجموعة العمل هذه يسقط الناس أحيانًا. شخص ما يذهب في إجازة ، شخص ما يعد تقريرًا لمؤتمر DevOps conf ، شخص ما يكتب مقالًا عن Habr. إن معرفة الأهداف والمهام التي يمكن القيام بها بالتوازي يصبح أمرًا مهمًا للغاية.

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

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

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

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

أثناء العرض التوضيحي ، من الضروري الكشف عن تفاصيل المهمة والتأكد من إظهار عملها.

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

2. كيف تم حل المشكلة من قبل؟ على سبيل المثال ، كان النقر الجماعي للفأرة مطلوبًا ، أو كان من المستحيل فعل شيء على الإطلاق.

3. كيف نقوم بتحسينه. على سبيل المثال: "انظر ، الآن هناك نص ، ها هو ملف تمهيدي."

4. أظهر كيف يعمل. من المستحسن تنفيذ أي برنامج نصي للمستخدم مباشرة. أريد X ، أفعل Y ، أرى Y (أو Z). على سبيل المثال ، انشر NGINX ، عنوان url للدخان ، احصل على 200 OK. إذا كان الإجراء طويلاً ، فاستعد مسبقًا للعرض لاحقًا. يُنصح بعدم الكسر خاصةً إذا كانت هشة قبل ساعة من العرض التوضيحي.

5. اشرح مدى نجاح حل المشكلة ، وما هي الصعوبات المتبقية ، وما لم يكتمل ، وما هي التحسينات الممكنة في المستقبل. على سبيل المثال ، الآن cli ، سيكون هناك أتمتة كاملة في CI.

من المستحسن أن يبقى كل مكبر في غضون 5-10 دقائق. إذا كان العرض التقديمي مهمًا بشكل واضح وسيستغرق وقتًا أطول ، فيرجى الموافقة عليه مسبقًا في قناة sre-takeover.

بعد الجزء وجهًا لوجه ، هناك دائمًا مناقشة في الموضوع. هذا هو المكان الذي تظهر فيه التعليقات التي نحتاجها بشأن مهامنا.

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

استنتاجات طويلة وماذا بعد

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

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

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

طرق المستوى الأعلى للتأثير على نظام التشغيل - التخطيط والعمل مع المهام يعطي تأثيرات بالضبط: تبادل المعرفة الجيد وتحسين جودة التطوير.

استنتاجات قصيرة في سطر واحد

• تعمل ممارسات XP في IaC ، ولكن بكفاءة أقل.
• تقوية ما ينجح.
• ابتكر آليات وممارسات التعويض الخاصة بك.

المصدر: www.habr.com