وتف في الساعة

لا يمكن لروح الشاعر تحمل الغموض ، ويشاركه بسخاء أفكاره النبيلة. (ج) مجهول

منذ بعض الوقت كتبت ثلاثة مقالات بعنوان "الحلول المعمارية للعبة المحمولة" مخصصة لهندسة أحلامي:
• الجزء 1: نموذج
• الجزء 2: القيادة وقوائم الانتظار الخاصة بهم
• الجزء 3: عرض على الدفع النفاث

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

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

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

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

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

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

سيبدأ البث يوم الأربعاء الساعة 22:30 (هذا هو وقت فراغي ، للأسف. :) وسيكون متاحًا هنا:

الآن عن محتوى الدفق.

بشكل عام ، هناك تطبيق لطيف للتفاعلية في مكتبة UniRX ، والتي أوصي بشدة بالتعرف عليها. ربما ستأخذها حرفيا لنفسك ، أو ربما تمسح الأفكار من هناك. لكنني سأظهر دراجتي الخاصة ، مكتوبة من الصفر. هذا ليس فقط لأنني أحب الدراجات. في UniRX ، تنفذ واجهات النظام القياسية. IObserver <in T> و System.IObservable <out T>. وفي العديد من الأماكن ، يقوم ThreadSafe بهذا (ليس دائمًا بشكل صحيح) والداخلي. وهذا يعني أن المكتبة بها الكثير من الأكواد ، ومن غير المريح توسيعها. وفي الواقع كنت بحاجة للتوسع والتكيف مع الظروف المحلية في ثلاث حالات من أصل ثلاث.

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

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

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

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

لذلك ، أريد الواجهة الخاصة بي ، من ناحية دون سحب OnError ، ولكن من ناحية أخرى تحتوي على .OnTransaction (ITransaction t)

شيء أشعر بالغ العمق. سيكون الحديث عن ذلك أثناء تدفق مع رمز على الشاشة أسرع بشكل واضح وأكثر قابلية للفهم. مزيد من المعلومات حول القمم:

• واجهاتي هي IActive و IReactive. كيف تكون أجمل من أي أحداث وكيف تبدو النتيجة النهائية لاستخدامها.
• ActiveProperty <T>. كيف يختلف عن Active.Proxy <T> كيف يتم تمريره وكيف تتم معالجة القيمة الأولية للمتغير.
• كيف يمكنني التحقق من كل هذا مع الاختبارات ولماذا مريحة للغاية. في الواقع ، لن يكون من الممكن كتابة شيء من هذا القبيل دون اختبارات على الإطلاق.
• استراتيجية التدبير الإداري آلية مزدوجة تدعم كلاً من OnComplete و ICollection <IDisposible>
• كيفية القيام بسهولة تدفق ملحقات مجموعة الأدوات وقراءة الأمثلة الأكثر فائدة.
• أدوات التصحيح لجميع هذه الفوضى. أولاً وقبل كل شيء .Log () ، وسنصل إلى حساب حساب الحساب في وقت ما في المرة القادمة.
• قراءة متأنية لرمز Active.Proxy <T> ، لماذا لا توجد أي أحداث أسفل الغطاء ، ولكن قائمة مزدوجة الارتباط.
• IActiveList و IActiveDictionary ، أول الأفكار الأكثر شيوعًا.
• كيفية الانقسام إلى ViewModel ، المراقب المالي وعرض. كيف لا حلقة تياراتك.
• عملية إسقاط المتغيرات من التفاعلية إلى نموذج.
• ActiveList و ActiveDictionary مع الحد الأدنى من دلتا. على عكس التنفيذ الأمامي لـ DeltaDictionary بشكل عام وفي UniRX بشكل خاص.
• الإستراتيجية العامة لتصحيح الأخطاء في الكود ، لأنه لا يوجد موضوع في الجامعات ، لكن يجب أن يكون كذلك.

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

ملاحظة: سيكون هذا أول دفق لي ، لذا لا تحكم بدقة في حالة وجود أي مشكلات فنية.