سمعت العديد من المبرمجين أنه في بعض الأحيان يجب تخصيص الكود لمكتبات منفصلة لإعادة استخدامها. ومع ذلك ، فإن السؤال حول نوع الكود الذي يجب تمييزه ككيان منفصل يربك العديد من المطورين. عند قراءة المقالات / المحادثة حول هذا الموضوع ، عادة ما يتم التذكير بمشكلة التعميم المبكر.
عادة ما يكون للمبرمجين المتمرسين قواعد خاصة بهم ، وبعد ذلك يفهمون ما إذا كان يجب تمييز الشفرة على أنها قابلة لإعادة الاستخدام. على سبيل المثال ، إذا تم استخدام هذا الرمز (أو رمز مشابه جدًا) في ثلاثة أماكن أو أكثر. ومع ذلك ، فإن كل من أتيحت لي الفرصة للتحدث حول هذا الموضوع يوافق على أن مثل هذا الرمز القابل لإعادة الاستخدام يجب أن يكون موجودًا ، وإنشائه نعمة ، وأنه يستحق قضاء وقتك.
أرغب في إثارة موضوع إعادة استخدام الشفرة في سياق إنشاء بنية خدمة موجهة إلى الخدمات الصغيرة.
ما هو رمز قابلة لإعادة الاستخدام؟
الكود القابل لإعادة الاستخدام هو الكود المعزول في كيان منفصل ، يسمى بشكل مختلف بلغات مختلفة - المكتبة ، الحزمة ، التبعية ، إلخ. عادةً ما يتم تخزين هذا الرمز في مستودع منفصل ، وهناك وثائق للاتصال واستخدام هذا الرمز (README.md). بالإضافة إلى ذلك ، قد تتم تغطية الرمز بواسطة الاختبارات ، وقد تكون هناك تعليمات لإجراء تغييرات (CONTRIBUTING.md) ، وقد يتم تكوين CI. تعمل الشارات المختلفة المرتبطة بالوصف على تحسين التمثيل المرئي لنضج كيان معين ، وسيشير عدد النجوم المعينة إلى شعبية هذا الحل. ليس عليك أن تذهب بعيدًا للحصول على أمثلة - فقط افتح صفحة github لأي من الأطر الشائعة بلغتك المفضلة ، على سبيل المثال
vue.js. بشكل عام ، تعتبر طرق تصميم المكتبات عالية الجودة عربة وعربة صغيرة.
الخدمات والخدمات الصغيرة
في هذه المقالة ، الخدمة عبارة عن كيان كامل يقوم بتنفيذ مجموعة محددة من المهام المحددة في مجال مسؤوليته ويوفر واجهة للتفاعل. يمكن أن تكون الخدمة أو الخدمة المجهرية في هذه المقالة من وجهة نظر معمارية مفاهيم متطابقة ، والسؤال هو فقط في نطاق. يمكن أن تتكون الخدمة من مجموعة من الخدمات المصغرة التي تنفذ قطاعها من منطق الأعمال ، أو أن تكون خدمة ميكروية واحدة فخورة.
تفترض البنية الموجهة للخدمة أن كل خدمة متصلة بأقل حد ممكن بالآخرين. ومع ذلك ، لا يتم استبعاد التفاعل بين الخدمات ، ولكن من المفترض فقط أنه ينبغي التقليل منه. لتلقي الطلبات ، تقوم الخدمة عادةً بتنفيذ بعض واجهات برمجة التطبيقات الموحدة. يمكن أن يكون أي شيء - REST أو SOAP أو JSONRPC أو GraphQL حديثًا.
تقليديا ، يمكن تقسيم الخدمات إلى بنية تحتية وبقالة. خدمات المنتجات هي تلك التي تنفذ منطق منتج العميل. على سبيل المثال ، تعمل مع تطبيقات للاتصال به ، أو تنظم الدعم لهذا المنتج طوال دورة حياة العميل بالكامل. تتعلق خدمات البنية الأساسية بالوظائف الأساسية لشركة (أو مشروع) ، على سبيل المثال ، خدمة تحتوي على معلومات العميل ، أو خدمة تخزن معلومات حول أوامر معينة. تشمل خدمات البنية الأساسية أيضًا الخدمات التي تنفذ وظيفة مساعدة ، على سبيل المثال ، خدمة معلومات العميل (إرسال رسائل دفع أو رسائل نصية قصيرة SMS) أو خدمة للتفاعل مع البيانات.
القليل من الخيال
لنفترض أن هناك متجرًا افتراضيًا عبر الإنترنت مبني على بنية موجهة نحو الخدمة. تمكن مطورو هذه المعجزة الهندسية من الاتفاق فيما بينهم وتوصلوا إلى استنتاج مفاده أن جميع خدماتهم ستعمل كواجهات برمجة تطبيقات ، على سبيل المثال ، باستخدام بروتوكول jsonrpc. ومع ذلك ، نظرًا لأن المتجر عبر الإنترنت كبير ، فهو لا يقف صامتًا ويتطور بشكل نشط ، فهناك العديد من مجموعات التطوير هناك ، فليكن أكثر من اثنتين - اثنتان من مجموعات التصميم ، واحدة مصحوبة بما تم كتابته بالفعل. أيضًا ، لتعزيز التأثير ، تكتب جميع الفرق على نفس المجموعة.
بنية متجر افتراضي على الإنترنت:
توفر خدمة واجهة برمجة التطبيقات (API) فقط على الإنترنت إمكانية الوصول إلى جميع أنظمة الواجهة الأمامية - واجهة الويب الخاصة بالمتجر عبر الإنترنت ، بالإضافة إلى تطبيقات الأجهزة المحمولة.
تقوم خدمة معلومات العميل بتخزين المعلومات حول العملاء ، وتعرف كيفية بدء تشغيلها ، والتخويل ، وإصدار المعلومات اللازمة عنها.
تقوم خدمة معلومات المنتج بتخزين المعلومات حول المنتجات وأرصدةها وتوافر الطلب ، كما توفر طرقًا للحصول بسهولة على المعلومات الضرورية.
تعمل خدمة الطلب مع الطلبات. هنا هو منطق تكوين الطلب وتأكيده واختيار نوع الدفع وعنوان التسليم ، إلخ.
يمكن لخدمة معلومات العميل إرسال رسائل PUSH / SMS / البريد الإلكتروني. يعتمد نوع الاتصال ، على سبيل المثال ، على إعدادات عميل معين ، ويمكن للعميل أيضًا تعيين الوقت المرغوب فيه لتلقي الإعلامات.
هذه الخدمات هي بنية أساسية مشروطة ، لأنه بدونها لا يمكن أن يعمل المتجر عبر الإنترنت بهذه الصفة.
من المفترض أن يتم تطوير خدمات العروض الترويجية وتوزيع الخلاصة في المستقبل القريب بواسطة فرق المشروع. هذه الخدمات هي مشروط البقالة.
من الواضح ، على أي حال ، لن تتمكن أي خدمة منتج جديدة من الوجود دون التفاعل مع خدمات البنية التحتية - فمن المرجح أن تتلقى معلومات حول العملاء أو تحتاج إلى إرسال إعلامات.
في المثال الموضح أعلاه ، تكون تفاصيل تنفيذ كل خدمة مخفية عن قصد. لذلك ، على سبيل المثال ، من المحتمل أن يكون لدى خدمة معلومات العميل آلية تأجيل تنفيذ التعليمات البرمجية ، مثل قائمة انتظار التنفيذ ، ويمكن أن يكون لخدمة معلومات المنتج لوحة مسؤول خاصة بها لإدارة البضائع المريحة ، ومن المحتمل أن يحتوي api للأنظمة الأمامية على عدة نسخ متماثلة. علاوة على ذلك ، قد لا تكون البنية الموصوفة هي الأمثل ؛ فهي ببساطة مأخوذة من الرأس.
في سياق البنية المقترحة ، يصبح من الواضح على الفور أن المكتبات الجاهزة ضرورية لتطوير المنتجات بسرعة. لذلك ، من المهم أن يكون لديك تطبيق جاهز لخادم jsonrpc ، وكذلك العميل له ، لأن هذا هو البروتوكول الرئيسي لتنظيم التفاعل بين الخدمات. في هذا المثال أيضًا ، ترتفع مشكلة توثيق واجهة برمجة التطبيقات إلى أقصى إمكاناتها. من الواضح ، لتشكيل الوثائق ، ينبغي أن يكون للفرق أيضًا أداة جاهزة. إذا افترضنا أنه لا تزال هناك أداة جاهزة لإنشاء مخططات smd لخوادم jsonrpc ، فقد تزداد سرعة تطوير خدمات جديدة بشكل أكبر. نتيجةً لذلك ، من الناحية المثالية ، يجب أن يكون هناك مجموعة من المكتبات الجاهزة التي تستخدمها جميع الفرق لأداء مهام نموذجية. يمكن أن تكون هذه المكتبات مملوكة أو مفتوحة المصدر ، الشيء الرئيسي هو أنها تؤدي مهامها بشكل جيد. من الواضح أن الفريق الموجود في المجموعة العامة ويكتب الخدمات باستخدام المكتبات الجاهزة سيكون أكثر فعالية من الفريق الذي يدور باستمرار. بوجود إطار واحد وقاعدة بيانات واحدة للمكتبات المستخدمة في جميع فرق المشروع ، أسمي نظامًا بيئيًا واحدًا.
وماذا عن الشركات الكبيرة؟
في الشركات الكبيرة ، هناك الكثير من خدمات البنية التحتية ، بالإضافة إلى بروتوكولات التفاعل المستخدمة. يمكن أن يصل عدد المكتبات الجاهزة إلى عشرات أو حتى مئات. تسليط الضوء على رمز قابلة لإعادة الاستخدام هنا هو أكثر أهمية.
لقد حدث أن اكتسبت خبرة في شركة توظف حوالي 200 مطور يكتبون بلغات مختلفة - java، c #، php، python، go، js، إلخ. بشكل مدهش ، النظام البيئي المشترك ، في سياق مكدس واحد ، بعيدا عن جميع فرق التطوير لديها واستخدامها. يبدو أن الشيء الواضح - إعداد التعليمات البرمجية القابلة لإعادة الاستخدام وتهيئتها بشكل صحيح واستخدامها - بعيد عن الوضوح. بالطبع ، فرق التطوير تحل مشاكلها. يستخدم شخص ما قالب خدمة - مجموعة من التعليمات البرمجية التي تشكل جوهر كل خدمة جديدة ، يتم من خلالها طرح كل ما هو غير ضروري وإضافته الضرورية.
تستخدم فرق التطوير الأخرى دراجاتها الخاصة ، وانسخها والصقها من مشروع إلى آخر ، ولا تهتم بتوثيقها واختبارها. بشكل عام ، هناك الكثير من الخلاف في الأدوات والأساليب المستخدمة داخل نفس المجموعة في شركة واحدة. علاوة على ذلك ، تقع جغرافيا في مدينة واحدة.
فوائد النظام البيئي واحد
إن تشكيل نظام بيئي واحد يمكن أن يحل العديد من الصعوبات ، ولديه إمكانات هائلة لزيادة الإنتاجية لشركة كبيرة. في الواقع ، هذه الممارسة مأخوذة من مجتمع المصادر المفتوحة - حيث تبقى أفضل الحلول في مجالها وأكثرها شعبية. الآن يكفي فتح أي مدير تبعية وفاجأ فقط بوفرة الحلول المقترحة. ولكن مثل هذا النهج يمكن تنفيذه داخل الشركة. مزايا هذا النهج عند تنفيذ خدمة جديدة هي كما يلي:
- درجة عالية من الاستقرار - استخدام المكتبات المغطاة بالاختبار والموثقة جيدًا يزيد من استقرار الخدمة ككل ؛
- سهولة تناوب الزملاء بين الفرق - إذا كانت جميع الفرق داخل نظام بيئي واحد ، فعند الانتقال من فريق إلى آخر ، فلن يضطر المطور لقضاء الكثير من الوقت للتعرف على الأدوات المستخدمة ، لأنه يعرفها بالفعل ؛
- التركيز على منطق الأعمال - في الواقع ، يتلخص تطوير خدمة جديدة في الحاجة إلى تشديد التبعيات الضرورية التي تحل جميع مهام البنية التحتية وكتابة منطق الأعمال فقط ؛
- تسريع التنمية - ليست هناك حاجة إلى دورة ، كل شيء جاهز ، باستثناء منطق الأعمال ؛
- تبسيط الاختبار - يجب اختبار منطق العمل فقط ، لأنه تم بالفعل اختبار المكتبات ؛
يطير في مرهم
من الواضح أنه من أجل تحقيق هذا النهج ، يجب اتباع بعض الممارسات ، وهي تطوير المكتبات باستخدام الإصدارات الدلالية ، والاعتناء بالوثائق والاختبارات ، وتهيئة ci. هذا نوع من النضج ليس فقط لفريق التطوير ، ولكن أيضًا للمطورين في الشركة ككل.
PS
والنهج الموجه نحو الحزمة هو فقط لأن الكود القابل لإعادة الاستخدام في مجموعتي يسمى الحزمة. حسنا ، هذا يبدو مضحكا. في الآونة الأخيرة ، أجريت حوارًا مع أحد زملائي دفعني إلى كتابة هذا المقال:
- زميل: أنت تتحول إلى أمين الصندوق في خمسة
- أنا: معنى؟)
- زميل: قريبا سوف تسأل "هل تحتاج إلى حزمة؟"
- أنا: يرجى فتح الفكر. انا لا افهم
- زميل: حسنًا ، للمرة الألف لديك حزمة جاهزة لحل مشكلتي
الشيء هو أنه في مجتمعنا من المطورين داخل الشركة هناك حوالي 20 قطعة من الحزم الجاهزة ، ويترجم إنشاء خدمة جديدة إلى سحب التبعيات اللازمة ، وكذلك كتابة منطق الأعمال. تكلفة الربط من حيث كتابة التعليمات البرمجية تكاد تكون لاغية.