ניתוח סטטי

ניתוח סטטי הוא סוג של בדיקה שמספק בדיקה אוטומטית של בלי להריץ אותו בפועל או לכתוב בדיקה אוטומטית. היתרה סביר להניח שכבר ראיתם בדיקה כזו אם אתם משתמשים בסביבת פיתוח משולבת (IDE), כמו VSCode, בדיקה שמבוצעת על ידי TypeScript היא סוג של ניתוח סטטי, והיא יכולה להראות כקווים מסולסלים מתחת לשגיאות או לאזהרות.

ESLint

ESLint הוא כלי שיכול לספק משוב על בעיות אפשריות ב-codebase. הבעיות האלה עשויות להיות מסוגבטוחות,אבל שגיאות או התנהגות לא סטנדרטית בזכות עצמו. באמצעות ESLint אפשר להחיל כמה כללים שנבדקים את ה-codebase, כולל הרבה מהקודים ה"מומלצים" שלו הוגדרה.

דוגמה טובה לכלל ESLint היא no-unsafe-finally כלל. הדבר מונע ממך לכתוב הצהרות שישנו את תהליך בקרה בתוך בלוק finally. זהו כלל מצוין, כי ככה עושים את זה היא דרך לא שגרתית לכתוב JavaScript שקשה לעקוב אחריו. עם זאת, גם משהו שתהליך בדיקת הקוד אמור להיות מסוגל לזהות.

  try {
    const result = await complexFetchFromNetwork();
    if (!result.ok) {
      throw new Error("failed to fetch");
    }
  } finally {
    // warning - this will 'overrule' the previous exception!
    return false;
  }

לכן, ESLint הוא לא תחליף לתהליך בדיקה תקין (וסגנון שמגדיר איך ה-codebase צריך להיראות), כי הוא לא עומד כדי לתעד כל גישה לא אורתודוקסית שמפתח עשוי לנסות ליישם ל-codebase. במדריך 'שיטות עבודה טכניות' של Google יש קטע קצר בנושא 'שמירה על פשטות'.

באמצעות ESLint אפשר לשבור כלל ולהוסיף קוד בהערות כ'מותר'. לדוגמה, יכול לאפשר את הלוגיקה הקודמת באמצעות הוספת הערות כך:

  finally {
    // eslint-disable-next-line no-unsafe-finally
    return false;
  }

אם נתקלתם בהפרה קבועה של כלל, אולי כדאי להשבית אותו. האלה וכלים מעודדים אתכם לכתוב קוד בצורה מסוימת, אבל ייתכן שהצוות שלכם ישתמש לכתוב קוד בדרך אחרת ולהיות מודעים לסיכונים .

לסיום, הפעלת כלים של ניתוח סטטי ב-codebase גדול יכולה ליצור של רעש לא מועיל (ועבודה קשה של ארגון מחדש) בקוד שאחרת עבד בסדר. כך קל יותר להפעיל את התכונה בשלב מוקדם במחזור החיים של הפרויקט.

יישומי פלאגין של ESLint לתמיכה בדפדפן

ניתן להוסיף ל-ESLint פלאגין שמסמן את השימוש בממשקי API שלא נמצאים בתפוצה רחבה נתמך, או לא נתמך על ידי רשימת דפדפני היעד שלך. eslint-plugin-compat יכול להזהיר אתכם כשממשק API לא יהיה זמין למשתמשים, לא חייבים לעקוב כל הזמן בעצמכם.

בדיקת סוג לניתוח סטטי

במהלך למידת JavaScript, מפתחים חדשים בדרך כלל לומדים להכיר את הרעיון שזו שפה מקלידים בצורה חלשה. כלומר, אפשר להצהיר על בתור סוג אחד, ואז להשתמש באותו המיקום לישות כלשהי אחרת. היא דומה ל-Python ולשפות סקריפטים אחרות, אבל שפות מקודמות כמו C/C++ ו-Rust.

שפה כזו יכולה להתאים לתחילת העבודה, ויש טענות אפשריות של הפשטות שבזכותה JavaScript פופולרי כל כך — אבל לעיתים קרובות זו נקודת כשל עבור מסדי קוד מסוימים, או לפחות משהו שמאפשר לשגיאות מבלבלות קורה. לדוגמה, על ידי העברת number שבו string או סוג אובייקט היה צפוי, הערך שהוקלד באופן שגוי יכול להפיץ ספריות לפני בסופו של דבר גורם ל-TypeError מבלבל.

TypeScript

TypeScript הוא הפתרון העיקרי לחוסר ההקלדה של JavaScript מידע. בקורס הזה נעשה שימוש נרחב. אומנם זה לא קורס TypeScript, הוא יכול להיות חלק חשוב מארגז הכלים שלך כי הוא מספק ניתוח סטטי.

לדוגמה מהירה, הקוד הזה, שמצפה לקבל קריאה חוזרת (callback) שמקבלת השם של string וגיל אחד (number):

const callback = (name: string, age: string): void => {
  console.info(name, 'is now', age, 'years old!');
};
onBirthday(callback);

יוצרת את השגיאה הבאה כשמריצים אותה דרך TypeScript, או גם כשמעבירים את העכבר מעליה בסביבת פיתוח משולבת (IDE):

bad.ts:4:12 - error TS2345: Argument of type '(name: string, age: string) => void' is not assignable to parameter of type '(name: string, age: number) => void'.
  Types of parameters 'age' and 'age' are incompatible.
    Type 'number' is not assignable to type 'string'.

4 onBirthday(callback);
             ~~~~~~~~

Found 1 error in bad.ts:4

בסופו של דבר, המטרה של שימוש ב-TypeScript היא למנוע שגיאות כאלה. הגיל צריך להיות number, ולא string – שמצטברים לפרויקט. הזה לפעמים קשה לזהות טעות מסוג זה באמצעות בדיקות מסוגים אחרים. בנוסף, מערכת הסוגים יכולה לשלוח משוב עוד לפני שהבדיקה נכתבת. כך יהיה קל יותר לכתוב את הקוד ולקבל משוב בשלב מוקדם על שגיאות הקלדה במהלך פיתוח התוכנה, ולא מתי הקוד בסופו של דבר פועל.

החלק המאתגר ביותר בשימוש ב-TypeScript הוא הגדרה נכונה. הכול לפרויקט נדרש קובץ tsconfig.json, ואילו הוא משמש בעיקר את tsc כלי שורת הפקודה עצמו, נקרא גם על ידי סביבות פיתוח משולבות (IDE) כמו VSCode, וגם לפתח כלים וכלים, כולל Vitest. הקובץ הזה מכיל מאות ודגלים, ותוכלו למצוא משאבים טובים להגדרה כאן:

• מהו tsconfig.json
• המלצות מרוכזות לבסיסי TypeScript
• בדיקת ה-JS בעזרת TS

טיפים כלליים לגבי TypeScript

כשמגדירים את TypeScript ומשתמשים בו באמצעות קובץ tsconfig.json, חשוב לשמור את חשוב לזכור:

• מוודאים שקובצי המקור אכן כלולים ומסומנים. אם בקובץ באופן מסתורי, 'אין שגיאות', זה כנראה בגלל שלא בדקתם את זה.
• תיאור מפורש של סוגים וממשקים בתוך .d.ts קבצים, במקום שמתוארים במרומז בזמן שאתם כותבים פונקציות, את ה-codebase יותר קל לבדוק. קל יותר לכתוב לעגות ולזיופים גרסאות של כשהממשקים המעורבים ברורים. .

TypeScript מרומז

אחת מאפשרויות התצורה המתקדמות והמתגמלות ביותר של TypeScript סימון noImplicitAny. עם זאת, בדרך כלל קשה ביותר להפעיל את האפשרות, במיוחד אם כבר יש לכם Codebase גדול. (הדגל noImplicitAny הוא מופעל כברירת מחדל במצב strict, אך לא במצב אחר).

הדגל הזה יגרום לפונקציה הזו להחזיר שגיאה:

export function fibonacci(n) {
  if (n <= 1) {
    return 0;
  } else if (n === 2) {
    return 1;
  }
  return fibonacci(n - 1) + fibonacci(n - 2);
}

למרות זאת, בתור קורא, ברור למדי ש-n צריך להיות מספר, ל-TypeScript אין אפשרות לאשר זאת בביטחון. אם משתמשים ב-VSCode, מעבירים את העכבר מעל הפונקציה תתאר אותה כך:

function fibonacci(n: any): any

הקריאות לפונקציה הזו יוכלו להעביר ערך מסוג any (סוג שמאפשר כל סוג אחר), לא רק number. על ידי הפעלת סימון noImplicitAny, ניתן להגן על קוד מהסוג הזה במהלך הפיתוח, בלי שתצטרכו לכתוב בדיקות לוגיקה עסקיות מקיפות כדי שהקוד שלכם יעבור סוגי נתונים שגויים במקומות ספציפיים.

כדי לפתור את הבעיה הזו, פשוט מסמנים את הארגומנט n וגם את סוג ההחזרה של fibonacci בתור number.

הדגל noImplicitAny לא מונע ממך לכתוב באופן מפורש את any ב- ב-codebase, עדיין אפשר לכתוב פונקציה שמקבלת או מחזירה מסוג any. זה רק מבטיח שתציינו סוג של כל משתנה.