ننشر اليوم الجزء الثاني من ترجمة المقالة ، والذي يحتوي على مجموعة من التوصيات لمطوري Angular. في
الجزء السابق تم تقديم 11 نصيحة ، سننظر في نفس المبلغ.
1. مكونات صغيرة مناسبة لإعادة الاستخدام
البحث عن أجزاء في المكونات التي يمكن إعادة استخدامها وإنشاء مكونات جديدة بناءً عليها. اجعل المكونات غبية قدر الإمكان ، لأن ذلك سيسمح باستخدامها في المزيد من السيناريوهات. إن المكون "الغبي" هو المكون الذي لا يحتوي على أي منطق محدد ، يعتمد تشغيله فقط على بيانات الإدخال المقدمة إليه.
عند العمل مع المكونات ، يجب الالتزام بالقاعدة العامة التالية: يجب أن يكون المكون الأكثر تداخلًا في شجرة المكونات هو الأكثر "غباء" أيضًا.
▍ تفسيرات
تقلل إعادة استخدام المكونات من تكرار التعليمات البرمجية ، مما يبسط دعم المشروع والتغييرات.
تكون المكونات الغبية أبسط من المكونات الأخرى ، لذا من غير المحتمل أن تظهر أخطاء فيها. استخدام مثل هذه المكونات يجعل المطور يفكر بشكل أفضل في واجهة برمجة التطبيقات المفتوحة للمكون ويساعد في حل المشكلات.
2. حول المهام التي تم حلها بواسطة المكونات
كلما أمكن ، تجنب التواجد في مكونات المنطق بخلاف تلك المستخدمة لتصور البيانات.
▍ تفسيرات
تم تصميم المكونات كأدوات لتقديم المعلومات وللتحكم في كيفية عمل الواجهات. يجب إزالة أي منطق عمل من المكونات ووضعه ، كلما أمكن ، في طرق أو خدمات منفصلة ، وبالتالي فصل منطق الأعمال عن منطق عرض المعلومات.
عادةً ما يكون منطق الأعمال ، عند تقديمه كخدمات منفصلة ، أسهل في اختبار الوحدة. مع هذا النهج ، يمكن إعادة استخدامه من قبل مكونات مختلفة تحتاج إلى نفس القدرات.
3. حول الأساليب الرائعة
إذا تبين أن رمز الطريقة طويل جدًا ، فهذا يشير عادةً إلى أن مثل هذه الوحدة تحل الكثير من المشاكل. ربما تحل مثل هذه الطريقة ككيان مستقل مشكلة واحدة فقط ، ولكن قد يكون هناك رمز داخلها يؤدي إلى عدة عمليات مختلفة. يمكن إصدار مثل هذا الرمز في شكل طرق منفصلة ، كل منها ، مرة أخرى ، يجب أن يحل مشكلة واحدة ، وبعد ذلك يجب عليك استخدام هذه الأساليب بدلاً من أجزاء التعليمات البرمجية المقابلة في الطريقة الأصلية.
▍ تفسيرات
من الصعب قراءة وفهم وصيانة طرق الكود الطويل. بالإضافة إلى ذلك ، فإن هذه الأساليب عرضة للأخطاء ، حيث أن تغيير أحدها يمكن أن يؤثر على العديد من الآليات الأخرى للطريقة. يعني الرمز الطويل إعادة هيكلة أكثر تعقيدًا ، وهذه العملية مهمة جدًا في أي تطبيق.
في هذا الصدد ، يمكننا أن نذكر مثل هذا المؤشر مثل
التعقيد السيكلومي للبرنامج . هناك
قواعد TSLint لتحديد التعقيد السيكلومي التي يمكن استخدامها في مشروع لتجنب الأخطاء التي قد تظهر في التعليمات البرمجية المعقدة للغاية. بمساعدتهم ، يمكنك تقييم جودة الرمز ومنع المشاكل المحتملة بدعمه.
4. مبدأ جاف
DRY (لا تكرر نفسك ، لا تكرر) هو مبدأ يجب اتباعه للتأكد من عدم وجود نسخ من أجزاء التعليمات البرمجية نفسها في أماكن مختلفة من المشروع. يجب أن تكون أجزاء التعليمات البرمجية هذه في شكل كيانات مستقلة ، وأساليب ، على سبيل المثال ، واستخدام مكالماتها حيث تم استخدام التعليمات البرمجية المتكررة من قبل.
▍ تفسيرات
إذا تم استخدام نفس الرمز في أماكن مختلفة من التطبيق ، فهذا يؤدي إلى حقيقة أنه إذا كنت بحاجة إلى إجراء تغييرات على هذا الرمز ، فسيتعين عليك القيام بذلك في العديد من الأماكن. ونتيجة لذلك ، سيكون الحفاظ على البرنامج أكثر صعوبة ، وسيكون عرضة للأخطاء المتعلقة ، على سبيل المثال ، بحقيقة أنه لم يتم تحرير جميع أجزاء نفس الرمز بشكل صحيح. هذا ، بالإضافة إلى ذلك ، يزيد من الوقت اللازم لإجراء تغييرات على التعليمات البرمجية واختبارها.
إذا واجهت شيئًا مشابهًا - قم بتهيئة رمز التكرار ككيان مستقل واستخدمه بدلاً من تكرار الأجزاء. سيؤدي هذا إلى حقيقة أنه لإجراء التغييرات ، تحتاج إلى إجراء تعديلات في مكان واحد فقط ، وأثناء الاختبار ، ستحتاج إلى اختبار جزء واحد فقط من التعليمات البرمجية وليس العديد. بالإضافة إلى ذلك ، كلما كان الرمز أقل تكرارًا في التطبيق ، كلما تم تنزيله بشكل أسرع من قبل المستخدمين.
5. آليات التخزين المؤقت
عند إجراء مكالمات إلى واجهات برمجة تطبيقات مختلفة ، ستلاحظ أن الإجابات من بعضها لم تتغير أبدًا. في مثل هذه الحالات ، يمكنك إضافة أدوات تخزين البيانات مؤقتًا إلى البرنامج وتخزين ما تعيده واجهات برمجة التطبيقات المماثلة في ذاكرة التخزين المؤقت. عند تنفيذ الطلب التالي ، يمكنك الانتقال إلى ذاكرة التخزين المؤقت ، وإذا كان يحتوي بالفعل على ما يحتاجه ، فيمكنك استخدام هذه البيانات ، وإذا لم يكن بحاجة إليها ، فقم بتنفيذ الطلب الحقيقي ووضع استجابة له في ذاكرة التخزين المؤقت.
إذا تغيرت البيانات الواردة من واجهات برمجة تطبيقات معينة في بعض الفترات ، يمكنك تخزينها مؤقتًا لفترة معينة. ونتيجة لذلك ، عند تقديم طلب إلى واجهات برمجة التطبيقات هذه ، سيكون من الممكن تحديد مكان الحصول على البيانات اللازمة.
▍ تفسيرات
تتيح لك آلية التخزين المؤقت تجنب إجراء طلبات API غير ضرورية. إذا تم إجراء استدعاءات التطبيق لواجهة برمجة التطبيقات (API) فقط عند الضرورة القصوى ، ولم يتم طلب البيانات التي تلقاها التطبيق بالفعل مرة أخرى ، يتحسن أداء الحل ، خاصة لأنه لا يتعين عليه الانتظار باستمرار للحصول على إجابات من بعض خدمات الشبكة. هذا النهج يسمح ، بالإضافة إلى ذلك ، بحفظ حركة المرور ، حيث لا يتم تنزيل نفس البيانات مرارا وتكرارا.
6. المنطق في الأنماط
إذا كانت القوالب الخاصة بك تحتوي على بعض المنطق على الأقل ، حتى لو كان
&& تعبير بسيط ، فيجب استخراج هذا المنطق ووضعه في المكون المناسب.
▍ تفسيرات
إذا كان للقالب منطق ، فهذا يعني أنه لا يمكن إخضاع هذا القالب لاختبار الوحدة ، وبالتالي ، يزداد احتمال حدوث أخطاء عند تغيير رمز القالب.
إلى
// <p *ngIf="role==='developer'"> Status: Developer </p> // public ngOnInit (): void { this.role = 'developer'; }
fter بعد ذلك
// القالب
<p * ngIf = "showDeveloperStatus"> الحالة: المطور
// public ngOnInit (): void { this.role = 'developer'; this.showDeveloperStatus = true; }
7. العمل مع الخطوط
إذا كان لديك متغير من نوع السلسلة يمكن أن يحتوي على قيم من مجموعة محدودة ، فبدلاً من تعريفها كسلسلة عادية ، حدد قائمة بالقيم المحتملة عند الإعلان عنها.
▍ تفسيرات
يسمح الوصف المتعمق لنوع المتغير بتبسيط اكتشاف الأخطاء وإزالتها ، حيث يتم اكتشافها باستخدام هذا النهج في مرحلة تجميع البرنامج وليس في وقت التشغيل.
إلى
private myStringValue: string; if (itShouldHaveFirstValue) { myStringValue = 'First'; } else { myStringValue = 'Second' }
fter بعد ذلك
private myStringValue: 'First' | 'Second'; if (itShouldHaveFirstValue) { myStringValue = 'First'; } else { myStringValue = 'Other' } // Type '"Other"' is not assignable to type '"First" | "Second"' (property) AppComponent.myValue: "First" | "Second"
8. حول إدارة حالة التطبيق
ضع في اعتبارك استخدام
@ ngrx / store للتحكم في حالة تطبيقك و
@ ngrx / تأثيرات لتنفيذ الآثار الجانبية. يتم وصف تغييرات الحالة من خلال الإجراءات ويتم تنفيذها من خلال وظائف نقية تسمى المخفضات.
▍ تفسيرات
@ ngrx / store يعزل المنطق المرتبط بحالة التطبيق في مكان واحد ويجعله موحدًا عبر المشروع بأكمله. هنا ، بالإضافة إلى ذلك ، هناك آلية للتذكر تعمل عند العمل مع التخزين ، مما يحسن أداء التطبيق. تؤدي آلية @ ngrx / store ، إلى جانب استراتيجية Angular للكشف عن التغيير ، إلى تطبيقات أسرع.
9. حول ثبات حالة التطبيق
عند استخدام @ ngrx / store ، فكر في استخدام
مكتبة ngrx-store-freeze لتجعل حالة التطبيق ثابتة. تمنع هذه المكتبة طفرات الدولة عن طريق طرح الاستثناءات. هذا يتجنب التغييرات العرضية في حالة التطبيق التي تؤدي إلى عواقب غير متوقعة.
▍ تفسيرات
يؤدي تغيير حالة التطبيق في المكونات إلى حقيقة أن سلوك التطبيق يتغير اعتمادًا على الترتيب الذي يتم فيه تحميل المكونات. هذا ينتهك النموذج العقلي لقالب redux. ونتيجة لذلك ، يمكن إعادة تعريف التغييرات إذا كانت حالة المستودع تتغير والعمل اللاحق معها تستخدم بالفعل الحالة الجديدة. هنا نطبق مبدأ الفصل بين المسؤوليات ، والذي تكون المكونات على مستوى العرض التقديمي ويجب ألا يعرفوا كيف يغيرون حالة التطبيق.
10. أدوات اختبار التطبيق
استخدم أدوات متخصصة لاختبار التطبيقات. من بينهم
Jest و
Karma .
▍ تفسيرات
Jest هو إطار تطبيق لاختبار الوحدة تم تطويره بواسطة Facebook. وهو يدعم آليات تنفيذ الاختبار المتوازي ، مما يسرع العمل. نظرًا لحقيقة أنه قادر على مراعاة التغييرات في قاعدة الرمز ، في جلسة الاختبار التالية ، يتم إجراء الاختبارات المتعلقة بالكود الذي تم تغييره فقط. هذا يحسن القدرة على تحليل نتائج الاختبار. بالإضافة إلى ذلك ، يوفر Jest مقاييس تغطية الاختبار ويدعمه محرر VS Code و WebStorm IDE.
تم تطوير عداء اختبار Karma بواسطة فريق AngularJS. لإجراء الاختبارات ، يحتاج إلى متصفح حقيقي و DOM. تتيح لك Karma تشغيل الاختبارات في متصفحات مختلفة. Jest ، بدوره ، لا يحتاج ، على سبيل المثال ، متصفح Chrome بدون واجهة مستخدم أو phantom.js ، نظرًا لأن النظام الأساسي Node.js فقط مطلوب لتشغيل هذا الإطار.
11. تقديم الخادم
إذا لم تكن قد استخدمت تقنية
Angular Universal حتى الآن ، فقد حان الوقت لتجربتها. يسمح لك بتنظيم التقديم من جانب الخادم للتطبيقات الزاويّة. ونتيجة لذلك ، يتم إرسال صفحات HTML الثابتة والمقدمة مسبقًا إلى المستخدم. وهذا يجعل التطبيقات سريعة بشكل لا يصدق ، حيث تظهر محتوياتها في المتصفحات على الفور تقريبًا نظرًا لأن المتصفح لا يحتاج إلى تنزيل حزم JS وتوزيعها وإضاعة الوقت لضمان تشغيل الآليات الزاويّة.
بالإضافة إلى ذلك ، تتمتع تطبيقات Angular المقدمة على الخادم بمزايا على التطبيقات العادية من حيث الرؤساء التنفيذيين. يقوم Angular Universal بإنشاء صفحات ثابتة ، وهذا يجعل من السهل على محركات البحث فهرسة هذه الصفحات ، حيث لا يتعين عليها تنفيذ تعليمات JavaScript البرمجية لتشكيل الصفحات.
▍ تفسيرات
يمكن أن يؤدي استخدام Angular Universal إلى تحسين أداء التطبيق بشكل كبير. قمنا مؤخرًا بتحديث تطبيقنا بإضافة إمكانات عرض الخادم إليه. وقد أدى ذلك إلى تقليل وقت تحميل الموقع من بضع ثوان إلى عشرات المللي ثانية.
بالإضافة إلى ذلك ، وبفضل هذا النهج ، يتم عرض الصفحات بشكل صحيح في مناطق معاينة المحتوى المستخدمة على الشبكات الاجتماعية. الوقت لأول عرض للصفحة ذات معنى (الطلاء ذو المعنى الأول) قصير جدًا ، مما يحفظ المستخدمين من الانتظار غير الضروري.
الملخص
تطوير التطبيقات هو المسار الذي يجد المبرمج من خلاله باستمرار فرصًا لتحسين ما يبتكره. أنت ، باتباع هذا المسار ، قد تستفيد أيضًا من النصائح المقدمة هنا لتحسين تطبيقات Angular. نحن على يقين من أن تطبيقهم المتناسق سيفيد أي فريق تطوير ، وأن النتيجة الناتجة ستجذب المستخدمين ، لأنهم ، من وجهة نظرهم ، سيؤديون إلى حقيقة أنهم سيعملون مع تطبيقات أكثر استقرارًا وإنتاجية.
أعزائي القراء! إذا كان بإمكانك مشاركة نصائح مفيدة لتحسين التطبيقات مع مجتمع المطورين Angular ، فالرجاء القيام بذلك.
