كيف يمكن أن تساعدك الاختبارات في إنشاء مجموعة أدوات واجهة المستخدم الخاصة بك

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

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

سواء أردنا ذلك أم لا ، وسواء فهمنا ما نكتبه أم لا ، فإننا نعمل مع المكونات ، نحلل المهام دائمًا إلى مهام أصغر.

وجمعنا للمرة الأولى لكتابة التنفيذ التالي للطاولة من أجل مجموعة أدوات واجهة المستخدم الداخلية الجميلة ، فكرت - ما العمل التمهيدي الذي أحتاج إلى القيام به؟ ما يجب أن تكون مكتوبة بالضبط؟ ومن أين تبدأ؟



بعد التحدث مع زملائه في الفريق ، سمعت بعض النصائح. أنا فقط حقا أحب واحدة. منذ أن كنت من محبي التفرد وقليلا من graphql ، طلب مني عدم كتابة أي شيء على الإطلاق. استخدم العلامة {table} وستقوم بعض الشبكات العصبية بمعالجة هذا الجدول ، وإنشاء استعلام graphql ، وملء الجدول بالبيانات. سهل واحد :).
لكن كما يقولون - "هناك خلل قاتل في أي نظام" ، بدأت أفكر في "كيفية ابتكار العجلة الخاصة بي". لقد توصل الأشخاص الأذكياء بالفعل إلى كل شيء أمامنا. نحن ، الألفية ، لا يمكننا إعادة ترتيب اللوحات وتسمية الأشياء إلا بطريقة مختلفة.

أنا مستعد لتقديم مجموعة من المبادئ الخاصة بنماذج UI-kits - IDOLS! لنلقي نظرة!

أنا أقف مع الفصل بين الواجهة ، و D تعني انعكاس التبعية ، O تقف ... تمزح فقط ، بالطبع ، إنها سوليد

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

دعونا تحميل هذه المبادئ في "RAM" لدينا وتصفح النقاط.

S - مسؤولية واحدة

هم ، من فضلك لا ...

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

O - فتح / مغلق

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

استبدال L - Liskov

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

I - واجهة الفصل

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


كل شيء يتم تكوينه في مكان واحد ، غير قابل للإصلاح وغير قابل لإعادة الاستخدام ...


كل شيء كمنشئ ، تجميع كما تريد وبشكل مريح

د - التبعية الانعكاس

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



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

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

لذلك دعونا نلقي نظرة ، ما هو التصميم الذري.

الرموز

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

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

ذرات

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

جزيئات

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

الجزيئات هي المستوى الأخير حيث يمكننا تلبية التصميم.

الكائنات الحية

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

قوالب / صفحات

المستوى الأخير من التصميم الذري. يمثل هذا المستوى مجموعات الكائنات الحية ، والتي تضمنتها الصفحة الحالية.

يمكننا أن نجعل تكوين الكائنات الحية على الصفحة عبر الجزيئات ثم نسمي تلك الصفحة كـ "تخطيط" ونعيد استخدامها لتغيير كائناتنا الحية بداخلها.

باستخدام هذين النهجين (SOLID و Atomic) ، سنحاول صياغة بعض التوصيات عند تطوير المكونات. لذلك ، ستكون هناك حاجة إلى تلك التوصيات لكي نفهم ، ما الذي نفعله بالضبط عندما نقول "إنشاء مكون واحد آخر".

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

يمكننا البدء في تطوير واجهة مثالية لدينا.

أول شيء تبدأ به هو عدم البدء في تطوير واجهة مثالية. الواجهة المثالية هي افتقاره. الواجهة هي عقبة بين ما فعلته ومتى تبدأ في العمل. هذا هو الألم ، والتي يجب تجنبها.

وبالتالي ، فإن أفضل حل هو ما يلي:


هذا ينقلنا بسلاسة إلى ما يلي:

1. تحديد حالة المكون

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



يمكن أن تكون الولايات مختلفة تمامًا في أوقات مختلفة.
فارغة → تحميل → تحميل → تحميل جزء آخر → محملة بالكامل → خطأ ، الخ
توجيه المطورين من خلال جميع المجموعات الممكنة من الدول ، وتعليمهم أثناء العمل.

عند التعامل مع مشكلات الحالة ، يتعثر المرء قسريًا بسبب مشكلة الحالات الافتراضية. بسبب ذلك ، التوصية الثانية.

2. تحديد القيم الافتراضية

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



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

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

3. لا حاجة لإعادة اختراع العجلة

ليس changePasswordInputValue ، ولكن onChange ، لأنه إذا كان "جزيءك" ، فسيظل من الواضح دائمًا ما ستتغير القيمة.

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

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

4. حاول أن تعطي للمطورين أكبر قدر ممكن من التحكم

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



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

5. حافظ على نظافة مكوناتك وجفافها حتى لا تتسرب التجريدات (KISS).

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

لذلك ، لدينا قائمة مختصرة بالتوصيات التي سيكون من الجيد اتباعها.

1. تحديد الدولة
2. تحديد القيمة الافتراضية
3. لا تعيد اختراع العجلة
4. دعهم (devs) يحكمون
5. اجعلها بسيطة ، غبية (KISS)

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

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

كيف إذاً أن نخدع عقولنا ونعمل التوصيات؟

حسنًا ، دعنا نحاول أتمتة هذا.

أتمتة

يمكننا استخدام حزمة eslint + lefthook أو أي أداة ربط أخرى.



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

لكن هذه ليست رصاصة فضية ولا يمكننا الوفاء بجميع التوصيات. فقط جزء.



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

ثم يمكنك تجربة طريقة أخرى. تطوير مكوناتنا من خلال SDD. قصة مدفوعة التنمية.

قصة يحركها التنمية

لدينا ملف قصة في النموذج حيث نصف جميع الحالات الممكنة للمكون. وقصة جمع هذه القصص.


قصصنا عن المكون


كيف تظهر القصص القصيرة لنا القصص

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

لكن في النهاية ، هذا أيضًا لن يعطينا كل ما نريد.



لذلك ، يبقى شيء واحد فقط.

الاختبارات واللقطات

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



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

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



وهنا نذهب ...



اكتب اختبارات للمكونات الخاصة بك. شكرا.