1. الاتساق
الاتساق مشكلة شائعة جدا في التنمية. كل شخص لديه ما يفضله. إذا لم يكن لدى الشركة نمط رمز واحد ، أعتقد أن المطورين قد يكونون عالقين في جدال كل يوم. لماذا باسكال كيس؟ لماذا الكباب؟ لماذا الثعبان؟ لماذا هذا؟ لماذا ذلك؟ وسيكون الرمز غير قابل للقراءة تمامًا.
فيما يلي اصطلاح التسمية المفضل لدي:
- camelCase لاسم المتغير والوظيفة. على سبيل المثال: let firstName = "Oyster"
- الاستخدام هو وله قيمة منطقية. على سبيل المثال: isDark ، isBlur ، isDirty ، hasFooter ، إلخ.
- عندما تقوم إحدى الوظائف بإرجاع شيء ما ، فابدأ دائمًا بـ get. على سبيل المثال: getFullName () ، getImages ()
- UPPER_SNAKE_CASE لكائن ثابت أو ثابت. على سبيل المثال: API_URL ، TIMEZONE
- بادئة دالة بمقبض أو تشغيل (اختر أحدهما) لمعالج الأحداث. على سبيل المثال: handleFormSubmitted، onFormSubmitted
- بادئة دالة خاصة أو متغير خاص يستخدم فقط في نفس الملف مع _. على سبيل المثال: _fooBar ، _prefix
2. رمز زائدة عن الحاجة
لقد رأيت الكثير من التعليمات البرمجية الزائدة التي كتبها مطورون مختلفون بغض النظر عن الأقدمية
فمثلا:
// bad
const getFullName = (firstName, lastName) => {
let fullName = `${firstName} ${lastName}`
return fullName;
}// good
const getFullName = (firstName, lastName) => {
return `${firstName} ${lastName}`;
}
سؤال: لماذا نعلن عن متغير إضافي ولا نستخدمه غير العودة؟
// bad
const isMoreThanFourty = foo > 40 ? true : false;
// bad
const isMoreThanFourty = foo < 40 ? false : true;
// good
const isMoreThanFourty = foo > 40;// bad
if (value === true) {}
// good
if (value) {}
سيعيد عامل المقارنة قيمة منطقية بها صواب أو خطأ. مما يعني أنه لا فائدة من إرجاع صح أو خطأ يدويًا.
3. رمز مكرر
هناك مبدأ برمجة واحد يسمى DRY (لا تكرر نفسك). عندما تقوم بنسخ اللصق من مكان إلى آخر ، فهذا يعني أنك تقوم بتكرار الرمز.
ومع ذلك ، قد ينتهك المطورون بسهولة مبدأ آخر يسمى YAGNI (لن تحتاج إليه) عند كتابة كود DRY. يجب ألا تكتب شيئًا تعتقد أنك قد تحتاجه في المستقبل. تعد إضافة المنطق أسهل مقارنة بحذف المنطق في المستقبل. عادة ما ينتهي المنطق الذي تعتقد أنك بحاجة إليه بشكل مختلف. نعم ، قد يكون المنطق هو ما يريده الفريق قليلاً ، لكن ليس بالضبط ، في النهاية ، ما زلت بحاجة إلى بذل الجهد لتعديله. "كن حكيما لا ذكيا"
4. استيراد المكتبة بأكملها
تجنب استيراد المكتبة بأكملها بأي ثمن! سيؤدي ذلك إلى زيادة حجم الحزمة. سوف آخذ لوداش كمثال. لا تستورد _ من "لوداش". سيؤدي ذلك إلى زيادة حجم الحزمة الخاصة بك بأكثر من 500 كيلو بايت.
يجب عليك استيراد الوظيفة الوحيدة التي تحتاجها. على سبيل المثال ، الاستيراد فارغ من "Lodash / isEmpty" ، وسيقوم جهاز التجميع الخاص بك بهزه.
5. استخدام مستمع الحدث الفردي بدلاً من تفويض الحدث
يمكن لتفويض الحدث تبسيط الكود وحفظ الذاكرة ، دون الحاجة إلى إضافة معالجات أحداث متعددة ، عند إضافة عناصر DOM أو إزالتها ، لا حاجة لإضافة / إزالة المعالج.
مستمع الحدث الفردي
يوضح الرسم البياني أعلاه أن كل شخص لديه مستمع حدث خاص به ، ومستمع مختلف للأحداث يستمع إلى نفس المعالج. مما سيؤدي إلى ارتفاع استهلاك الذاكرة. ومع ذلك ، يمكن إعادة هيكلة هذا.
تفويض الحدث
حصل تفويض الحدث على أداء أفضل مقارنة بمستمع الحدث الفردي لأنه يحتوي على مستمع واحد فقط للحدث.
كما نعلم ، تحتوي JavaScript على حدث تم نشره (منتشر) في التسلسل الهرمي في شجرة DOM. عند النقر فوق عنصر li ، ستتلقى ul في النهاية حدث النقر.