مزايا إرشادات الأنماط التالية عند تطوير التطبيقات الزاوية

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



يمكنك مشاهدة الفيديو الخاص بي على يوتيوب.


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

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

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

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

قواعد أسلوب جيد

بالنسبة لـ AngularJS و Angular 2+ ، قام جون بابا ، وهو خبير مشهور في عالم تطوير الواجهة الأمامية ، بإنشاء أدلة أسلوب تصف قواعد الأسلوب الجيد عند تطوير تطبيقات Angular. العمل في Promsvyazbank ، علمت عن هذه الأدلة نمط. من الواضح أن الفريق تابعهم في جميع المشاريع. ولكن في المشروع الجديد ، جاء الرمز من مقاولين لم يفكروا بجدية في أسلوب البرمجة. مع فريقي الجديد ، صادفت المهام اليومية التي سبق لي حلها من قبل. ومع ذلك ، فإن هذا لم يعطيني أي مزايا ، ولكن فقط الألم والمعاناة.

قصة من الوقت الضائع أو لماذا نحتاج إلى كل هذه القواعد

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

لنبدأ بكل بساطة

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

الآن ، انظر إلى قاعدة Bootstrapping (النمط 02-05) من دليل النمط.

ضع الكود الذي يخدم تشغيل التطبيق في ملف منفصل ، ولا تضع منطق التطبيق في هذا الملف. يجب وضع المنطق في الخدمات والمكونات.

مثال مليون

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

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

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

عند مراجعة دليل أسلوب John Papa ، رأيت أن وحدتنا قد انتهكت عدة قواعد للشفرة الجيدة في آن واحد. بعد أن قدرت درجة تأثير كل من هذه القواعد ، حددت ثلاثة ، انتهك انتهاكها عملنا:

• حكم واحد - شطبت 25 ٪ من الوقت الضائع لانتهاك هذه القاعدة ؛
• مسؤولية واحدة - ساهم الانحراف عن هذا المبدأ في الخسارة الكلية بنسبة 35٪ ؛
• LIFT - في انتهاك لهذه المجموعة من الأساليب ، أعتقد أن 40٪ منا هم الأكثر تباطؤًا.

حكم واحد

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

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

الآن دعونا نرى ما يقوله حكم قاعدة واحدة.

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

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

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

تطبيق مبدأ المسؤولية الفردية (SRP).

رفع

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

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

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

ويكمل نهج LIFT من قبل اثنين من القواعد.

تقدم الإرشادات الهيكلية الشاملة إنشاء مجلد لكل مكون فردي وتجميع كافة الملفات المتعلقة بهذا المكون فيه. على سبيل المثال ، يكون أكثر ملاءمة عندما لا يكون ملف payment-form.controller.js في مجلد Controllers ، ولكن في مجلد نموذج الدفع مع payment-form.html و payment-form.css.

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

نتيجةً لذلك ، إذا اتبع مؤلفو الكود قواعد LIFT ، فإن بنية المشروع ستبدو كما يلي:



موافق ، هذا الخيار لتنظيم الكود هو أكثر ملاءمة للقارئ. وقال انه سيوفر فريقنا كله الكثير من الوقت.

المبرمجين جيدة الذهاب إلى شريط

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

إذا جعلك هذا النص يفكر في شيء ما أو ذكر شيئًا مألوفًا بشكل مؤلم ، فسيسعدني أن أراه في التعليقات على المنشور.