تحية! أنا فاليري لابتيف ، رئيس تطوير LM في روسيا. لمدة عامين كنت بحاجة إلى رفع قسم ضخم ، وكانت تجربة مثيرة للاهتمام إلى حد ما.
الحقيقة هي أن ليروي ميرلين موجود في العديد من البلدان. الشركة الأم في فرنسا تسمى ADEO. يكتبون رمز لفرنسا وإيطاليا وإسبانيا وروسيا. تختلف نماذج أعمالنا: إذا احتفظنا بأقل الأسعار في السوق الروسية (أقل من كل المنافسين في المراقبة) ، فعندئذٍ يختلف كل شيء في أوروبا. في الواقع ، يختلف البحر - من خصائص اللغة إلى التشريعات الأخرى. هناك ميزات للبنية التحتية لروسيا (نفس التأخيرات الكبيرة جدًا في خاباروفسك) ودورة حياة أخرى لوضع أمر. كل هذا يؤدي إلى مثل هذا الرمز الجهنمي الذي يتكون من كتل IF ضخمة:
قبل عامين ، كان لدينا 60 متجراً والعديد من ميزات قائمة الأمنيات. توالت في حوالي ستة أشهر وليس دائما بشكل صحيح. القشة الأخيرة بعد مجموعة من الميزات التي تم رفضها ذات الأولوية المنخفضة كانت طلبًا لإدخال حقل صف بالترتيب ، حتى نتمكن من تحليله لاحقًا. كان هذا ضروريًا لميزات التسليم في روسيا ، لأن البلد أكبر من البلدان الأخرى التي توجد فيها LM. لقد رفضوا هذا ، أو بالأحرى ، قالوا إنه سيكون في مكان ما خلال سبعة إلى ثمانية أشهر.
دورة نصف السنة للشركة الأم على مهل لم تناسبنا. بطبيعة الحال ، اقترحنا كتابة التعليمات البرمجية الخاصة بنا ، وتقديمها للمراجعة وانتظار التنفيذ ... صحيح ، لا شيء جيد جاء من هذا.
لماذا تم تنفيذ الميزات ببطء؟
القصة بسيطة للغاية: على الرغم من العشرات من المتاجر لدينا ، نحن لسنا أول من في العالم. هناك احتياجات فرنسا (حيث المنظمة الأم) ، وهناك احتياجات البلدان الأخرى. يتم تحديد الأولويات وفقًا لربح أو تكلفة محتملة لمجموعة من الشركات ويتم تنفيذها بهذا الترتيب. أي أن ميزاتنا لا تُصنع أبدًا تقريبًا ، إلا إذا كان الحظ محظوظًا وفي نوع من الركض ، سينهي شخص ما دوره في وقت مبكر ويذهب لتفكيك الجزء السفلي من الأعمال المتراكمة.
الميزة الثانية هي أنه عندما تقوم بتحريك أي ميزة إلى الفرع الرئيسي (هنا في رمز Leg-IF-IF القديم) ، فأنت بحاجة إلى التحقق من سلوكه في البلدان الأخرى. اسمحوا لي أن أقتبس
441869 من باش:
مبرمج: حسنا ، تخيل أنك كاتبة وتدعم مشروع "الحرب والسلام". لديك TK - اكتب فصلاً حول كيف سار ناتاشا روستوفا في الحديقة تحت المطر. أنت تكتب - "كانت السماء تمطر" ، باستثناء ، رسالة الخطأ تطير: "ماتت ناتاشا روستوفا ، والاستمرارية مستحيلة". لماذا هي ميتة؟ تبدأ في فهم. اتضح أن أحذية بيير بيزوخوف الزلقة ، سقط ، وأصاب مدفعه الأرض وأطلق الرصاص على عمود ، والرصاصة من العمود ارتدت إلى ناتاشا. ما يجب القيام به شحن بندقية الخمول؟ تغيير الأحذية؟ قررنا إزالة العمود. تلقينا الرسالة: "لقد توفى الملازم رزفسكي". اتضح أنه في الفصل التالي يميل على عمود لم يعد ...
بشكل عام ، عندما نقدم شيئًا لمكتب الشباك الروسي ، في مكان ما في البرازيل ، قد ينتعش شخص ما.
هذا يعني تغطية اختبار كبيرة جدًا ، وإجراءات طويلة قبل النشر ، وممانعة عامة في الحفاظ على الكود الذي ينمو بسرعة. لذلك ، فإن أقل الميزات - كلما كان ذلك أفضل. لكنك تمسك هناك.
الموقف ككل أمر مفهوم للغاية ، وسأفعل ذلك على موقع الشركة الأم. لأنه عقلاني.
حل المشكلات
كان النهج الأول على الجبهة: اقترحنا فتح رمز لنا للقيام بطلب سحب هناك. كان من المفترض أنه سيكون هناك حوالي 10 مطورين سيقومون بترميز المهام المهمة للأعمال بسرعة وبسرعة ، ويعطونها للفرنسيين ، وسيختبرون وفقًا لإجراءاتهم الخاصة ، وسيكون كل شيء على ما يرام.
في الواقع هؤلاء الأشخاص كانوا بالفعل: لقد شاركنا في استبعاد منطق الأعمال الإضافي الذي حصلنا عليه من بلدان أخرى ، مثل الخصومات التراكمية المختلفة والأسهم غير العادية (والتي هي ببساطة مستحيلة مع نموذج أعمالنا) ، ووضع الدمى في هذا المكان.
أراد الفرنسيون في ADEO دورة إصدار للتداول وتثبيت الإصدارات الجديدة من خلال أنفسهم. قبلت عرضنا حول فرع واحد للتجارب.
أعطى الوصول ، وبدأ في اتخاذ رمز للمراجعة. اتضح أن تكون بطيئة على أي حال. النشرات لعدة أشهر - ليس هذا هو الحال. حسنا فازت بضعة أسابيع ، ولكن لا تزال العملية لا تصلح.
ثم ، لمدة ستة أشهر ، لم تظهر ميزة مهمة بالنسبة لنا في جزء المحتوى (إدارة بيانات المنتج التي يراها العميل). جلسنا لمدة ستة أشهر دون إطلاق سراح. إما أن الميزة لم تنته ، أو الاختبارات لم تنجح ، ثم لم يدركوا بالضبط ما نحتاجه. نتيجة لذلك ، جلسنا على نظام رئيسي لفترة طويلة دون تحديثات. كان هناك NodeJS + PostgreSQL + Couchbase + Elasticsearch + Angular في المقدمة. في التعليمات البرمجية ، نظرًا لعدد من الطبقات الأثرية ، تمت مواجهة الأشياء ، مثل سوء استخدام قاعدة بيانات SQL وقاعدة البيانات غير العلائقية. في أحد الأماكن ، تم أخذ جزء كبير من البيانات الرئيسية ، وإدخاله في حقل واحد من قاعدة بيانات SQL ، ثم تقسيمه إلى كيانات في قاعدة بيانات NoSQL. في صفحة واحدة من الموقع مع عرض البضائع ، كان هناك عشرات ومئات من هذه الطلبات. مع مزيد من القراءة لهذا الإرث ، بدأ الشعر على أجزاء مختلفة من الجسم في التحرك. لقد فهمنا ما هي خصوصيات الإرث الذي يواجهه قسم الرأس.
التنمية الخاصة
كانت الفكرة الأولى هي القيام ببعض الميزات معًا. في الحال ، أي في فرنسا. ذهب أربعة منا إلى فرنسا وبدأوا في الجلوس بجانب زملائنا لفهم كل شيء معًا والقيام بما نحتاج إليه.
لم ينجح ومع ذلك ، كان كل شيء بطيئًا جدًا.
الفكرة الثانية كانت أن تتفوق على كل ما هو موجود بالفعل وأن تنهيه تدريجيا جلسنا من قبل اللجنة المعمارية ، وقمنا بتقييم الآفاق وحساب خطط التطوير التقريبية وأدركنا أننا بحاجة إلى اختيار طريقة مختلفة. على وجه التحديد ، نعم ، لشوكة ، ولكن ليس لتطوير الكود الموجود ، ولكن لتقسيم المتراصة إلى أجزاء ووضع خدمات ميكروية عند الحاجة.
وهذا هو ، خططنا لإعادة كتابة كتل كاملة من المنطق في شكل رمز لدينا. ولهذا بدأوا في تحويل جزء من الخدمات إلى ما يمكن القيام به معنا. بدأنا في توظيف المطورين. ثم تابعنا تمامًا كومة الشركة الأم - Java و Spring وكل شيء قريب ، بدلاً من Couchbase كان Mongo (هذه قاعدة NoSQL مماثلة).
مع تطور المشروع ، أدركنا أننا بحاجة إلى القيام بالكثير من الأشياء بطريقتنا الخاصة (لأنه أسرع وأسهل حتى لا ندعم الإرث الذي لا نحتاج إليه ، على وجه الخصوص) ، وبدأنا في التوسع لتشمل التقنيات الأخرى. ثم كان هناك Java 7 و Wildfly (JBoss سابقًا) و SVN. سألنا عن سبب عدم ترحيلهم إلى Java 8 و GIT و Tomcat. اتضح أنهم لن يمانعوا ، ولكن بعد بضع سنوات. في غضون ذلك ، أيها الأعزاء ، اكتب على المكدس القديم. لذلك نحن كلمة للكلمة وقررت أن تفصل تماما. قامت الشركة بفرز السؤال ، ما هي إيجابيات وسلبيات ، وأيدته بالكامل.
على الفور تقريبا ألقى حوالي 30 في المئة من الكود ، وكتب الكثير من الخدمات الدقيقة الخاصة بهم حولها. من حقيقة أنهم لم يمسوا ، فإن هذا هو جوهر المعاملات التجارية مقابل المال.
بطبيعة الحال ، فإن أول ما فكرنا فيه هو كيفية التمييز بين مجالات التنمية. أود أيضًا أن أتحدث عن هذا بشكل منفصل ، ولكن بشكل عام ، فإن المخطط على النحو التالي:
الأفقي هو مجال الأعمال. على سبيل المثال ، كل ما يتعلق بعلاقات العملاء (الخلية الخضراء الأولى) هو مجال واحد ، وهناك مجموعة من التطبيقات من قسم واحد. يؤدي الفصل بين الوظيفة الهدف إلى إنشاء العديد من التكرارات للرمز في أماكن مختلفة ويتطلب ناقل شركة جيدًا (مرة أخرى ، قصة منفصلة) ، ولكنه يسمح لك بالعثور على النهايات بوضوح وحل المشكلة حتى النتيجة. بالنظر إلى هذا بعد ما يقرب من ثلاث سنوات ، يمكنني أن أقول أن العمارة قد تم اختيارها بشكل صحيح ، لكن إذا كنت أعرف ما أعرفه الآن ، فسأجري بعض التغييرات.
لقد توصلنا الآن إلى استنتاج مفاده أنه يوجد في الهيكل العام العديد من فرق الميزات التي تشكل فرق منتج كبيرة. في الوقت نفسه ، لا يشمل فريق المنتج المطورين أنفسهم فحسب ، بل يشمل أيضًا المصممين وممثلي الأعمال. نظرًا لأن الهدف النهائي لأي قسم لتكنولوجيا المعلومات في إحدى الشركات هو إما زيادة سرعة تطوير الأعمال ، أو خفض التكاليف بسبب الأتمتة ، فنحن بحاجة إلى ممثلين عن العمل ضمن هذه الفرق. التجزئة هو كل شيء عن تكنولوجيا المعلومات. لا توجد عملية واحدة يمكن تسميتها "غير مقبولة".
فريق الميزات عبارة عن مجموعة صغيرة من الأشخاص (عادة ما يكون محللًا واختبارًا ومطورًا للجهة الخلفية ومطورًا للواجهة الأمامية ، مكتب خدمات المشاريع). عادة ما يلعب المحلل دور مالك المنتج أو يأتي شخص من الشركة إلى هذا المكان. المالك لديه تراكم ، والأولوية ، والمهام. انه يملي تنميتها. يختار المطور خيار التنفيذ بنفسه ، ويناقش في الفريق ما الذي سيتم عمله وكيف. ليس لدينا قيادة فريق لتقييم المهمة ، والترميز ، وصنع القرار. الجميع يفعل كل شيء. عادة ما يقدم أعضاء الفريق الأكثر خبرة الآراء التي يرغب الكثيرون في الاعتماد عليها. ولكن يمكن لأي شخص اتخاذ قرار. بالطبع ، هناك تعارضات عندما لا يستطيع مطوران الاتفاق على تطبيق ميزة. إذا تحول الصراع إلى شخصية - فأنت بحاجة إلى تصعيد في الرأس. ولكن معظمها هو اختيار الحل للتنفيذ. ثم يقف الجميع ويتوجهون بالقرب من اللوحة حتى يجدوا خيارًا يناسب الجميع. عادة ما يتحول بسرعة ، ولكن كانت هناك حالات عندما جادلوا طوال اليوم. عندما تصل الحجة إلى طريق مسدود ، يتم استدعاء الحكم غالبًا - أي شخص من فريق آخر يثق به الجميع. يشرحون جوهر المشكلة ، وقال انه يحل. حتى جون أو متدرب يمكنه المشاركة من الناحية النظرية في هذا النزاع ، لكنني أعرف فقط حالتين من هذه الحالات - عادةً ما يكون لدى jons معلمه يستمع إليه.
مثال على فريق الميزات: لدينا منصة خدمات تتيح لك شراء خدمة مع مقاول إلى جانب البضائع. على سبيل المثال ، اشتريت بابًا - يمكنك وضعه في السلة والتثبيت فورًا ، حتى يأتي سيد مستقل ويعمل وفقًا لمعاييرنا. ونحن سوف تحقق ودفع ، وإعطاء الضمان. لذلك ، يصنع هذا الفريق منتجًا ، لذلك يكتب حلول تكنولوجيا المعلومات ويتخذ قرارات العمل ، ويغير العمليات في المتاجر. نتفق مع المقاولين. هناك - صاحب المنتج من العمل ، كاتب من المتاجر ، المهندس المعماري ، المطورين ، المحللين والاختبار. يستخدمون على الفور منصة API الخاصة بشركتنا لتقديم جميع البيانات ذهابًا وإيابًا وكتابة خدمة microservice. يتيح لك هذا النهج - الذي يعمل على الفور ورجال الأعمال بالتزامن مع المطورين وفريق صغير - إنشاء منتج بسرعة. لكن ، على ما أعتقد ، من الأفضل أن يخبركوا لاحقًا كيف يبدو من الداخل.
في البداية ، لم نكن نريد إجراء اختبارات منفصلة: كان هناك اتجاه بأن على المطور إما اتباع منهجية TDD أو اختبار الكود الخاص به حتى النهاية بنفسه. في الواقع ، لم يكن فعالاً للغاية. في البداية سار كل شيء على ما يرام: كتب - أجبت. تحتاج إلى اختبارات حتى يعمل التطبيق الخاص بك بشكل صحيح. ولكن بعد ذلك ، كلما أصبحت المهام والتطبيقات أكثر ، أصبحت أكثر صعوبة. تلاشت بعض الطلبات ، وذهب البعض إلى المنتج ولم يتغير منذ شهور. أصبح من الصعب كتابة الاختبارات والمحافظة عليها وما إلى ذلك. لقد تغير محللو الفريق. نسبيا في الآونة الأخيرة ، وافقوا على أنهم كانوا مخطئين: هناك حاجة لاختبار. لكن المطورين لا يتوقفون عن كتابة الاختبارات - وفي بعض الأحيان - يقومون بـ TDD. لقد أدركنا لأنفسنا أن الاختبارات التي تتحقق من الوظيفة (التطبيق يعمل بشكل صحيح) والاختبارات التي تتحقق من أن التطبيق يعمل في المواقف الصعبة يجب أن يتم بواسطة أشخاص مختلفين. وللثاني ، هناك حاجة إلى اختبار ، لأنها تغطي الحالات الغريبة المحتملة ليس فقط مع اختبارات الوحدة.
يوجد الآن 60 مطورًا خالصًا - خلفي ، أمامي ، مجموعات كاملة. هناك أيضا محللون ، اختبار والدعم. بالإضافة إلى سبعة إضافيين آخرين. لكن مع ذلك ، لم يتم تجنيد 200 شخص مخطط لهم من العنوان ، لذلك نحن نبحث الآن عن أشخاص جدد ، لأن مجال العمل ضخم. هناك شواغر في
دائرتي ، إذا كان ذلك. وهذا هو ، من التنمية لدينا الآن 74 من حوالي 200.
InnerSource
نظرًا لأن لدينا العديد من الفرق المستقلة في روسيا فقط ، وما زالت هناك فرقًا شهدت شيئًا مشابهًا في العديد من البلدان الأخرى ، فإننا نتحرك في اتجاه
مصدره الداخلي . هذا يشبه إلى حد كبير المصدر المفتوح داخل مجموعة محدودة من الناس.
داخل مجموعة ADEO من جميع شعب البلاد ، كل الكود يقع في جيثب السحابية. تم إعداد المشروع وفقًا لقواعد التصميم الموحدة. لا توجد قيود على الأسلوب والتكنولوجيا والأدوات. عندما يكون لديك شفرة مفتوحة المصدر وقواعد تصميم واضحة ، يمكن لأي مطور على الرصة المساهمة. لنسخك إلى الكود ، تحتاج إلى قراءة المرسى ، استنساخ المستودع ، إجراء تعديل ، إرسال طلب سحب.
حاليا ، البرازيل وروسيا وفرنسا تستخدم بنشاط جدا هذه القاعدة المشتركة.
نحن نحاول الآن نقل رمز المقاولين بالكامل (ولدينا الكثير منهم في اتجاهات مختلفة) إلى InnerSource. في التحليل ، أنشأنا خريطة على محورين: التعقيد الفني للنقل إلى وضع الدائرة الداخلية على محور واحد والمحور الثاني ، ومدى فائدة النقل إلى الدائرة الداخلية بشكل عام. إذا كانت الشفرة فريدة وتحتاج إليها فقط في مكان واحد - ربما لن تضطر إلى لمسها. ولكن إذا استخدمت العديد من الفرق هذا الموقع - فمن الضروري بالتأكيد.
كل هذا يعزز بشكل عام ثقافة التنمية. ويسرع من سرعة العديد من الفرق ، لأنه يمكنك كتابة طلب دمج لأي ميزة تحتاجها. سيتم اعتماده بواسطة فريق المالك ، وسيتم اختباره من قبل الشخص المساهم. أحد الشروط المهمة هو توفر الاختبارات التلقائية وأوصاف أي كود في المستودع.
بعض الفروق الدقيقة أكثر
عندما بدأوا ، لم يكن هناك شيء على الإطلاق. بالتوازي مع المطورين ، جندوا devops. الآن يتم توفير خدمات devobservices كخدمة (بالنسبة لأولئك الذين يحتاجون إليها) ، أو أن فريق المنتج لديه عمليات مكتبية خاصة به ، والتي تحدد بالفعل ماذا وكيف.
يتم التجميع في جينكينز ، ويتم تشغيل الكود في سونار (بدقة أكثر ، بالفعل SonarQube). فشل سونار - لا يوجد إطلاق. اختبار يكتب autotests ، أصحاب رمز - الاختبارات الوظيفية. يتم تقديم قاعدة البيانات كخدمة من قبل مهندسي البنية التحتية. يتم إجراء اختبار الحمل الكامل في حالات نادرة ، نظرًا لأن هيكل قاعدة الاختبار والقاعدة الرئيسية مختلفان: في مرحلة ما قبل الإنتاج ، لدينا بيانات فوضوية ، وليس بيانات حقيقية مجهولة المصدر (هذه هي إحدى الخطوات في المستقبل) ، لذلك تحتاج إلى التدوير برفق وليس الكل في وقت واحد.
قريباً يجب أن نذهب إلى Kubernetes (وبعض المنتجات الجديدة مثل
السوق موجودة بالفعل في البداية) ، بمجرد أن نتوصل إلى خطة الانتقال ونتفق على جميع التفاصيل في البنية التحتية.
سوف أواصل أنا وزملائي الحديث عن كيفية ترتيب جزء من العمل ، لأنه في كل مكان تقريبًا يمكنك المتابعة إلى ما لا نهاية. حسنًا ، يمكنك متابعة برنامج الواقع الخاص بنا (لأن كل شيء يتم بناؤه ويتغير بسرعة) والمراهنة على عدم تثبيته أم لا.