🔕 👩🏻‍🔧 👩🏼‍🎤 سفينة الفضاء على محرك الاحتراق الداخلي. النجاة من المعركة بالديون الفنية 👩🏻‍🎤 🉐 👧🏼

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

اسمي دينيس ، أنا قائد فريق Backend في Wrike. أنا مسؤول عن التسليم في فريقي وعن نمو المطورين في العديد من الفرق. حدث ذلك أن كل خبرتي تقريبًا تعمل في مجال التكنولوجيا المالية. لقد عملت في بنكين كبيرين ، والآن أعمل في Wrike.

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

Wrike هو حل تعاون فريق SaaS نبيعه لعملائنا. نصنع Wrike باستخدام Wrike لتنظيم التنمية.

طور Wrike ثلاثين فريقًا من scrum. الخدمة متاحة 24/7 ، لذا يجب أن تكون القرارات التي نتخذها موثوقة. إذا حدث خطأ ما ، فسيؤثر ذلك على عمل جميع الفرق تقريبًا.

لماذا سفن الفضاء؟

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

ما هو الدين الفني؟

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

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

خوارزمية الديون الفنية

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

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

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

الآن دعونا نرى كيف تعمل الخوارزمية في الواقع باستخدام عدة حالات كمثال.

الحالة الأولى

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

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

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

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

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

الحالة الثانية

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

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

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

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

الحالة الثالثة

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

حقيقتان قديمتان:

يعمل بالتأكيد.
لا أحد يعرف كيف يعمل. لهذا السبب تراث.

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

هناك العديد من الأساليب هنا التي يمكن أن تساعد ، خاصة إذا كان حجم الكارثة كبيرًا بما يكفي في مقدار الرمز:

. Java , , , . , , , , ;
. , , , . , , . , ;
-.

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

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

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

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

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

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

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

كيفية تنظيم العمل

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

لفهم ماهية التكرار ومجموعة المهام التي يحتوي عليها ، استعارنا مفهوم تعريف تم من سكروم. هذه مجموعة من المعايير التي يجب استيفاؤها حتى يتم اعتبار القصة مستوفاة.

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

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

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

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

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

يمكنك حماية نفسك من هذه التغييرات بعدة طرق:

— . , , - , .
, . git hook, git commit git push. unit test, , - , , , : .

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

كيفية تجاوز المدير النهائي

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

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

يمكنك الاتفاق على حصة زمنية. على سبيل المثال ، سيخصص 10٪ من الوقت للمطورين للعمل على الديون التقنية. مثل هذه الحصة لن تسمح بالتخلص من الديون التقنية ، لكنها ستسمح لها بعدم الانتفاخ.

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

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

ربما لن تتزامن الأهداف على الفور ، ولكن في ربع السنة أو حتى في السنة. لكن هذا سيسمح لك بفهم متى سيكون العمل جاهزًا للتغيير.

إذا تمكنت من مزامنة الأهداف ، فستتلقى جميع المكافآت: تحديد الأولويات والموارد وتنظيم جميع الأعمال. سيساعدك مالك المنتج في القيام بذلك. المهمة الرئيسية هي الاتفاق معه.

مجموع

عندما نتحدث عن التغييرات في المجالات الرئيسية للمنتج ، تتعقد خوارزمية بسيطة من أربع خطوات:

تتم إضافة خطوتين إضافيتين. الأول هو فهم ما نعمل معه. الثاني - بعد التغليف - فهم كيفية عمل الحل وكيفية منع التغييرات في التعليمات البرمجية الخاصة بك.

باستخدام هذه الخوارزمية وتوصياتي لتنظيم العملية ، يمكنك العمل مع أي دين تقني.

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

سفينة الفضاء على محرك الاحتراق الداخلي. النجاة من المعركة بالديون الفنية