هل نحن حقا بحاجة إلى TypeScript في عام 2020؟

أصبح TypeScript أحد المهارات الأساسية لمطور الويب الحديث. في عام 2019 ، دخل إلى أكثر 10 لغات استخدامًا على GitHub ، وتم إضافة دعمه بالكامل إلى تطبيق Create react ، ويمكنك العثور على الكثير من الأدلة الأخرى على تزايد شعبيته. في الوقت نفسه ، تستمر لغات مثل Java و C في التراجع .

عندما نتحدث عن فوائد TypeScript ، فإن القائمة التالية عادة ما تتبادر إلى الذهن:

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

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

نظرًا لأن الهدف الرئيسي من TypeScript هو تقليل عدد الأخطاء ، فلنقرر سبب أهمية ذلك؟ الجواب بسيط: كلما قل عدد الأخطاء - الوقت الأقل تكلفة الذي نقضيه للمطورين والمُختبرين ، فسنحصل على منتج مفيد مقابل نقود أقل وسيبدأ في توليد الدخل في وقت مبكر.

مع وضع ذلك في الاعتبار ، دعنا نعرف كيف يمكن لـ TypeScript مساعدتنا في تحسين إنتاجيتنا وكفاءتنا.

الكتابة الساكنة - لوحة سحرية للأخطاء؟

الميزة الرئيسية لـ TypeScript هي دعم الكتابة الثابتة. هناك اعتقاد واسع النطاق بين المطورين بأن الكتابة الديناميكية هي مصدر جميع المشكلات التي يواجهها مطورو JavaScript تقريبًا.

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


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

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

هل رمز TypeScript أسهل في القراءة؟

فيما يلي مثالان لـ Redux Thunk:

const getUsers = async dispatch => { //... try { const users = await APIService.get('/users') dispatch(successGetUsers(users)) } catch(err) { dispatch(failedGetUsers(err)) } } 

ونفس الشيء على TypeScript:

 const getUsers = (): ThunkAction<void, {}, {}, AnyAction> => async (dispatch: ThunkDispatch<{}, {}, AnyAction>) => { //... try { const users: User[] = await APIService.get('/users') dispatch(successGetUsers(users)) } catch(err) { dispatch(failedGetUsers(err)) } } 

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

لن يكون هناك المزيد من الأخطاء الدقيقة؟

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

اتباع أفضل ممارسات OOP

كما نعلم ، يجب أن نتبع أفضل الممارسات إذا أردنا كتابة تعليمات برمجية عالية الجودة وقابلة للتطوير بسهولة ويمكن صيانتها. و TypeScript يمكن أن تساعدنا في هذا. هذا يبدو رائعًا ، لنلقِ نظرة على مثال من Express:

userRoute.js

 router.get('/users', (req, res) => { //get users from DB res.json(users) }) router.post('/users', (req, res) => { //create user res.json(userCreated) }) 

userRoute.ts

 class UserRouter { public router = express.Router() public address = '/users' constructor() { this.initRoutes() } initRoutes() { this.router.get(this.address, this.getUsers) this.router.post(this.addressm this.createUser) } getUsers(req: express.Request, res: express.Response) { //get users from DB res.json(users) } createUser(req: express.Request, res: express.Response) { //create user res.json(userCreated) } } 

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

عندما قام المطورون بالتصويت لصالح لغات بسيطة ومرنة وديناميكية مثل JavaScript و Python ، عندما أظهر نموذج البرمجة الوظيفية ميزاته وقدرته على حل بعض المشكلات بشكل أكثر أناقة وكفاءة (وفي JavaScript يمكننا استخدام كلا النهجين) ، يدفعنا TypeScript إلى لكتابة الكود بالطريقة القديمة في أسلوب OOP Java و C #.

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

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

أراه مثل هذا:

حسنًا ، لم نعد نريد جافا بعد الآن ، بل نريد جافا سكريبت. لكننا لا نحب جافا سكريبت كما هي ، لذلك دعونا نجعلها تشبه جافا. عظيم ، الآن لدينا كل ما كان في جافا ، وهذا ليس جافا. دعنا نذهب!