المبادئ

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

افتراضي إلى الاتفاقيات

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

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

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

المظاهر هي مصدر الحقيقة

يؤدي وجود العديد من طبقات التكوينات والعقود فيما بينها إلى إعداد مشروع يصعب التفكير فيه والحفاظ عليه. فكر للحظة في مشروع عادي. يعيش تعريف المشروع في الدلائل .xcodeproj ، وواجهة برمجة التطبيقات في البرامج النصية (على سبيل المثال Fastfiles)، ومنطق CI في خطوط الأنابيب. هذه ثلاث طبقات مع عقود بينها نحتاج إلى الحفاظ عليها. كم مرة مررت بموقف قمت فيه بتغيير شيء ما في مشاريعك، ثم أدركت بعد أسبوع أن البرامج النصية للإصدار تعطلت؟

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

يجب أن يمتلك التويست التعقيدات ويكشف عن واجهة بسيطة وآمنة وممتعة لوصف مشاريعهم بأكبر قدر ممكن من الوضوح.

اجعل الضمني صريحًا

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

يجب أن يوفر Tuist واجهات برمجة تطبيقات صريحة لسلوكيات Xcode الضمنية. كما يجب أن يدعم تحديد شاهد Xcode الضمني ولكن يتم تنفيذه بطريقة تشجع المطورين على اختيار النهج الصريح. يسهّل دعم شاهد Xcode الضمني والتعقيدات اعتماد Tuist، وبعد ذلك يمكن للفرق أن تستغرق بعض الوقت للتخلص من الشاهد الضمني.

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

يسمح تصميم واجهة برمجة التطبيقات لتكون صريحة لـ Tuist بإجراء بعض الفحوصات والتحسينات على المشاريع التي لم تكن ممكنة لولا ذلك. وعلاوة على ذلك، فإنه يتيح ميزات مثل tuist graph ، الذي يصدّر تمثيلًا للرسم البياني للتبعية أو tuist cache ، الذي يخزن جميع الأهداف في شكل ثنائيات.

TIP

يجب أن نتعامل مع كل طلب لنقل الميزات من Xcode كفرصة لتبسيط المفاهيم باستخدام واجهات برمجة تطبيقات بسيطة وواضحة.

اجعل الأمر بسيطًا

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

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

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

ابدأ من تجربة المطور

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

نحب أن نفكر كما قال [توم بريستون] (https://tom.preston-werner.com/) في [هذا البودكاست] (https://tom.preston-werner.com/): "يمكن تحقيق معظم الأشياء، أيًا كان ما يدور في رأسك يمكنك على الأرجح تحقيقه باستخدام التعليمات البرمجية طالما كان ذلك ممكنًا ضمن قيود الكون". إذا تخيلنا كيف نرغب في أن تكون تجربة المطور ، فإن الأمر مجرد مسألة وقت لإنجازها - من خلال البدء في تحليل المشاكل من تجربة المطور يعطينا وجهة نظر فريدة من نوعها ستقودنا إلى حلول سيحب المستخدمون استخدامها.

قد نشعر بالإغراء لاتباع ما يفعله الجميع، حتى لو كان ذلك يعني التمسك بالمضايقات التي يستمر الجميع في الشكوى منها. دعنا لا نفعل ذلك. كيف أتخيل أرشفة تطبيقي؟ كيف أحب أن يكون توقيع الأكواد البرمجية؟ ما هي العمليات التي يمكنني المساعدة في تبسيطها مع تويست؟ على سبيل المثال، إضافة دعم [Fastlane] (https://fastlane.tools/) هو حل لمشكلة نحتاج إلى فهمها أولاً. يمكننا الوصول إلى جذور المشكلة من خلال طرح أسئلة "لماذا". وبمجرد أن نحدد مصدر الدافع، يمكننا التفكير في أفضل طريقة يمكن أن يساعدهم بها تويست. ربما يكون الحل هو الاندماج مع Fastlane، ولكن من المهم ألا نتجاهل الحلول الأخرى الصالحة بنفس القدر التي يمكننا وضعها على الطاولة قبل إجراء المفاضلة.

الأخطاء يمكن أن تحدث وستحدث

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

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

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

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

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