دليل التطوير القائم على المكونات

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

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


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

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

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

CDD في تطوير واجهة المستخدم

العمل على بت: إنشاء المكونات وعزلها وإعادة استخدامها والتعاون فيها

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

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

يرتبط CDD بالتصميم الذري ( هنا مادة مفيدة حول هذا الموضوع) وبنهج تطوير أجزاء العميل من مشاريع الويب ، والمعروفة باسم " الواجهة الصغيرة ".

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

حدد إدي عثماني بعض الفوائد الرئيسية لاستخدام CDD. لقد صممها في مجموعة من المبادئ تسمى FIRST .

هذه المبادئ هي:

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

أدوات CDD

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

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

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

itBit: تطوير الأفراد والفريق للمكونات

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

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

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

علاوة على ذلك ، يسمح لك Bit بتعبئة المكونات المستقلة والمغلفة وتنظيم مشاركتها باستخدام الأدوات السحابية . يتيح ذلك للفرق العاملة في المشروعات استخدام جميع المكونات التي تمت مشاركتها. يحتوي مجتمع Bit على حوالي 50،000 مطور. جهودهم خلقت الآلاف من مكونات مفتوحة المصدر متاحة للجميع.


تطوير المشروع باستخدام مكونات مغلفة

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

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


سحابة القدرات في CDD

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

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

and التطوير والبحث في مكونات واجهة المستخدم: Storybook و Styleguidist

يعد StoryBook و Styleguidist بيئات لتطوير عناصر واجهة المستخدم بسرعة باستخدام React. كل من هذه المشاريع هي أدوات رائعة لتسريع تطوير المكونات.

القصص القصيرة

StoryBook هي بيئة لتطوير مكونات واجهة المستخدم بسرعة. يتيح لك العمل مع مكتبة المكونات وعرض الحالات المختلفة للمكونات والمشاركة في التطوير التفاعلي واختبار المكونات.


العمل في StoryBook

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

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

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

الرد على styleguidist

React Styleguidist هو بيئة تطوير مكون. تحتوي هذه البيئة على خادم تطوير يدعم التمهيد السريع. كما أن لديها نظام إدارة أسلوب تفاعلي يعرض propTypes المكونات propTypes ويوفر للمطورين أمثلة قابلة للتحرير لاستخدام المكونات القائمة على ملفات .md.


الرد على styleguidist

يدعم هذا النظام الأساسي JavaScript ES6 و Flow و TypeScript. إنها قادرة ، دون إعدادات إضافية ، على العمل مع تطبيق إنشاء رد فعل. لدى Styleguidist القدرة على إنشاء وثائق المكونات تلقائيًا. هذا يسمح لهذا النظام بلعب دور بوابة الوثائق المرئية للمكونات التي يعمل عليها بعض الفريق.

إذا كنت مهتمًا بمشاريع مثل StoryBook و Styleguidist ، فقد ترغب في إلقاء نظرة على مشروع React Live ، الذي يتم تطويره بواسطة Formidable.

الفرق بين Storybook و Styleguidist

أثناء العمل مع StoryBook ، يكتب مبرمج "القصص" في ملفات JavaScript. عند العمل مع Stuleguidist ، يكتب "أمثلة" في ملفات تخفيض السعر. بينما يُظهر StoryBook تنوعًا واحدًا فقط من المكون في وقت واحد ، يمكن لـ Styleguidist عرض أشكال مختلفة من مكونات مختلفة. يعد StoryBook مفيدًا لتحليل حالات المكونات المختلفة ، كما أن Styleguidist يعد أمرًا رائعًا لإنشاء وثائق المكونات وإظهار قدرات المكونات.

القرارات المعمارية المستخدمة باستخدام منهجية CDD

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

يمكن إنشاء المكونات في إطار التطبيق نفسه (أي ، في نفس المشروع ، مستودعات) ، وفي شكل مشروع منفصل (مستودع) - في شكل مكتبة مكون.

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

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

لماذا إنشاء مكتبة مكونات؟

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


تقاسم عنصر في مشاريع مختلفة

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

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

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

لنفترض أنك قررت إنشاء مكتبة مكونات. إذا كان الأمر كذلك - فنحن نقدم لك بعض النصائح التي ستساعدك في ذلك.

7 مبادئ لتطوير مكتبات نوعية موجهة نحو CDD

1. المعايير. ما هي معايير التطوير التي تلتزم بها عند إنشاء مكتبتك؟ أين تقع المكونات؟ أين تقع الاختبارات؟ ماذا عن الأنماط؟ ما كومة التكنولوجيا التي تستخدمها؟ على سبيل المثال - هل تخطط لاستخدام TypeScript؟ كيف يتم تقسيم المكونات؟ هل يتكون مكون "الجدول" ، على سبيل المثال ، من "صفوف" و "خلايا"؟ هل تتألف اللوحة التي تحتوي على علامات تبويب من علامات تبويب منفصلة (هل يمكن طرح الأسئلة نفسها فيما يتعلق بالكيانات المماثلة الأخرى)؟ أفترض أنك فهمت بالفعل معنى هذه التوصية. من المهم أيضًا تضمين المصممين في عملية صياغة المعايير. سيضمن ذلك أن تكون المكتبة مرنة بدرجة كافية وستلبي متطلبات التصميم التي قد تظهر في المستقبل.
2. التصميم. كيف تخطط لتصميم المكونات؟ هل ستربط كود CSS المقابل بكل مكون؟ إذا كان الأمر كذلك ، فما الذي يحدث عندما يحتاج المصمم إلى تغيير شيء ما فقط لتطبيق منفصل يستخدم مكونًا؟ ربما لتحسين فصل المكونات عن الأنماط التي تستحق استخدام المكتبات التي تقوم بتطبيق CSS في تقنية JS ؟ ربما يستحق البحث عن طريقة أخرى للتصميم؟ على سبيل المثال ، باستخدام Bit ، يمكنك تمييز الموضوعات كمكونات منفصلة. يمكن تطبيق هذه الموضوعات على المكونات التي تنفذ نوعًا من المنطق. يتيح لك هذا إنشاء تطبيقات يتم فيها دمج التصميم والمنطق تمامًا كما يحتاج المطور. فيما يلي مثال على المرونة القصوى للأنظمة المبنية باستخدام مبدأ الوحدة.
3. الاختبار. كيف ستختبر المكونات المدرجة في المكتبة؟ باستخدام Jest and Enzyme؟ يجب التعامل مع اختيار مجموعة جيدة من أدوات اختبار المكون مع كل المسؤولية. سيتيح هذا الأدوات لمساعدتك في تطبيق منهجية CDD. سوف تتداخل الخيارات السيئة للأدوات مع العمل. اختبارات الوحدة جيدة. لكن يجب عليهم التحقق من واجهات برمجة التطبيقات الوظيفية للمكونات ، وليس تفاصيل تنفيذها. لا تقل أهمية اختبارات الدمج والاختبارات من طرف إلى طرف عن أهمية اختبارات الوحدة. منهجية TDD تعمل بشكل جيد عند تطبيقها في المشاريع التي تستخدم CDD.
4. عملية التجميع كود. يجب أن يتم تجميع التعليمات البرمجية. كيف ستنظم عملية بناء الكود لمكتبتك؟ كيف سيتم تنفيذ الإصدارات؟ هل تخطط لنسخ الكود ببساطة من التطبيق ولصقه في المكتبة (ربما يعدله قليلاً)؟ هل ستقوم بتحديد تكوينات التجميع لكل مكون (Lerna) وتطبيق الآليات المناسبة على الكود قبل نشره؟ هل تخطط لاستخدام ، على سبيل المثال ، البت المذكور أعلاه أكثر من مرة لتخصيص عمليات الإنشاء التي تنطبق على جميع المكونات (أو الفردية)؟ إذا قمت بتعقيد عملية التجميع أكثر من اللازم ، فسيصبح من الصعب الانخراط في التطوير ، فسوف تتدهور نمطية المشروع. سيصبح منحنى التعلم المطلوب للمشاركة في التطوير شديد الانحدار.
5. إدارة التعليمات البرمجية. من يملك المكتبة؟ في المؤسسات الكبيرة إلى حد ما ، هناك غالبًا فرق من المطورين الأماميين ، وأحيانًا المهندسين المعماريين. إنهم يقومون بإنشاء منتج يسمى "المكتبة المشتركة". تقوم فرق التطوير الأمامية الأخرى بإنشاء تطبيقات باستخدام مكتبات مماثلة. باستخدام نظام التفاعل هذا ، من المهم جدًا استخدام نظام يتيح لك العثور بسهولة على المكونات الضرورية (Bit ، Storybook). الأهم من ذلك ، ربما ، هي الآلية التي يمكن من خلالها لمستخدمي المكونات اقتراح تحسينات المكون. إذا لم تكن هناك مثل هذه الآليات في المؤسسة ، فلن ترغب فرق المستخدم المكونة في ربط طلباتهم بالمكتبة وانتظار قبول العلاقات العامة الخاصة بهم ، والتي قد لا ينتظرونها. لا حاجة لإجبار المبرمجين على فعل أي شيء. من الضروري إقامة تعاون صحي. إذا كنت لا تسعى لتحقيق ذلك ، فلن يستخدم أي شخص المكتبة. سيقوم المبرمجون ببساطة بنسخ الشفرة ولصقها ، ولن يقوم أحد بأي شيء حيال ذلك. علاوة على ذلك ، سيكون هذا خطأك. إذا كنت تعمل في فريق صغير ، فحدد بوضوح من الذي يدير الكود. حتى إذا لم يكن هناك منخرط في قاعدة الشفرة طوال الوقت ، فحدد بعض المتخصصين الذين سيدعمون هذا الرمز الباقي سيفعل العلاقات العامة - تمامًا كما يفعل في جيثب.
6. العثور على المكونات. لن تحقق المكتبة فائدة كبيرة إذا لم يتمكن المبرمجون من العثور على المكونات التي يحتاجون إليها ، ولا يمكنهم معرفة كيفية عمل هذه المكونات ، ولا يمكنهم استخدامها في التعليمات البرمجية الخاصة بهم. بت لديه القدرات المدمجة التي تساعد المطورين في العثور على المكونات. بالإضافة إلى هذا النظام الأساسي (أو بدلاً منه) ، يمكنك استخدام قدرات StoryBook أو نوع من الحلول الخاصة. يمكن أن توفر منصة Codesandbox بعض الفوائد في حل المشكلات المتعلقة باختيار المكونات والعمل مع الوثائق الخاصة بها.
7. تنظيم التعاون على المكونات. ماذا يحدث عندما يحتاج المطور (ربما من فريق آخر ، أو حتى من بلد آخر) إلى تغيير شيء متعلق بعنصر من مكتبتك؟ هل يحتاج إلى التعمق في إنشاء علاقات عامة لمكتبتك ، وعبور أصابعه ، وانتظر النتائج. بالنسبة للعديد من المطورين ، هذا الأمر معقد للغاية ، ولن يقوموا بذلك حتى لو حاولت التأثير عليهم بطريقة أو بأخرى. سيكون أفضل بكثير إذا كنت تستخدم منصة معينة تبسط التعاون في المشاريع.

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

فوائد فريق CDD

تستفيد الفرق التي تستخدم مبدأ CDD من التطوير المتسارع وزيادة إمكانية إعادة استخدام الشفرة وتحسين TDD وواجهة نظام تصميم متسقة.

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

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

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

تقدم شركات مثل Uber و Airbnb و Shopify وغيرها نهجًا للمكونات.

النتائج

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

أعزائي القراء! هل تستخدم منهجية CDD عند العمل في مشاريعك؟