تطوير الواجهة الأمامية في الشركة: ما هي وكيف تجعلها فعالة



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

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

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

في هذه المقالة ، ستتعرف على طريقنا للإجابة على الأسئلة التالية:

  • , ;
  • , ;
  • ;
  • ;
  • ;
  • .


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

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

بطريقة ما سئلت عن ماذا أحتاج الآن لتقديم الطلبات حتى لا تصبح عفا عليها الزمن لعدة سنوات أخرى؟

بصفتي مبرمجًا ، يمكنني تقديم إجابة دقيقة تمامًا وغير مفيدة تمامًا: HTML و CSS و JavaScript. ما يجب اختياره بالضبط ، jQuery ، Angular أو React - هذه هي التفاصيل.

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

ماهو الفرق؟

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

لذا ، ما الذي تحتاجه للقيام بالتطبيقات في الوقت الحالي ، بحيث يتم التطوير بسرعة وكفاءة ولا يفسد العميل؟

سرعة التطوير


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

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

جودة المنتج


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

كل هذا يتوقف على خبرة ومعرفة المطور.

كلفة


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

ومن هنا الاستنتاج: أنت لا تحتاج إلى الاعتماد على التكنولوجيا بقدر ما تعتمد على المطورين وتنظيم عملهم.

يكاد يكون أي إطار عمل حديث حديث جيدًا بما يكفي لإنشاء أي تطبيق قد يتطلبه العمل الحديث تقريبًا.

لذلك ، سيكون أكثر حول فعالية الواجهة الأمامية من حيث تنظيم التنمية.

كيف كان معنا


بحلول عام 2017 ، كانت لدينا تطبيقات على كل شيء تقريبًا يستحق الاهتمام في عالم جافا سكريبت: من jQuery إلى إصدارات مختلفة من Angular و React on Typescript and Flow. عمل مطورو التخطيطات والخلفية / fullstack على جانب العميل من تطبيقاتنا. اختار كل مطور أدوات لمهامه ، اعتمادًا على معرفته بتقنيات الواجهة الأمامية.

يمكنني الآن التكهن فقط ، ولكن يبدو لي أن اختيار الأطر والمكتبات من قبل مطوري البرامج الكاملة / الخلفية كان شيئًا مثل هذا:

"دعنا نرى ما يكتبونه على الإنترنت ..."










حسنًا ، أنت تفهم.

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

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

دون علم عام 2017 ، تحولنا إلى حديقة حيوانات تقنية أمامية حقيقية.

الواجهة الأمامية كوحدة منفصلة


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

يمكن للوثائق عالية الجودة أن تخفف من الآثار السلبية لهذا التنوع ، ولكن عادةً ما تستغرق وقتًا طويلاً للدراسة وتغرق في تكنولوجيا غير مألوفة.

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

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

كيفية علاج حديقة الحيوان؟


مجموعة متنوعة من التقنيات غير المنضبط تجعل من الصعب التنبؤ بسرعة وجودة التطوير بشكل عام ، بينما يتطلب التطوير التجاري ذلك تمامًا.

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



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

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

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

كمرجع: أداتنا الرئيسية هي React ، لكننا نعمل أيضًا على تطوير الخبرة في Angular.

هنا يبدا المرح. إن التأثير في عالم البرمجة يعمل بشكل سيئ للغاية.



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

للقيام بذلك ، تحتاج إلى:

  1. إصلاح بطريقة ما ، إضفاء الطابع الرسمي على متطلبات التنمية ؛
  2. شجع المطورين على اتباع هذه الإرشادات.

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

لقد حللنا مشكلة التحفيز على النحو التالي: من الأفضل من أي وثائق أن تمنح المطور تطبيقًا نصف نهائي (قالب).

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

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

ما تحتاجه لوضعه في قالب التطبيق


عند بدء مشاريع جديدة ، يقوم المطورون عادةً بحل المهام النموذجية التالية:

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

أي من هذه المهام يمكن لمطوريك حلها في بضع دقائق؟

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

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

  • وحدات قالب منطق الأعمال التي يتم توصيل معالجات الخطأ ، والمحمل ، والإعلام.

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

ولكن بعد ذلك ، ينتظر المطور عددًا كبيرًا من المهام الأخرى المثيرة للاهتمام (وليس كذلك).



اختيار مكتبة المكونات


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

في عام 2017 ، كانت المكتبة الرئيسية للشركة هي مكتبة مكونات Kendo المدفوعة ، والتي قدمت حلول واجهة المستخدم لمختلف التقنيات ، بدءًا من jQuery. لأسباب مختلفة ، لم يناسبنا ذلك ، وقررنا النظر في مكتبات بديلة ، بما في ذلك خيار إنشاء مكتبتنا الخاصة.

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


:

  • ;
  • ;
  • .

:

  • ( , , );
  • ;
  • , . ;
  • , . .



:

  • ;
  • ;
  • .

:

  • ;
  • , / ( ..);
  • ( , , , ).

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

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

لا أحد من الخيارات يناسبنا تمامًا ، ووجدنا حلاً آخر.

قررنا عمل إضافة للمكتبة النهائية.



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

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

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

قررنا وضع إنجازاتنا في المجال العام ، وسرعان ما يمكن تنزيلها واستخدامها في مشاريعنا ، اتبع الإعلانات.

ماذا حصلنا في النهاية؟


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

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

بدأنا بتقليل وقت التطوير عن طريق تغيير هيكل مهام المبرمجين. دعونا نلقي نظرة على كيفية تغيرها.

لقد قدمت بالفعل قائمة بالمهام التي قام المطورون بحلها قبل عامين:

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

من بين هؤلاء ، في شركتنا اليوم ، ينخرط المطورون في الثلاثة الأخيرة فقط:

  • تنفيذ الوظائف بأمر من العميل (منطق الأعمال) ؛
  • مراجعة التعليمات البرمجية؛
  • الحفاظ على وثائق المشروع.

يتم تحديد الباقي بالفعل في قالب التطبيق ومكتبة المكونات.

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

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

مع رغبات الكفاءة ونراكم قريبا!

Source: https://habr.com/ru/post/undefined/


All Articles