מהו Full-Stack?

Full-Stack, להלן FS, הוא כינוי לאוסף היכולות הטכניות המרכזיות שמאפשרות לפתח מערכת תוכנה מודרנית מקצה אל קצה.
מדובר ביכולות של פיתוח ממשק המשתמש Front-End, להלן FE, ממשקים אחוריים Back-End, להלן BE ולעתים אפילו מבני נתונים DB.

הביקוש לתכניתני Full-Stack

אם בעבר, למעשה מתחילת עידן
ה-Client\Server, מגמת הביקוש של תוכניתנים הייתה למהנדסים בעלי התמחות יעודית כל אחד בתחומו:
BE או FE, הרי שבעשור האחרון אנו עדים למגמה הולכת וגוברת של ביקוש לתוכניתנים ורסטילים השולטים בכלל היכולות הללו.
כמובן שקשה יותר לאתר תוכניתנים כאלה: בהנחה שאיננו מעוניינים להתפשר על איכות ועומק המומחיות בכל תחום, הרי שמדובר בעומס ועקומת לימוד גבוהה משמעותית על התכניתנים, בסיס ידע שלא רק נדרש לרכוש אלא גם לתחזק.
במערכות תוכנה מודרניות מבוססת WEB מדובר בשליטה במגוון רחב של שפות תכנות ו-Frameworks.

יתרונות ניהוליים בפרויקט מבוסס מפתחי FS

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

שיבוץ כח-אדם

כל מנהל יודע, שאחד האתגרים הכי גדולים בניצול יעיל של כח-האדם הוא היכולת לנהל את השיבוץ וההקצאה של כח-האדם באופן מיטבי.
כל שגיאה או כשל בזה מתורגם מידית לשורה התחתונה – פגיעה ברווחיות. לעתים קרובות מנהלים קוראים לפעילות הניהולית הזאת ״שבץ-נא״. רק שהמשחק הזה, בצורתו הניהולית, הוא לא על נקודות אלא על כסף אמיתי ובמקרה זה תוכניתי FS הם קלף מנצח – בגלל הורסטיליות שלהם:
יש לך צורך בתכניתן למשימה מסויימת? יש לך תכניתן פנוי?
אם הוא FS סביר שהוא מתאים למשימה.
במקביל נפתרו 2 בעיות:
תקציב שנשרף מכך שיש תוכניתן זמין ללא משימות והתקדמות שנבלמת ממשימה חסרת איוש.

מיקוד ניהולי בנתיב הקריטי של הפרויקט

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

חסכון בעלויות אינטגרציה

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

  1. צד אחד, בדרך כלל ה-FE פונה ל-BE
  2. אם ההפעלה אינה תקינה שני הצדדים מחפשים את מקור התקלה.
  3. איתור מקור התקלה הינו תהליך מורכב מאוד לעתים וברור כי כאשר מדובר בתוכניתן יחיד שמבצע אינטגרציה ״עם עצמו״ מדובר בחיסכון משמעותי.
  4. לאחר איתור התקלה – עשוי להיווצר ״זמן מת״ של צד אחד בעוד השני מטפל בתקלה מצידו. אם מוסיפים לכך את סוגיית הניוד והשיבוץ, עשוי להיווצר עיכוב וחוסר יעילות מעריכית: אף אחד לא מבטיח שכאשר הטיפול בתקלה יסתיים הצד השני יהיה פנוי להמשך אינטגרציה. רצף אינטגרציה הוא מרכיב קריטי לאינטגרציה יעילה ואיכותית.

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

יותר איכות – פחות עלות

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

מה הלאה?

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

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת /  לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת /  לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת /  לשנות )

מתחבר ל-%s

%d בלוגרים אהבו את זה: