תשתיות פיתוח – מה זה ולמה חשוב להכיר את זה גם אם לא עובדים בחברה גדולה

ממש עכשיו התפרסם פרק בפודקאסט Front Cast עם אדיר קנדל וניר ארגיל ובו התארחתי כדי לדבר על נושא מאד קרוב לליבי: תשתיות פיתוח. מאד מומלץ להאזין לפרק הזה! בפוסט הזה אני כותב קצת מעבר וגם מביא כמה קישורים בנושא תשתיות ומדבר גם על הסיכונים.

תשתיות – האם רק לחברות ענק?

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

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

מה זו תשתית פיתוח?

תשתית פיתוח זה כל מה שאפשר לשכפל אותו מפרויקט לפרויקט או ממפתח למפתח ומסביבה לסביבה.

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

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

רובד נוסף הוא ספרית קומפוננטות – כשכאן יש כמה רמות. יש כאלו שיעדיפו לבנות מאפס ספרית קומפוננטות. יש כאלו שיעדיפו לעטוף ספרית קומפוננטות. יש כאלו שיסתפקו ב-theming מעל ספרית קומפוננטות.

רובד נוסף הוא שכבת בדיקות משותפת – למשל service mock משותפים.

יש עוד שפע של דברים שמרכיבים תשתית. כאשר יש לנו גם יתרונות וגם חסרונות.

היתרונות של שימוש בתשתית פיתוח

היתרון המרכזי הוא מהירות ואחידות – כאשר יש תשתית טובה, אפשר לייצר תוצרים מהירים מאד בזמן מועט ובאיכות יוצאת דופן. קשה להבהיר בטקסט עד כמה זה אפקטיבי ויעיל. אבל כאשר יש תשתית חזקה, השמים הם הגבול. תחשבו למשל על next.js. היום אנחנו יכולים להריץ אפליקציה סופר מורכבת, עם SSR ודיפלוימנט בדקות. כל מה שצריך לעשות זה להכניס את ה business logic וזהו. אם אני משתמש בתשתית של ספרית קומפוננטות, אני גם מקבל עיצוב אחיד של כל מוצרי החברה.

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

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

מה החסרונות של תשתיות?

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

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

החסרונות הם גם חוסר במידע ובדוקומנטציה והרבה hidden lore בכל מה שקשור לתשתית. במיוחד פנימית. אם יש לי שגיאה בתשתית כמו React Material UI למשל, אז כנראה שאני אמצא את הפתרון באמצעות גיגול מהיר, שאלה לקופיילוט/צ׳אטג׳יפיטי/ה-LLM החביב או אפילו התייעצות עם מתכנתים מקבוצות מקצועיות. אם יש לי שגיאה בתשתית ahla-bahla-infra שצוות הפלטפורמה של החברה שלי פיתח, אני אהיה בבעיה. אם אין דוקומנטציה טובה אפילו LLM עם קונטקסט לא יעזור לי.

לפעמים תשתית קשוחה מדי גם גורמת למעקפים שמתכנתים עושים כדי לזוז מהר ולהרבה shadow IT שמתקיים. למשל מתכנתים שינסו לבטל את הלינטר שאוכפים בחברה כי יש בו כלל מעצבן ולא הגיוני, ספריות קומפוננטות מפוארות שלא משתמשים בהן בכלל לצד ספריות פיראטיות של יוזמות מקומיות וכמובן הסבר מתחת לרדאר של איך לעשות no-verify– כדי למנוע commit hooks מעצבנים.

פתרונות

דיברנו על המענה לבעיות האלו בפודקאסט – בגדול יש כמה דרכים להתמודדות עם הסיטואציות האלו שקורות בכל חברה – הראשונה היא שימוש ב inner source, כלומר אפשרות לתת לכל אחד אפשרות לתרום לקוד של התשתית/לדוקומנטציה ואפילו למדוד את צוות הפלטפורמה/מי שאחראי על התשתית על בסיס זה. אפשרות שניה היא שימוש ב-tech radar כדי להבין מתי הבסיס של התשתית שלנו מתחיל להתיישן ולראות איך משדרגים אותו (זה בכלל טוב גם אם אני עובד לבד). מה שחשוב הוא להיות גמישים, למשל כן להסביר איך לדרוס את הלינטר הכלל חברתי איפה שצריך. איך לכבות צעדים ספציפיים ב-CI איפה שלא נדרש ובגדול כן לתת גמישות. עדיף שימוש חלקי בתשתית מאשר עקיפה שלה.

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