كيفية تسريع تطوير البرمجيات باستخدام JavaScript؟

تعريف التطوير السريع للتطبيقات

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

موبايل؟ الويب؟ لا أهتم.

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

• ليس هناك حاجة لتكرار الكود المسؤول عن نفس الشيء,
• ليست هناك حاجة لتوظيف مطوري الأجهزة المحمولة الأصليين لتنفيذ نفس الجزء من التطبيقات,
• ليست هناك حاجة للخلط بين لغات مختلفة لتنفيذ التطبيق نفسه عبر منصات الهواتف المحمولة المختلفة (Android/iOS),
• يمكن لمطوّر واحد أن يكون مسؤولاً عن تنفيذ ميزات تطبيق محدد على جميع المنصات.

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

الخلاصة - إذا كنت ترغب في إنشاء تطبيق ويب وتطبيق للهاتف المحمول في نفس الوقت، فكر في مكتبة React التي يمكنها مشاركة قاعدة بيانات في إصدار الهاتف المحمول والويب من التطبيق.

ولكن ماذا عن الواجهة الخلفية؟

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

ما الذي أتحدث عنه؟ إذا قمت بتعيين مطورو JS، اتضح أنه يمكنهم كتابة ليس فقط الواجهة الأمامية للتطبيق، ولكن أيضًا الواجهة الخلفية - أي أن يكونوا مسؤولين عن معالجة البيانات على الخادم، والتواصل مع قاعدة البيانات، وأنواع مختلفة من عمليات التكامل، إلخ. هل ما زلت متردداً أو غير مقتنع بهذه اللغة؟ لا يوجد سبب لاتخاذ هذا الموقف! الواجهة الخلفية باستخدام الشبيبة يمكن تنفيذها بطريقتين شائعتين - في وضع قابل للتوسيع والتكوين، وهو ما يمكن أن يوفره لنا Express.js، وفي وضع منظم باستخدام نمط DI - nest.js.

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

لا يزال غير كافٍ؟ على غرار مشاركة التعليمات البرمجية بين تطبيقات الويب وتطبيقات الهاتف المحمول، يمكن للواجهة الخلفية مشاركة الموارد مع كل من الأولى والأخيرة. الكلمة الأساسية التي يجب استخدامها هنا هي TypeScript - من بين أمور أخرى، فهي تسمح لنا بمشاركة قاعدة رموز، أي تعريف نوع بيانات مشترك بين جميع المنصات.

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

هل تستطيع JS تشغيل تطبيقات سطح المكتب؟

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

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

هل JS ناضجة بما فيه الكفاية؟

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

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

يوفر الكثير من موفري الخدمات السحابية حزم SDKs التي تتيح لك استخدام السحابة الطرق. الغريب في الأمر أن أحد أكثر علامات التبويب شيوعًا، بجانب C#، و جافاهو Node.js. اتضح أن هذه المنصة مثالية لتوسيع نطاق وبناء التطبيقات القائمة على الخدمات المصغرة أو البنية بدون خادم. الخلاصة - JS هي واحدة من أكثر اللغات شيوعًا لتطوير التطبيقات القائمة على الخدمات المصغرة/ البنية بدون خادم. في الشاشات أدناه، يمكننا أن نرى أن الثالوث المقدس (خدمات جوجل الحاسوبية وAWS وAzure) لمزودي الخدمات السحابية يسمح لنا ببناء التطبيقات باستخدام العقدة.js.

أما بالنسبة لنظام node.js البيئي، فغالبًا الجميع على دراية بمكتبة تُدعى express.js - إنها أداة بسيطة ومباشرة تسمح لك بتحديد المسارات ثم تغذيتها بالبيانات المناسبة التي تمت معالجتها بشكل صحيح من جانب JS. والأكثر من ذلك أن النمط المستخدم بين طلبات HTTP التي يتم التعامل معها في Express.js أصبح أحد أكثر الأنماط شيوعًا في النظام البيئي بأكمله وهو نوع من الأنماط لمختلف المكتبات الأخرى التي تستخدم، على سبيل المثال، البنية بدون خادم.

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

هل JS سريعة بما فيه الكفاية؟

حسنًا، المحرك الأكثر استخدامًا لتنفيذ شيفرة JS هو v8، وهو مدعوم بلغة C++. هذا المحرك الذي طورته جوجل مخصص لتشغيل التطبيقات لمنصات الويب. الشيء المثير للاهتمام هو أن هذا المحرك لا يفسر كود JS. بدلاً من ذلك، يقوم بما يسمى "JIT" - "التجميع في الوقت المناسب". بفضله لا يتعين علينا تفسير شيفرة JS سطراً بسطر، بل نقوم فقط بتجميعها وتنفيذها. إنه أسرع ويعطينا نتائج أداء رائعة حقًا.

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

لقد ناقشت بالفعل الأداء والمعايير بالتفصيل في هذه المقالة.

أليست لغة JS غريبة بين اللغات الأخرى؟

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

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

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

اخلطها كلها معًا

بجمع كل الفقرات معًا، يمكننا ذكر بعض الحقائق:

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

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

اقرأ المزيد:

لماذا يجب عليك (على الأرجح) استخدام Typescript

كيف لا تقتل مشروعاً بممارسات الترميز السيئة؟

استراتيجيات جلب البيانات في NextJS