كيفية تنظيم المشاريع الزاوي؟ المقالة التالية تجمع وتشارك 5 نصائح عملية لإدارة مشاريع Angular وآمل أن تكون مفيدة للجميع! 
مدخل الواجهة الأمامية (vue) إلى دورة الإتقان: أدخل التعلم
مع إصدار ميزات جديدة، تصبح Web apps أكبر وأكبر. في رحلة DevOps الخاصة بالشركة، يحدث هذا النوع من تغيير الإصدار كل يوم. [البرامج التعليمية الموصى بها: "البرنامج التعليمي الزاوي"]
في دورة الإصدار السريع هذه، يمكن أن تصبح التعليمات البرمجية غير عملية بسرعة. خاصة المشاريع التي تم تطويرها بناءً على JavaScript ، مثل NextJS أو Angular.
فيما يلي أفضل 5 ممارسات لدينا لإدارة مشاريع Angular لتحقيق أقصى قدر من سهولة القراءة وقابلية الصيانة وقابلية التوسع.
العديد من نوى التطبيق الفردي عبارة عن قواعد تعليمات برمجية ذات فئات متضخمة. وبحكم طبيعتها، يصعب الحفاظ على هذه البرامج المتضخمة. إنها هشة بمعنى أن تغيير سطر واحد من التعليمات البرمجية يمكن أن يكون له آثار كارثية على البرنامج بأكمله. مبدأ المسؤولية الفردية يمكن أن يمنع هذه المشاكل.
مبدأ المسؤولية الفردية يعني أن المكون له وظيفة واحدة فقط.
ينتج عن إنشاء التطبيقات باستخدام هذا الأسلوب إطار عمل معياري يتم فيه ربط التطبيق معًا من خلال كتل التعليمات البرمجية هذه.
يمكن أن يؤدي استخدام هذا الأسلوب إلى جعل البرامج أكثر قابلية للقراءة والصيانة. ويمكنه أيضًا تحديد موقع الوظائف المحددة في التطبيق بسهولة.
للتأكد من أن الكود الخاص بك يلبي هذا المتطلب، اسأل نفسك هذا السؤال:这代码是干什么的？ إذا كانت إجابتك تحتوي على الكلمة الأساسية and ، فأنت بحاجة إلى إعادة صياغة الكود الخاص بك إلى رمز مسؤولية واحدة.
يعد إنشاء تطبيقات Angular وتوسيعها بمثابة تمرين مستمر. مع مرور الوقت، تنظيم مشاريعك باستخدام مبدأ المسؤولية الواحدة سيجعل تطبيقاتك نظيفة، وقابلة للقراءة، وقابلة للصيانة.
الوحدات في Angular هي تطبيق لمبدأ واحد. في Angular ، تمثل كل وحدة وظيفة منفصلة ومستقلة.
يوفر Angular العديد من وحدات الكتابة لتحديد كيفية تجميعها أو تنظيمها بشكل منطقي.
جوهر
الوحدة Core هي وحدة NgModule تُستخدم لإنشاء مثيل للتطبيق وتحميل الوظائف الأساسية للاستخدام العالمي.
لذلك، يجب تنفيذ أي خدمة مفردة في الوحدة الأساسية. يعد الرأس أو التذييل أو شريط التنقل وحدات من هذا النوع.
يجب تنفيذ جميع الخدمات (الخدمات الفردية) التي تحتوي على مثيل واحد فقط لكل تطبيق في الوحدة الأساسية. على سبيل المثال، خدمة المصادقة أو خدمة المستخدم.
ميزة
تمثل الوحدات الوظيفية الكود الذي يبني وظائف التطبيق. على سبيل المثال، في تطبيق التسوق عبر الإنترنت، سيكون لدينا وظيفة إضافة عناصر إلى عربة التسوق ووحدة منفصلة للدفع.
مشترك
تتكون الوحدات المشتركة من وحدات يمكن دمجها لإنشاء وظائف جديدة. على سبيل المثال، يمكن استخدام وظيفة البحث لوظائف متعددة في النظام الأساسي.
إن هيكلة التعليمات البرمجية الخاصة بك بهذه الطريقة تجعل تحديد موقع الأشياء أسهل وتزيد من فرص إعادة استخدام التعليمات البرمجية.
يمكن أن تصبح ملفات الأنماط غير منظمة بسرعة إذا لم تتبع بنية مشتركة. نمط أفضل الممارسات العامة 7-1 ، والذي يستخدم 7 مجلدات وملف 1 ، كما هو موضح أدناه:
التطبيق - المجلد الرئيسي للمشروع
الملخص - قسم الملخص، الذي يحتوي على جميع المتغيرات والخلطات والمكونات المشابهة
الأساسية - تحتوي على التخطيط وإعادة التعيين والتعليمات البرمجية النموذجية للموقع بأكمله
المكونات - تحتوي على أنماط لجميع المكونات التي سيتم إنشاؤها لموقع ويب، مثل الأزرار وعلامات التبويب والنماذج
التخطيط - يحتوي على الملفات المطلوبة لتحديد تخطيط الموقع، مثل الرؤوس والتذييلات
الصفحات - تحتوي على أنماط لكل صفحة محددة
البائعون - هذا المجلد الاختياري مناسب لإطار عمل bootstrap الذي يستخدمه المشروع، مثل bootstrap
قم بإنشاء ملف all.scss جديد في كل مجلد يحتوي على كافة المهام الخاصة بهذا المجلد المعين.
تم تصميم العديد من الخدمات للتشغيل عالميًا. وبعد ذلك، في بعض الحالات، يتطلب المكون خدمة. توصي ممارسات مكونات الترميز التقليدية بمبدأ المسؤولية الفردية.
وبموجب هذا النهج، تتم كتابة الخدمات والمكونات كمشاريع منفصلة.
ولكن ماذا يحدث عندما تفكر في إزالة مكونات هذه الخدمات؟ ما ينتهي بك الأمر هو رمز ميت، مما يجعل المستودع أكثر ازدحامًا. في هذه الحالة، أفضل الممارسات هي وضع الخدمة داخل المكون.
بهذه الطريقة، تصبح صيانة المكونات والخدمات أسهل.
يعد التنقل في بنية الملفات المتداخلة أسهل من نظام الملفات المسطح الذي يضع جميع ملفات التعليمات البرمجية في دليل واحد.
ومع ذلك، مع اقتراب المشروع، يمكن أن تصبح بنية ملف المشروع معقدة للغاية. على الرغم من أن هذا يجعل تحديد موقع الكود أسهل، إلا أنه يمثل تحديات عند كتابة بيانات الاستيراد.
عندما يبدأ هيكل الدليل في النمو إلى ما بعد ثلاثة أو أربعة مستويات، يمكن أن تصبح بيانات import طويلة جدًا ويصعب قراءتها.
لحل هذه المشكلة، يمكننا تكوين الاسم المستعار للمسار في ملف tsconfig.json. يوجد في هذا الملف مصفوفة اسمها compilerOptions . هذا هو الاسم المستعار للمسار الذي تقوم بتكوينه في تطبيقك.
عندما يتم تجميع التعليمات البرمجية، يتم استبدال الأسماء المستعارة للمسار المحددة في هذه المصفوفة بمسارات حقيقية. قيمة كل مسار هي كائن ذو قيمة أساسية يحتوي على المسار الفعلي والاسم المستعار.
يعد إنشاء تطبيقات Angular وتوسيعها بمثابة تمرين مستمر.