👨🏻‍🏭 👨‍🚒 🧓🏾 بنية نظيفة للواجهة الأمامية ▶️ 🤜 👆🏽

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

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

التحفيز

في المرة الأولى التي قرأت فيها الأسئلة الشائعة حوالي عام ونصف قبل كتابة مقال حول نصيحة أحد كبار المطورين. قبل ذلك ، تأثرت للغاية بالمقتطفات القصيرة من Pure Code التي تم تكييفها مع JavaScript ( https://github.com/ryanmcdermott/clean-code-javascript ). أبقيت علامة التبويب هذه مفتوحة لمدة ستة أشهر لتطبيق أفضل الممارسات في عملي. علاوة على ذلك ، فشلت محاولاتي الأولى لقراءة قانون نظيف الأصلي. ربما لأنها ملتزمة جدًا بميزات مشاريع الواجهة الأمامية ، أو لأن القراءة يجب أن تعززها الممارسة طويلة المدى. ومع ذلك ، فإن Cheka هو دليل عملي يمكنك أخذه وتطبيقه على الفور إلى الوظيفة المكتوبة (أوصي بشدة بقراءتها أولاً إذا لم تكن مألوفًا).

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

منطق الأعمال والواجهة الأمامية

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

لقد عرف الجميع منذ وقت طويل أنك بحاجة إلى فصل منطق الأعمال عن العرض التقديمي ، ومراقبة مبادئ SOLID. سوف يخبرك العم بوب في CHA بذلك بالتفصيل. ولكن ما هو منطق الأعمال؟ يقدم R. Martin العديد من التعريفات والفئات الفرعية ؛ يبدو أحدها تقريبًا وبالتالي:

منطق الأعمال (قواعد العمل) هي القواعد التي تجلب الأموال للمؤسسات حتى بدون أتمتة.

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

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

قالب مقرف

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

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

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

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

ملاحظة: المكونات في ChA! == المكونات في تفاعل / الزاوي والتعاون.

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

مهمة بسيطة للغاية

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

ولكن دعونا نبدأ العمل. ما هذا النموذج؟ نحن نحاول أن نمثل ، ونعبر عن الأفكار برمز زائف.

ContactFormGroup
  +getValue()
  +isValid()

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

ContactFormGroup
  emailFormGroup
  phoneFormGroup
  getValue()
    => [emailFormGroup.getValue(), phoneFormGroup.getValue()]
  isValid()
    => emailFormGroup.isValid() || phoneFormGroup.isValid()

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

EmailFormGroup
  getValue()
  isValid()
  isSecondaryEmailVisible()
    => isValid() && !!getValue()

هل يمكننا تحديد مكان لمطالب غريبة ...

PhoneFormGroup
  getValue()
  isValid()
  isSecondaryPhoneVisible()
    => isValid() && today !== ‘sunday’

قد يبدو أحد تطبيقات نموذجنا على Angular هكذا.

تنفيذ ContactFormGroup (الزاوي)

export class ContactFormGroup {
    emailFormGroup = new EmailFormGroup();
    phoneFormGroup = new PhoneFormGroup();

    changes: Observable<unknown> = merge(this.emailFormGroup.changes, this.phoneFormGroup.changes);

    constructor() {}

    isValid(): boolean {
        return this.emailFormGroup.isValid() || this.phoneFormGroup.isValid();
    }

    getValue() {
        return {
            emails: this.emailFormGroup.getValue(),
            phones: this.phoneFormGroup.getValue(),
        };
    }
}

export class EmailFormGroup {
    emailControl = new FormControl();
    secondaryEmailControl = new FormControl();

    changes: Observable<unknown> = merge(
        this.emailControl.valueChanges,
        this.secondaryEmailControl.valueChanges,
    );

    isValid(): boolean {
        return this.emailControl.valid && !!this.emailControl.value;
    }

    getValue() {
        return {
            primary: this.emailControl.value,
            secondary: this.secondaryEmailControl.value,
        };
    }

    isSecondaryEmailVisible(): boolean {
        return this.isValid();
    }
}

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

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

مجموع

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

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

PS حول إدارة الدولة

يمكن أن يكون الالتزام بمكتبة إدارة الدولة عقبة كبيرة جدًا لفهم NA. في الواقع ، المكتبات مثل redux / mobx تحل في نفس الوقت مهمة إخطار المكونات حول التغييرات. وبالنسبة لبعض المطورين ، فإن الجبهة التي لا يوجد فيها مدير دولة أمر لا يمكن تصوره. أعتقد أنه يمكن تطبيق مبادئ ChA مع وبدون استخدام مدير الدولة. ولكن من خلال التركيز على مكتبة إدارة الدولة ، ستفقد حتمًا بعض المرونة. إذا كنت تعتقد من حيث ChA و OOP ، فإن مفهوم إدارة الدولة يختفي بشكل عام. أبسط تنفيذ بدون إدارة الدولة هنا habr.com/en/post/491684

PPS

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

بنية نظيفة للواجهة الأمامية