תלות בקוד היא השטן.

התלות שלך תשרוף אותך בכל פעם.
"השינוי הוא הקבוע היחיד ..." - הרקליטוס (פילוסוף)

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

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

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

לאחר 20+ שנים של פיתוח, תכנון וארכיטקט של יישומי אינטרנט, יצא לי להעריך שתי אמיתות חשובות:

  1. תלות חיצונית מהווה איום גדול על היציבות והכדאיות לטווח הארוך של כל יישום.
  2. יותר ויותר קשה - אם לא בלתי אפשרי - לבנות כל סוג של אפליקציה לא טריוויאלית מבלי למנף תלות חיצונית.

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

חור הארנב עמוק מאוד.

אם נתחיל לחשוב על כל הדברים שיישומי האינטרנט שלנו תלויים בהם קל לחשוב על תריסר או יותר לפני שאנחנו בכלל מגיעים לקוד:

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

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

בקוד ישנם שלושה סוגים של תלות:

1. תלות שאנו שולטים בהן

זהו קוד שנכתב ובבעלותנו או על ידי הארגון שלנו.

2. תלות שאיננו שולטים בה

זהו קוד שנכתב על ידי ספק צד ג 'או קהילת תוכנות קוד פתוח.

3. תלויים לאחר הסרתם

אלה תלות בקודים שתלותי הקוד של צד שלישי תלויים בהם. (תגיד שלוש פעמים מהר!)

אנו נדבר בעיקר על תלות שאיננו שולטים בהן.

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

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

מדוע תלות בקוד של צד שלישי טובה

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

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

אתה רוצה להתרכז בקוד שפותר בעיה לא שכיחה או פותר בעיה שכיחה בדרך לא שכיחה. זה מה שהופך את היישום שלך לבעל ערך: הקוד המיישם את הכללים העסקיים הייחודיים לאפליקציה שלך בלבד - "הרוטב הסודי."

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

קוד צד שלישי - בצורה של ספריות - מאפשר לך ליישם במהירות את התכונות המסומנות של האפליקציה שלך, כך שתוכל להישאר ממוקד ב"רוטב הסודי "שלך.

מדוע התלות בקוד של צד שלישי גרועות

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

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

אל דאגה, בסוף מאמר זה תמצאו תקווה חדשה.

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

לקוח לשעבר שלי בנה את האפליקציה שלהם באמצעות ספק Backend-as-a-Service בבעלות פייסבוק, שנקרא Parse. הם השתמשו בספריית לקוח JavaScript שסופקה על ידי Parse כדי לצרוך את שירות Parse. בתהליך, הם קישרו בחוזקה את כל הקוד שלהם - כולל קוד הרוטב הסודי - לספריה זו.

שלושה חודשים לאחר השקת המוצר הראשונית של הלקוח שלי - בדיוק כשהתחילו להשיג משיכה טובה עם לקוחות אמיתיים ומשלמים - Parse הודיעה שהיא נסגרת.

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

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

איזון הטובים והרעים

לפני מספר שנים הפיתרון שלי להתגברות על הסיכונים תוך שמירה על היתרונות של ספריות של צד שלישי היה לעטוף אותם באמצעות דפוס המתאם.

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

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

תרשים דפוס מתאם מ- Dofactory.com

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

אתה יכול לדמיין שאתה צריך לעטוף את כל ספריית ה- React (כולל JSX) לפני שתשתמש באחת מהן? מה דעתך לעטוף jQuery, או Angular, או את מסגרת האביב ב- Java? זה הופך במהירות לסיוט.

בימינו אני ממליץ על גישה יותר ניואנסת ...

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

  1. הסבירות שהתלות תשתנה באופן חומרי.
  2. כמות הנזק ששינוי מהותי בתלות תגרום ליישום שלך.

סביר להניח כי ספריה או מסגרת של צד שלישי ישתנו כאשר חלק מהדברים הבאים או כולם נכונים:

  • זה קיים מספר שנים ויש לו כמה מהדורות מרכזיות.
  • משתמשים בה ביישומים מסחריים רבים.
  • יש לו תמיכה אקטיבית של ארגון גדול - רצוי חברה או מוסד שמות משק בית.

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

  • זה משמש רק לחלק קטן מהיישום שלך ולא לשימוש בכל הדרך.
  • הקוד התלוי בו אינו חלק מאותו "רוטב סודי" עליו דיברתי קודם.
  • הסרתו דורשת שינויים מינימליים בבסיס הקוד שלך.
  • כל היישום שלך קטן מאוד וניתן לכתוב אותו במהירות. (היזהר עם זה - זה לעיתים רחוקות נכון לאורך זמן רב.)

ככל שמשהו מסוכן יותר, סביר להניח שעליך לעטוף אותו או להימנע ממנו לחלוטין.

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

לפעמים זה אומר להגיד "לא" לספריה של צד שלישי שאתה חושב שהיא ממש מגניבה, או שאתה באמת רוצה להשתמש מסיבה זו או אחרת. להיות חזק. תאמין לי, זה ישתלם. רק תשאלו את כל האנשים שהשקיעו רבות במהדורה הראשונה של Angular, או הלקוח הקודם שלי שהשתמש בפרס בכל מקום. זה לא כיף. תאמין לי.

אם מדברים על כיף, תסתכל על זה ...

גרף תלות עבור Explorer TinyTag

התמונה למעלה היא גרף התלות עבור יישום בשם TinyTag Explorer.

יצירת גרף תלות עבור היישומים הקיימים שלך היא דרך נהדרת להבין את רמת הסיכון שמוצגת על ידי התלות שלך. הרכבתי רשימה של כלים חינמיים להפקת גרפים דומים לאמור לעיל במגוון שפות כולל JavaScript, C #, Java, PHP ו- Python. אתה יכול להשיג את זה כאן.

עזור לי לעזור לאחרים

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

לבסוף, אל תשכח לתפוס את רשימת מחוללי הגרפים התלויים בחינם כאן.