التطبيق كحزمة واحدة

تتمثل طريقة تحويل تطبيقنا إلى وحدات في تحويل التطبيق بأكمله إلى حزمة.

إنشاء الهيكل

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

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

config.paths.paths.add 'app/packages'، glob: '*/{*،*/concerns}'، تحميل_حريص:صحيح

يعمل التطبيق الآن ولكن لا يمكنه العثور على طرق العرض، لذلك نحتاج إلى إضافة سطر آخر من التكوين إلى التطبيق_كونترولر.rb

إلحاق_عرض_المسار(Dir.glob(القضبان.root.jo.join('app/packages/*/*/views')))

إنشاء الحزم

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

فرض_الخصوصية: خطأ
فرض_التبعية: صواب

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

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

التحقق من صحة نظام الحزمة

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

 سيؤدي ذلك إلى التحقق من بنية المجلد, تكوين الحزمة، وذاكرة التخزين المؤقت للمسار التحميل التلقائي.

في الوقت الحالي، تطبيقنا غير صالح وعلينا إصلاح مسارات التحميل فيPackwerk.yml. للقيام بذلك، علينا فقط إضافة المسارات المفقودة.

# packwerk.yml

تحميل_المسارات:
.
.
.

# المستخدمون
- التطبيق/الحزم/المستخدمون/المتحكمون
- التطبيق/حزم/المستخدمون/النماذج
- التطبيق/packages/المستخدمون/المستخدمون/الحزمة.yml
- التطبيق/packages/المستخدمون/المستخدمون/المشاهدات

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

# deprecated_references.yml

.
.
.

app/packages/repos:
  ":::Repo":
    انتهاكات
    - التبعية
    الملفات:
    - app/packages/users/models/user.rb

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

- التطبيق/الحزم/المستندات  - الحزمة التي يكون فيها الانتهاك الثابت
تم العثور عليها.

- :: الريبو  - المسار إلى الملف الذي يحتوي على الثابت المنتهك.

- التبعية  - نوع من الانتهاكات، إما التبعية أو الخصوصية.

- التطبيق/الحزم/المستخدمون/النماذج/المستخدم.rb  - المسار إلى الملف الذي يحتوي على الثابت المنتهك.

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

تصور التبعية

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

تشغيل أشعل النار بوكي: توليد سننشئ ملفًا باسم باكويرك.png حيث يمكننا تصور الرسم البياني الأول للتبعيات.

مع تحديد جميع الحزم سيبدو الرسم البياني بهذا الشكل.

التبعيات موجودة بالفعل ولكن هذا لا يعني أنها مقبولة من قبل باكويرك. لـ
قبول التبعية، نحتاج إلى إضافة تكوين التبعيات إلى الحزمة.yml
في كل حزمة. سنركز على بناة_البريد بما أنها حزمة بدون تبعية دائرية. من الجدير بالذكر أن باكويرك لن تسمح لنا بقبول التبعيات الدائرية.

# التطبيق/packages/mail_builders/package.yml

``روبي
فرض_الخصوصية: خطأ
فرض_التبعيات: صحيح
التبعيات:
- التطبيق/الحزم/المستندات
- تطبيق/حزم/مشكلات
- التطبيق/الحزم/المستندات

بعد إضافة هذا التكوين, بوكي ستلون التبعيات المقبولة باستخدام اللون الأخضر.

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

روبي على قضبان القضبان النمذجة مع Packwerk قبول التبعيات سيظل تطبيقنا يعمل كما كان من قبل، ولكن الآن لدينا المزيد من
المعلومات لاتخاذ القرارات وإعادة الهيكلة.

إزالة التبعيات الدائرية

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

- لا تفعل شيئاً,

- قبول التبعيات، دمج الحزم,

- الانتقال الكود بين الحزم,

- تكرار وظيفة, 

- إجراء حقن التبعية أو حقن التبعية مع الكتابة.

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

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

1. انقل جميع ملفات_التطبيق ومجلداته من التطبيق إلى التطبيق/الحزم/القضبان.
2. إنشاءالحزمة.yml للحزمة بنفس تكوين الحزم السابقة.
3. أضف جميع مسارات الملفات الجديدة إلى Packwerk.yml.
4. إضافة التطبيق/الحزم/القضبان كتبعية من بقية الحزم.

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

إزالة التبعيات من الحزمة الجذر

الآن يبدو الرسم البياني لدينا أفضل بكثير سيكون رائعًا إذا تمكنا من إزالة جميع التبعيات من الحزمة الجذر. إذا تحققنا من deprecated_references.yml المهملة في الحزمة الجذر، سنلاحظ أن معظمها من الاختبار , ليب/مهام , ديسيبل و التكوين
مجلد. من أجل حل هذه التبعيات، سنقوم بإنشاء مجلد اختبار داخل كل حزمة. وجود شيء مثل التطبيق/الحزم/المستخدمون/الاختبار. بعد ذلك، سنستبعد ليب/مهام , ديسيبل و التكوينمن بين مجلدات أخرى من باكويرك التحليل لأن هذه التبعيات ليست مهمة حقًا في تحليلنا وليس لدينا طريقة سهلة لحلها. سنضيف ما يلي إلى Packwerk.yml.

استبعاد:
- "{bin,node_modules,node_modules,script,tmp,vendor,lib,db,config,perf_scripts}/**/*"
- "lib/tasks/**/*.rake"

بعد نقل جميع الاختبارات من الحزمة الجذرية واستبعاد المجلدات من التحليل سيكون لدينا رسم بياني جديد بدون تبعيات الجذر.

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

يمكنك العثور على النتيجة النهائية للمشروع هنا.

الخطوة التالية

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

فرض_الخصوصية: صحيح
فرض_الاعتمادات: صحيح
المسار_العام: my/custom/path/مخصص/

الاستنتاجات

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

المصادر

1. النمذجة التدريجية لـ Ruby on Rails - Stephan Hagemann
2. فرض النمطية في تطبيقات Rails باستخدام Packwerk
3. باكويرك جيثب
4. الرمز المصدر للمادة

قراءة المزيد

GraphQL روبي. ماذا عن الأداء؟

السكك الحديدية ووسائل النقل الأخرى

تطوير القضبان باستخدام TMUX و Vim و Fzf + Ripgrep