كيفية تنظيم العمل على مكتبة من المكونات المشتركة

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

منذ عام 2015 ، كنت أعمل في Tinkoff في قسم خدمات الأعمال. خلال هذا الوقت ، نما فريقنا من 3 إلى 60 مطورًا ، ونما Tinkoff Business من 3 إلى 50 تطبيق ويب. في المراحل المختلفة من تطورنا ، تعاملنا مع العمل باستخدام الكود الموحد بطرق مختلفة ، وأريد أن أتحدث عن هذا في هذا المقال.

مؤسسة: رخيصة والبهجة

لذلك ، سريع إلى الأمام حتى عام 2015. لدينا ثلاثة تطبيقات ويب فقط: خدمات إدارة النقد ، ومشروع كشوف المرتبات ولوحة التحكم. والعديد من المطورين.

تصنع واجهات التطبيق بنفس النمط ، ويتم نقل الكود العام إلى مكتبة Foundation في مستودع منفصل. لا يتم تجميع المكتبة - وبكلمات صارمة ، لا يوجد شيء يمكن ترجمته هناك ، فكل رمز ES5 لا يتم نشره في npm ، ولكنه متصل باسم الفرع في package.json. تم إنشاء فروع إصدار مؤسسة منفصلة لإصدارات المنتجات لإصلاح الحالة. إذا نسينا الالتزام بفرع المؤسسة ، مع الإصلاح ، اتضح أن المؤسسة قد تغيرت وأن إصدار الإصلاح العاجل لن يقوم بذلك.

هذا ما بدا عليه اتصال المؤسسة في package.json:

"dependencies": { ... "sme-foundation": "git+https://stash_url/sme-foundation.git#develop" ... }, 

المبدأ الرئيسي للمكتبة في هذا الوقت هو الملكية العامة للكود.

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

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

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

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

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



في 2019 ، من غير المرجح أن تفعل الشيء نفسه. ولكن هنا ما يمكن تعلمه من هذه القصة:

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

مع مرور الوقت ، نما فريق تطوير وتنمية Tinkoff Business. عندما كان هناك أكثر من عشرة مشاريع ، توقف هذا النهج عن العمل.

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

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

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

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

كيت واجهة المستخدم ونهج جديد لتنظيم العمل

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

الفريق

لقد اخترنا ثلاثة أشخاص من فرق المنتجات وقلنا: "الآن يصنع هؤلاء الرجال مكونات واجهة المستخدم لمشاريع أخرى."

ماذا قدم الفريق المتفاني؟

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

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

الوثائق

إن فكرة إعادة تصميم منصة العرض التوضيحية الخاصة بنا كانت موجودة منذ فترة طويلة ، وقد جعل تطوير مكتبة جديدة من الممكن.

ثم لم يتم إصدار Storybook for Angular بعد ، لذلك سلكنا طريقنا. إنه للأفضل: إن تنفيذنا لم يحد من خيالنا ، يمكننا أن نفعل كل ما نريده على الإطلاق.

وهنا ما فعلناه:

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

بالطبع ، كل هذا لم يظهر على الفور ، لكنه تطور.

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

لكن تصميم UI Kit نفسه كان شائعًا بالنسبة لجميع منتجات الشركة ، مما يعني أن العشرات من الفرق تحتاج إلى نفس المكونات - من مشاريع الموارد البشرية الداخلية إلى WebOffice ، وهو نظام يعمل لعشرات الآلاف من الموظفين عن بُعد. لذلك ، واجه فريق الحوت مهمة أوسع: لإنشاء منتج داخلي عالي الجودة تستخدمه جميع فرق Angular.

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

لحل هذه الشكوك ، قمنا بتنظيم العمل بشفافية قدر الإمكان.

شفافية

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

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

ما الأدوات التي استخدمناها؟

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

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

سجل التغيير . قدمنا ​​الالتزامات التقليدية وتوليد سجل التغيير منها ، مما سهّل إلى حد كبير الانتقال إلى الإصدارات الجديدة للفرق.



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

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

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

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



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



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

دور الفريق

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

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

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

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

التحديات والتسويات

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

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

لقد وجدنا حلاً وسطًا: إجراء تغييرات عاجلة لا يزيد عن كل إصدار خامس ، أي مرة كل خمسة أسابيع. على سبيل المثال ، قد تستدعي مثل هذه التغييرات في الإصدارات 0.50 و 0.55 و 0.60. لكن الانتقال من 0.50 إلى 0.51 لم يتطلب أي جهد. استمر هذا حتى إصدار مستقر الإصدار 1.0.0. الآن API مستقرة ، ويتم تأجيل جميع التغييرات واسعة النطاق إلى 2.0.0 في المستقبل إلى أجل غير مسمى.

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

النتائج

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

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