كيف يخيب لي Typescript وهل يستحق كل هذا العناء؟

قبل البدء ، أريد أن أذكر أنني من محبي TypeScript. هذه هي لغتي البرمجة الرئيسية لمشاريع الواجهة الأمامية على React ولأي عمل خلفي أقوم به في Node. أنا من أجل Typescript تمامًا ، ولكن هناك لحظات تزعجني وتريد أن أخبرها عن هذا المقال.

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

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

أي فريق تطوير ، بغض النظر عما إذا كان كبيرًا أم صغيرًا ، يكتب في TypeScript أم لا ، يستحق دائمًا الأمان:

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

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

TypeScript ليس نظام كتابة موثوقا به

أعتقد أن هذا قد يكون المشكلة الرئيسية في TypeScript ، لكن أولاً اسمحوا لي بتحديد أنظمة الكتابة الموثوقة وغير الموثوقة .

نظام قوي النوع

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

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

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

// Type 'string' is not assignable to type 'number' const increment = (i: number): number => { return i + "1"; } // Argument of type '"98765432"' is not assignable to parameter of type 'number'. const countdown: number = increment("98765432"); 

نظام نوع غير آمن

Typescript يُعلن بشكل صريح تمامًا أن الموثوقية بنسبة 100٪ ليست هي الغرض منه. حتى الرقم "غير المستهدف" في قائمة TypeScript "غير المستهدفة" ينص بوضوح على:

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

هذا يعني أنه لا يوجد ضمان بأن المتغير من نوع معين في وقت التشغيل. يمكنني توضيح ذلك مع المثال التالي المفترض إلى حد ما:

 interface A { x: number; } let a: A = {x: 3} let b: {x: number | string} = a; bx = "unsound"; let x: number = ax; // unsound axtoFixed(0); // WTF is it? 

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

لسوء الحظ ، يتم تجميع هذا التعبير دون أخطاء:

 axtoFixed(0); 

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

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

يتحدى TypeScript الحالة الحالية للأشياء من خلال القول بأن خفض التكاليف المعرفية عند استخدام الأنواع أكثر أهمية من الموثوقية.

أفهم سبب اختيار TypesScript لمثل هذا المسار ، وهناك رأي مفاده أن TypeScript لن يكون شائعًا للغاية إذا كانت موثوقية نظام الكتابة مضمونة بنسبة 100٪. هذا الرأي لم يقف أمام الاختبار - لغة دارت تكتسب شعبية بسرعة ، إلى جانب الاستخدام الواسع النطاق للرفرفة. ويقال إن موثوقية النوع هو هدف دارت.

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

لا يضمن TypeScript التحقق من أي نوع في وقت التشغيل

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

نظرًا لأنه لا يمكننا ضمان أي شيء في وقت التشغيل ، يمكن أن يحدث هذا بسهولة:

 const getFullName = async (): string => { const person: AxiosResponse = await api(); //response.name.fullName may result in undefined at runtime return response.name.fullName } 

هناك عدد قليل من المكتبات المساعدة مثل io-ts ، والتي تعد رائعة ، لكن هذا قد يعني أن عليك تكرار النماذج الخاصة بك.

اكتب مخيف أي وخيار صارم

النوع "أي" يعني "أي" ، والمترجم يسمح بأي عملية أو تعيين لمتغير من هذا النوع.

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

 export class Person { public _id: any; public name: any; public icon: any; 

يتيح لك TypeScript نسيان نظام الكتابة.

يمكنك كسر نوع أي شيء مع أي :

 ("oh my goodness" as any).ToFixed(1); // remember what I said about soundness? 

يتضمن الخيار الصارم خيارات برنامج التحويل البرمجي التالية ، والتي تجعل كل شيء أكثر موثوقية:

• --strictNullChecks
• --noImplicitAny
• --noImplicitThis
• --alwaysStrict

هناك أيضًا قاعدة eslint @ typescript-eslint / no-express-any .

توزيع أي يمكن أن يفسد موثوقية التعليمات البرمجية الخاصة بك.

استنتاج

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

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

يعتبر برنامج TypeScript رائعًا بفضل الدعم الجيد من IDEs مثل vscode ، حيث نحصل على تعليقات مرئية أثناء عملية الطباعة.


خطأ في TypeScript في vscode

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

اشترك في مطور Instagram الخاص بنا