مرحبا اسمي Azat Zulkarnyaev ، أقوم بتطوير تطبيقات iOS على Badoo. عند إنشاء تطبيقات الهاتف المحمول ، يتم قضاء معظم الوقت في تطوير واجهة المستخدم ، ويكون تحسين هذه العملية دائمًا موضوعًا ساخنًا بين المطورين. كتب زميلي ألكسيس سانتوس مقالًا عن المشكلات التي واجهناها وكيف تحركنا صوب حلها عند العمل في هذه المهمة. قررت مشاركة الترجمة معك. أوصي أيضًا بمشاهدة تسجيل لتقرير حديث صادر عن إيجور سافيليف في Mobius 2018.قبل بضعة أشهر ، صادفت مسلسل وثائقي ممتع للغاية من Netflix - "التجريد: فن التصميم". وهي تفصل عمل المصممين من مختلف المجالات: الهندسة المعمارية ، والتصميم الجرافيكي ، والأزياء ، وما إلى ذلك. من السهل أن تلاحظ تشابهاً معينًا من عملهم مع أنشطة مطوري iOS المشاركين في تنفيذ واجهات المستخدم. على وجه الخصوص ، أثناء العمل في مشروع كبير ، يحاول المصممون تقسيمه إلى العديد من المهام الصغيرة بناءً على مبدأ "فرق تسد" وإتاحة الفرصة لتجميع جميع العناصر معًا في مرحلة لاحقة.
يتيح هذا الفصل التركيز على مشكلة معينة دون مراعاة ترابط المكونات. ومع ذلك ، لا يمكنك أن تنسى تمامًا الصورة الكبيرة - وإلا ، عندما يحين وقت التجميع ، قد تنشأ صعوبات.
من ناحية أخرى ، خلال عملية المشاهدة ، لاحظت أن التصميم النهائي للعديد من المنتجات - الأحذية أو الملصقات أو المباني - لا يخضع لأي تغييرات بمرور الوقت. نايك ، إرسال أحذية رياضية جديدة لتخزين الرفوف ، لم يعد تحديث مظهرها. في بعض الحالات ، لا يزال المنتج رائعًا في غضون 20 عامًا. لسوء الحظ أو لحسن الحظ ، لا ينطبق هذا المبدأ على تصميم تطبيقات الأجهزة المحمولة - يجب أن يكون المطورون على استعداد لإجراء تغييرات متكررة في مظهر منتجاتهم.
نايك اير ماكس 97 ، مبنى امباير ستيت (نيويورك)العديد من مطوري iOS ، الذين يعملون على تطبيقات كبيرة ومعقدة ، يقضون الكثير من الوقت في إنشاء واجهات ، وتحديد علاقات الكائنات ، وشحذ التفاصيل الصغيرة. من أجل العمل الفعال ، من الضروري أن تضع في اعتبارك الشكل الذي يجب أن يبدو عليه التطبيق ككل ، ومن المهم بنفس القدر التفكير في تقسيمه إلى مكونات منفصلة ، يتم إعادة استخدامها لاحقًا عند تطوير عناصر التطبيق.
يقوم فريقنا بإصدار إصدارات جديدة أسبوعيًا ، ويحتوي كل منها على ميزات وتحسينات وتغييرات أخرى تؤثر على واجهة المستخدم. نحن نسعى دائمًا للعمل بأسرع وقت ممكن وبكفاءة ، ولكن قبل عام ، أثناء تطوير واجهة المستخدم ، تم اكتشاف العديد من المشكلات.
العدد
باختصار ، لم تكن عملية تطوير واجهة المستخدم لدينا منظمة بشكل واضح.
في الممارسة العملية ، كان هذا يعني أن إطلاق أي وظيفة جديدة يمكن أن يؤدي إلى عواقب لا يمكن التنبؤ بها. على سبيل المثال:
- لم تكن هناك قواعد واضحة للتفاعل مع المصممين: الزملاء لم يكونوا دائمًا على دراية بعملنا ، وهذا أدى إلى حقيقة أنهم قاموا بإنشاء مكونات جديدة ، في الواقع ، تشبه تلك الموجودة ، ولكن تبدو مختلفة ؛
- لم يكن لدينا نموذج عالمي لتنفيذ مكونات واجهة المستخدم الجديدة: قام كل مطور بتنفيذ المكونات بطريقته الخاصة ، مما أدى إلى تعقيد دعم المشروع ؛
- رمز الازدواجية أيضا لم يجعل codebase أفضل.
نتيجة لذلك:
- لإجراء تغييرات على عنصر واجهة مستخدم واحد ، كان من الضروري تغيير الكود في العديد من أماكن المشروع ؛
- زيادة خطر كسر أجزاء التطبيق في الحالات التي لا تهمهم التحديثات فيها ولم يتم اختبار عملهم.
بالطبع ، كل هذه المشاكل لا يمكن أن تختفي عن طريق السحر. لتغيير ترتيب الأشياء ، كان من الضروري التوصل إلى اتفاق بين مختلف الفرق وإقناع جميع المشاركين في العملية بأن التغييرات ضرورية.
بالمناسبة ، مبدأ "فرق تسد". بدأنا المشكلات الصغيرة التي تم تحديدها واحدة تلو الأخرى ، وبعد ذلك توصلنا إلى حل عالمي خطوة بخطوة. أدناه سأخبرك كيف فعلنا ذلك.
أطر واجهة المستخدم
لقد تعاملنا مع حل المشكلة بكل جدية وبدأنا بالأساسيات. بادئ ذي بدء ، كان من الضروري التخلص من ازدواجية التعليمات البرمجية. للقيام بذلك ، قمنا بتوحيد المكونات المستخدمة ، ونجمعها معًا.
قررنا إنشاء عدة أطر تسمى BadooUIKit. وفقًا لفكرتنا ، يجب أن تحتوي على جميع مكونات واجهة المستخدم الضرورية (مثل UIKit من Apple). يتوافق كل فصل من فصول إطار العمل مع عنصر واجهة المستخدم للتطبيق (تقوم شركتنا بتطوير تطبيقات أخرى ، لكن في UIKit أضفنا فقط المكونات المستخدمة في Badoo).
كل تطبيق له خطوط وألوان وهوامش وسمات أخرى خاصة به ، وبالتالي من المفيد جدًا أن يكون هناك ورقة أنماط تتعلق بتطبيق معين.
ولكن ماذا لو كان أحد مكونات واجهة المستخدم أو أكثر يمكن استخدامه في تطبيقات مختلفة؟لهذه الحالة ، أنشأنا إطارًا آخر - Platform_UIKit. أنه يحتوي على جميع المكونات المناسبة للتطبيقات الأخرى.
هل نقلت فقط جميع واجهات المستخدم إلى الإطار الجديد مرة واحدة؟لا ، هذا مشكلة كبيرة. بدلاً من ذلك ، أنشأنا كل عنصر واجهة مستخدم جديد داخل الإطار ، ولم يتم نقل المكونات الموجودة إلا إذا لمسناها كجزء من عملنا في مهامنا. في بعض الأحيان كان من الصعب ترحيل مكون بسبب كثرة التبعيات - ثم عملنا عليه بشكل منفصل. بادئ ذي بدء ، قمنا بنقل العناصر الأساسية مثل الخطوط والألوان والأزرار. بعد ذلك ، بعد قيامنا ببناء الأساس ، قمنا بنقل الواجهة الكاملة لدردشةنا إلى الإطار. لتسهيل الأمر ، فعلنا ذلك بعد إنشاء البنية التحتية.
Offtopic: إذا كنت مهتمًا بعملية إنشاء المكونات ، فابحث عن مقالة رائعة كتبها زميلي Valery Chevtaev myltik .
أحد المتطلبات الرئيسية للأطر هو عدم الاعتماد على الأطر والفئات الأخرى غير المرتبطة بـ UI. على وجه الخصوص ، نحن لا نستورد أبدًا نماذج من التطبيق الرئيسي ، والطبقات المتعلقة بطبقة الشبكة ، والتحليلات ، إلخ. وبفضل هذا ، سنحصل على فرصة لإعادة استخدام المكونات:
يمكننا استيراد البيانات من Platform_UIKit إلى BadooUIKit ، ولكن ليس العكس: يجب أن تظل Platform_UIKit مستقلة.
لم يتطلب إنشاء هذه الأطر الكثير من العمل ، وكذلك دعمها اللاحق. يختلف كل مشروع Badoo جديد عن المشروع السابق ، وقد يكون من الصعب علينا الحفاظ على البنية الموصوفة ، لكن حلنا استفاد في الأجلين القصير والطويل.
إيجابيات استخدام UIKit:
- تخزين جميع مكونات واجهة المستخدم في مكان واحد يسهل العثور عليها ؛ تبعا لذلك ، يصبح العمل أكثر تنظيما.
- تحرير الفئات من التبعيات يساعد في تقليل وقت الترجمة ؛
- القضاء على التبعيات يسهل إعادة استخدام المكونات ويسرع أيضًا عملية التجميع ؛
- تحديث مكون في BadooUIKit ، نقوم بتحديثه في كل مكان ؛ إذا كان التطبيق يستخدم مكونات من BadooUIKit ، فسيتم تبسيط عملية إجراء تغييرات على المكونات في جميع أنحاء التطبيق ؛
- المكونات المعزولة أسهل بكثير للاختبار ؛
- إذا لزم الأمر ، يمكن استخدام إطار منفصل في تطبيقات أخرى (على سبيل المثال ، عند إنشاء تطبيق - كتالوج لجميع مكونات هذا الإطار).
إنشاء معرض Badoo
ساعد BadooUIKit في حل جزء كبير من المشكلات ، لكننا أدركنا أنه لا يوجد حد للكمال.
كيف ترى كل مكونات واجهة المستخدم بشكل فردي؟ هل يمكنني تخصيص البحث عن المكونات ومشاهدتها في أنظمة ألوان مختلفة؟ هل يمكن تسهيل اختبارهم؟ هل يمكن إنشاء كتالوج لجميع مكونات واجهة المستخدم الحالية والمنفذة للمصممين؟
من خلال إطلاق BadooUIKit ، قررنا إنشاء دليل تطبيق منفصل بسيط للاستخدام الداخلي. لذلك كان هناك معرض Badoo.
بادوو غاليري هو أداة تساعد المطورين والمصممين وحتى أعضاء فريق المنتج على رؤية جميع مكونات واجهة المستخدم بطريقة واضحة يسهل الوصول إليها. عند إنشائه ، استخدمنا مجموعة متنوعة من الأدوات التي تسهل التفاعل مع المكونات.
نظرًا لأن طلبنا لم يكن مخصصًا للنشر على متجر التطبيقات ، فبإمكاننا إضافة أي أداة نعتقد أنها ضرورية. كمفتاح ، حددنا الوظائف التالية:
- البحث المكون ؛
- فرز المكونات بالاسم ؛
- إضافة عناصر إلى المفضلة
- التبديل بين الأنماط - حتى تتمكن من رؤية كيف سيبدو المكون في تصميم معين ؛
- فليكس
- FPS العداد.
يمكن أن يكون كل مكون في حالات مختلفة اعتمادًا على تصرفات المستخدم والمنطق الداخلي للتطبيق. على سبيل المثال ، لدى UIButton خمس ولايات: 1) بشكل افتراضي ، 2) مظلل ، 3) عند التحويم ، 4) عند النقر ، و 5) مقفل.
مثيرة للاهتمام؟ اقرأ المزيد
هنا .
بالإضافة إلى ذلك ، أردنا أن نكون قادرين على تقديم جميع المجموعات الممكنة في مكان واحد - ونحن نفعل ذلك مع كل شاشة من كل مكون. بالطبع ، قد تختلف حالات أزرارنا عن حالات أزرار UIKit Apple.
الفوائد الرئيسية لمعرض Badoo:
- القدرة على إنشاء قائمة بمكونات واجهة المستخدم المنفذة ؛
- سهولة البحث عن مكونات واجهة المستخدم: يمكن لكل واحد منا رؤية جميع الخيارات الممكنة لظهور مكون واجهة المستخدم والبحث عن تطبيق لها ؛
- البحث الخفيف عن المكونات الموجودة يساعد في إقناع المصممين بإعادة استخدامها ؛
- وقت تجميع مثل هذا التطبيق الصغير قصير جدًا ، مما يساعد على تقليل فترة التطوير بشكل كبير ؛
- وظيفة المفضلة تساعد على العثور على المكونات التي يتم تنفيذها حاليا ؛
- تتيح لك إضافة أدوات خارجية مثل FPS و FLEX و MultiBrand قياس جودة مكونات واجهة المستخدم وتحسينها ؛
- يتم وضع جميع المكونات في إطار منفصل ويتم تقديمها في بيئة معزولة - أصبح الاختبار أسهل كثيرًا.
قليلا عن الاختبار
ساعدت الأدوات الجديدة في حل معظم المشكلات الموضحة في بداية المقالة ، ولكن ظلت بعض الأسئلة بلا إجابة.
هل يمكن أن نتأكد من أنه بعد إجراء التغييرات ، ستبدو واجهة المستخدم كما لو كنا نهدف؟ كيفية حماية المكونات والأجزاء الأخرى من التطبيق من الآثار الضارة للمعلمات الجديدة للمكونات الفرعية؟
العثور على إجابات لهذه الأسئلة سوف تساعد في اختبار مكونات واجهة المستخدم. هناك الكثير من المقالات على الويب حول تنظيم اختبار واجهة المستخدم على نظام التشغيل iOS. بالإضافة إلى ذلك ، هناك العديد من الأدوات المختلفة المصممة لاختبار الجوانب المختلفة للواجهة.
قررنا إجراء اختبار اللقطة عن طريق تقديم واحدة من أدوات المساعدة مفتوحة المصدر الأكثر شهرة iOSSnapshotTestCase (المعروفة سابقًا باسم FBSnapshotTestCase ، حيث تم إنشاؤه بواسطة Facebook).
يمكنك معرفة المزيد حول اختبار استخدام لقطات الشاشة وحول هذا الإطار باستخدام أحد هذه الروابط:
كنا بحاجة إلى طريقة لاختبار المكونات الموجودة بالفعل على BadooUIKit لتجنب الانحدار عند تحديث مكونات التطبيق. أردنا أيضًا أتمتة عملية إدخال اختبارات لقطة جديدة إلى الحد الأقصى.
في وقت سابق ، تحدثت عن المعرض الذي أنشأناه ، والذي يحتوي على قائمة بجميع المكونات ويذكر أنه يمكن لكل مكون قبولها. هذا أمر مريح للغاية ، لأنه في هذه الحالة ، يمكن إجراء اختبارات على أساس Badoo Gallery كتطبيق مضيف.
جميع المكونات الموجودة في BadooUIKit موجودة في فئة المستودع التي تتيح الوصول إلى جميع المكونات. يمكن لمستودع التخزين هذا عرض قائمة المكونات في المعرض وفتح الوصول إليها باستخدام فئات اختبار اللقطة. يحررنا هذا من العمل المزدوج المتمثل في إنشاء كائنات وإعداد حالات مختلفة لكل مكون ، حيث أن كل هذا تم بالفعل عندما قدمنا المكون إلى المعرض.
فيما يلي إجابات للأسئلة الأكثر شيوعًا حول الاختبار باستخدام لقطات.
أين يتم تخزين اللقطات؟نحن تخزينها مباشرة في مستودع جيت. كنا خائفين من أن هذا يمكن أن يؤدي إلى الانتفاخ ، ولكن في الواقع تبين أن كل شيء ليس سيئًا للغاية. كقاعدة عامة ، نقوم باختبار المكونات الصغيرة ، وبالتالي تزن لقطات الشاشة القليل جدًا. في الوقت الحالي ، يستغرق المجلد الذي يحتوي على لقطات شاشة حوالي 11 ميغابايت ، وهو في رأينا أمر مقبول.
هل تختبر جميع الأذونات الممكنة في جميع البيئات الممكنة؟لا ، فوائد هذا النهج قليلة. ولكن قد تكون هناك مشاكل كافية: ستصبح الاختبارات غير موثوق بها ، وسيصبح المجلد الذي يحتوي على لقطات أكثر ضخامة ، وسيكون دعم مجموعة الاختبار أكثر صعوبة. نجري اختبارات بشكل عملي للأجهزة الأكثر شعبية فقط. بالإضافة إلى ذلك ، تم تكوين نظام CI الخاص بنا لاستخدام نفس المحاكاة التي تم استخدامها لإنشاء اللقطة.
هل يمكن أن تغطي اختبارات اللقطات الواجهة بأكملها؟لا أعتقد ذلك. نحن في Badoo نقوم بإجراء اختبارات مختلفة لمستويات مختلفة من التطبيق. على سبيل المثال ، وظيفية (باستخدام أطر Calabash و KIF) والتكامل.
الاستنتاجات
بالطبع ، أثناء بناء النظام الأساسي الجديد ، تعلمنا الكثير - ونواصل التعلم. ظهرت الأدوات والعمليات الموضحة أعلاه قبل حوالي عام وما زالت قيد التطوير. في هذه المرحلة ، يمكننا أن نستنتج أنهم يستفيدون جميعًا من المطورين والشركة ككل.
فيما يلي بعض الدروس التي تعلمناها أثناء عملنا:
- لا يمثل نقل جميع المكونات الموجودة مهمة سهلة ، ولكن من خلال تطبيق نظام التصميم ومطالبة الفريق باستخدامه ، سترى كيف ينمو عدد المكونات بسرعة: لن يؤدي نقل المكونات التي يستخدمها المطورون إلى زيادة عدد عناصر واجهة المستخدم المعاد استخدامها في نظامك تلقائيًا فحسب ، بل يساعد أيضًا العناصر الموجودة على تحرير من التبعيات في المستقبل ، سيسمح هذا بنقل المزيد من المكونات ؛
- يرغب المصممون في إعادة استخدام المكونات (يصبح إقناعهم بالقيام بذلك أسهل عندما يكون من الممكن إظهار مكون يعمل بالكامل يلبي متطلباتهم) ؛
- توفير الوقت ضروري ؛ نعلم جميعًا أن مدة تجميع المشاريع على Swift and Objective-C يترك الكثير مما هو مرغوب فيه ، في حين أن تطبيق Badoo Gallery خفيف الوزن وسريع جدًا في التجميع ؛ لقد أدركنا أنه من الأنسب تطبيق مكونات واجهة المستخدم مباشرةً باستخدام المعرض ، ثم استخدامها من خلال التطبيق الرئيسي ، حيث التجميع ليس بهذه السرعة ؛
- من خلال الجمع بين جميع المكونات في UIKit وإطلاق تطبيق معرض حيث يمكنك اختبارها ، جعلنا عملية الاختبار بأكملها أكثر كفاءة وأسهل.
التالي - الكون
نولي اهتمامًا كبيرًا بكل من منتجاتنا ونريد أن يكون لجميعها واجهة عالمية وجذابة. لكي يستمتع المستخدمون باستخدامهم قدر الإمكان ، قررنا إجراء تغييرات عالمية. بمساعدة المصممين وفريق المنتج ، نعرض نظام تصميم موحد جديد يسمى Cosmos.
كتب
كريستيانو راستيلي بعض
المقالات الرائعة حول كيفية ظهور نظام الكون. لا تفوت!
شكر وتقدير
تم تنفيذ العمل في المشروع من قبل أكثر من شخص - إلى درجة واحدة أو أخرى ، شارك فريق Badoo iOS بأكمله في ذلك ، بما في ذلك المديرين والمطورين والمختبرين. أشكرهم جميعًا ، لأن كل واحد منهم كان على متن الطائرة منذ بداية الرحلة.
بفضل مصممينا المذهلين الذين هم على استعداد دائمًا لبذل كل جهد ممكن لتحسين عملية التصميم.
شكر خاص لـ
Alexander Zimin : للعديد من التحسينات المقترحة ، زيارة عدد لا يحصى من الطائرات الشراعية ، وكذلك على الدعم المقدم لي في هذه المغامرة.
أشكر أيضًا
Alissa Ordigliano على الرسوم التوضيحية الممتازة التي جعلت هذه المقالة أكثر سهولة.