האם המושג ״פול סטאק״ הוא רלוונטי?

[מחפשת עבודה17]

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

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

אבל עם כמות החבילות שקיימות כיום בשוק וקצב ההתקדמות המהיר שלהן - האם באמת אפשר להתמקצע כ״פול סטאק״ בצורה טובה ומלאה? או שלרוב מדובר על מישהו שמכיר צד אחד של הפיתוח (סרבר או קליינט) בצורה טובה ומלאה - ופשוט מכיר באופן שטחי גם את הצד המשלים מבחינת עקרונות וטכנולוגיה?

 

[קלייטון.ש]

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

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

 

[מחפשת עבודה17]

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

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

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

 

[קלייטון.ש]

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

שפות לא יכולות להוות הבדל. גם אם לא נבחר לעבוד בשני הצדדים ב-JS, עדיין ההבדל בין שפה כמו PHP או C# שמקובלות בצד שרת, ל-JS או TS לצד לקוח, הוא לא כזה שצריך בשבילו "התמחות". איזו צורה יש למתכנת שאומר "אני יודע PHP אבל לא JS"? אם הצלחת ללמוד PHP מה בדיוק עוצר אותך מללמוד JS?
גם בצד לקוח אפשר להשתמש במסד נתונים, indexedDB. ההבנה במסדי נתונים צריכה להיות נחלתו של כל מתכנת. מתכנת שאומר "אני יודע רק SQL" נכנס לאותה קטגורה שאין לה צורה. יש SQL ויש NOSQL ועוד מגוון שיטות לשמור נתונים. יכול להיות שבאמצע הפרויקט יחליטו לעבור מזה לזה, וצריך להיות מסוגלים ללמוד הכל.
(תכנון ממשק משתמש, או במושג הפלצני UX, זה באמת מקצוע אחר עם יכולות אחרות, אם רוצים לעשות אותו מסודר. בכל מקרה זה לא שייך לתכנות. לא צריך לדעת לתכנת בשביל להחליט איך מסדרים נתונים לתצוגה למשתמש. צריך לדעת לכתוב את הקוד שעושה את זה, ואת זה צריך לדעת בשני הצדדים, גם בשרת וגם בלקוח)

 

[user32]

ההבדל הוא בסביבה מולה מפתחים. בקליינט הפיתוח הוא במנוע דפדפן, בשרת הפיתוח הוא מול שרת ווב. זה משפיע על סגנון הקוד, החשיבה, דפוסי פיתוח, סטנדרטים מקובלים וכו'. בקליינט משתמשים הרבה בתכנות דקלרטיבי, בסביבה שהיא stateful ללא horizontal scaling, כמעט ללא persistence ובסביבה שהיא single threaded. בשרת המצב הפוך.
זה כמו להגיד שפיתוח לצ'יפ real time זה אותו דבר כמו כתיבת חנות באינטרנט.

 

[קלייטון.ש]

ההבדל הוא בסביבה מולה מפתחים. בקליינט הפיתוח הוא במנוע דפדפן, בשרת הפיתוח הוא מול שרת ווב. זה משפיע על סגנון הקוד, החשיבה, דפוסי פיתוח, סטנדרטים מקובלים וכו'. בקליינט משתמשים הרבה בתכנות דקלרטיבי, בסביבה שהיא stateful ללא horizontal scaling, כמעט ללא persistence ובסביבה שהיא single threaded. בשרת המצב הפוך.
זה כמו להגיד שפיתוח לצ'יפ real time זה אותו דבר כמו כתיבת חנות באינטרנט.

מה שכתבת פה הוא לא נכון, וגם אם היה נכון לא היה מצדיק יצירת "התמחות" בצד אחד ולא השני. מתכנת צריך לדעת להשתמש הן בתכנות דקלרטיבי והן פרוצדורלי גם אם "החשיבה" היא שונה. החשיבה שונה אבל שייכת לאותו מקצוע.
גם בצד שרת וגם בצד לקוח יש מחשב וצריך להגיד לו מה לעשות. יש כלים שונים והיום אפשר להשתמש באותם כלים (ולא רק JS תחת node, יש גם WASM ואפשר לכתוב בכל מיני שפות ולקמפל לריצה בדפדפן), אבל זה לא אומר שאם המתכנת מכיר כלי אחד אז הוא לא יכול וצריך להכיר כלים נוספים.
זה לא נכון שבצד לקוח צריך עקרונית להשתמש בשפה דקלרטיבית (איזו, HTML? ריאקט?). אפשר גם בצד לקוח לבנות הכל ב-JS או בכל שפה שמתקמפלת אליה. שמירה או אי שמירה של ה-state יכולה להתבצע בשתי הגישות גם בשרת וגם בלקוח. בפירוש אפשר וביישומים מסויימים הכרחי לשמור בסיס נתונים (ולכן persistence מלא) בצד הלקוח. כמו שכתבתי למעלה באמצעות indexedDB אפשר לשמור בצד לקוח בסיסי נתונים רציניים, וזה גם הכרחי אם רוצים PWA. אותו דבר בשרת, אפשר לשמור מצב ואפשר לעבוד ללא מצב. וגם לערבב. תלוי ביישום.
לא יודע מאיפה לקחת שבצד לקוח עובדים דווקא עם נים יחיד. יש WORKERS ורצוי מאד להעביר אליהם כל עיבוד מתמשך. ב-Node הם לא ממליצים לעבוד עם WORKERS, ממה שהבנתי, אבל זה דווקא צד שרת.
לא נכון שבצד שרת עובדים דווקא בריבוי נימים. אפשר אבל זה לא מחוייב בכלל. נכון שהשרת עצמו, אפאצ'י למשל, פותח נים לכל בקשה, ובתוכו מריץ את הקוד. אבל המתכנת לא מתעסק בזה. מבחינתו כמפתח הקוד שלו הוא בן יחיד.
בשורה התחתונה זה שיש בהנדסת תוכנה גישות שונות לפתרון בעיות, שפות שונות, טכניקות שונות, וכיוצא בזה, לא אומר שמתכנת טוב יכול להגיד שהוא מתמחה בגישה X ולא יודע גישה Y. לא יודע תלמד. כמו שלא נסכים שמתכנת יגיד שהוא יודע להשתמש רק ב-if ולא מכיר case. גם גישות שונות לפתרון בעיות דומות.

 

[user32]

אחלה. אתה תכתוב פרונט עם workers וללא HTML, תשמור את הכל בindexedDB ותתעלם מהת'רדס שרצים בשרת. אני לא אומר שלא עושים את זה, רק שיש שיטות מקובלות ומוסכמות וברוב המקרים מפתחים לפי השיטות הללו. וכן, יש קליינטים עם DB, ויש אנדרואיד ואייפון ויש local storage, ויש אפליקציות קליינט דסקטופיות עם DB פנימי או מערכת קבצים. וnode בשרת הוא single thread, בדרך כלל עם פרוקסי LB מקדימה שמנתב לכמה פרוססים, ויש workers בדפדפן שעובד טוב למשל עם עיבודי 3D בOpenGL וכו' אבל לא רק. ואפשר להשתמש בווב אסמבלי, ויש גם קוד נייטיב שמוזרק לדפדפן ופלאגאינים אחרים, בטח אם אתה כותב כלי ריגול למשל, ויש מצב אפילו לדחוף קוד מכונה לקליינט המסכן.
ואפשר בכיף לכתוב שרת ששומר סטייט במשתנים גלובליים, זה אפילו עובד טוב כל עוד מדובר במכונה בודדת שלא צריכה להסתנכרן עם אחרות ולא אכפת לך מריסטארטים.
אבל יש מוסכמות שרוב המפתחים כותבים לפיהם. כבר הבהרת בעבר שאתה מוכן לעבוד על קוד רק בסגנון האישי שלך ולכן לא אתפלא בכלל אם הסטנדרטיים של מי שמכונה "פולסטאק" לא מקובלים אצלך.

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

 

[קלייטון.ש]

אחלה. אתה תכתוב פרונט עם workers וללא HTML, תשמור את הכל בindexedDB ותתעלם מהת'רדס שרצים בשרת. אני לא אומר שלא עושים את זה, רק שיש שיטות מקובלות ומוסכמות וברוב המקרים מפתחים לפי השיטות הללו. וכן, יש קליינטים עם DB, ויש אנדרואיד ואייפון ויש local storage, ויש אפליקציות קליינט דסקטופיות עם DB פנימי או מערכת קבצים. וnode בשרת הוא single thread, בדרך כלל עם פרוקסי LB מקדימה שמנתב לכמה פרוססים, ויש workers בדפדפן שעובד טוב למשל עם עיבודי 3D בOpenGL וכו' אבל לא רק. ואפשר להשתמש בווב אסמבלי, ויש גם קוד נייטיב שמוזרק לדפדפן ופלאגאינים אחרים, בטח אם אתה כותב כלי ריגול למשל, ויש מצב אפילו לדחוף קוד מכונה לקליינט המסכן.
ואפשר בכיף לכתוב שרת ששומר סטייט במשתנים גלובליים, זה אפילו עובד טוב כל עוד מדובר במכונה בודדת שלא צריכה להסתנכרן עם אחרות ולא אכפת לך מריסטארטים.
אבל יש מוסכמות שרוב המפתחים כותבים לפיהם. כבר הבהרת בעבר שאתה מוכן לעבוד על קוד רק בסגנון האישי שלך ולכן לא אתפלא בכלל אם הסטנדרטיים של מי שמכונה "פולסטאק" לא מקובלים אצלך.

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

המוסכמות שלך (קבע אותן מי שקבע, אני לא מכיר אותו) תוקעות אותך ואת מי שחושב כמוך בטכנולוגיה מיושנת. אתה מאשים אותי כאילו שאני המצאתי ריבוי נימים בדפדפן, אני המצאתי את ה-indexedDB ואני המצאתי את ה-WASM. בשביל מה כל ההתקדמות הטכנולוגית הזו בפיתוח ווב בצד לקוח, אם יש מוסכמות שמונעות שימוש בה? בשביל מה כל ההתקדמות ב-V8 וב-JS עצמו אם בצד לקוח כותבים רק HTML? משקיעים היום המון בפיתוח APIים שיפתחו את הדפדפן לעולם. ממשקים למערכת הקבצים של המחשב, ממשקים לחומרה. מה המוסכמות שלך יגידו על זה?
פיתוח תוכנה הוא לא דת ולא מועדון סגור. אין פה חוקים ואין כללים. עושים מה שצריך בשביל להצליח.
יתרה מכך אם כולם עובדים לפי שיטה מסויימת, שתוקעת אותם ביכולות מסויימות כי הם מסרבים לסגל את ההתקדמות בטכנולוגיה, אז דווקא מי שישבור את המוסכמות הוא שישיג יתרון לפחות טכנולוגי.

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

 

[user32]

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

 

[קלייטון.ש]

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

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

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

 

[user32]

רמת אמינות = 0

 

[קלייטון.ש]

רמת אמינות = 0

טוב. להבא הערותיך המחכימות יישארו ללא תגובותי.

 

[BravoMan]

יש לה מתחרים - אלא מהבחינה שזו מערכת וובית בעוד כל המתחרים הם מערכות שולחניות.

לא אמרת לפני רגע "זה מחשב וזה מחשב"?
אז ממה אתה מתלהב בדיוק?

 

[BravoMan]

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

אתה מזכיר לי אחד שאומר שהוא יודע "לבנות אתר" כי אפשר לשמור מסמך ב-WORD כ-HTML ...
נו, ברור, זה תוכנה וזה תוכנה

 

[Desslok]

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

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

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

מקצת מההבדלים:

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

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

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

- מסד הנתונים של שרת צריך לטפל במיליארדי בקשות, בעוד שבקליינט אחדות פעילות ואולי מאות או אלפים שמורות היסטורית. זה משנה לגמרי את סט הכלים וההבנה הנדרשת בהם. בקליינט אם אתה צריך קצת אחסון תמיד אפשר לעשות משהו לא הכי יעיל (גם בשטח וגם ב CPU), כי מי ירגיש? הקליינטים חזקים. אבל בשרת כל שומן כזה הופך לצווארי בקבוק שמצריכים עוד ועוד שרתים (שעולים כסף) ואולי קורסים בסוף. לא ניתן להגדיל שרת SQL ללא גבול ואולי באיזשהו שלב עוברים ל no-sql שמצריך חשיבה מחודשת על כל מבנה ה DB, האינדקסים שלו, הטבלאות, והקשרים ביניהן על מנת לייעל.

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

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

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

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

בשרת השתמשנו ב Java ו- ++C. בצד ה Java השתמשנו בספריה אסינכרונית שהיתה לי קשה ללימוד והבנה בשם RX Java על מנת שלא יהיו נעילות של משאבים קריטיים. שים לב: הסביבה מאפשרת לך לכתוב קוד אסינכרוני, היא לא הופכת קוד רגיל לכזה, היה צורך לשכתב חלקים גדולים של המערכת כדי להשתמש.

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

וזהו.

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

 

[קלייטון.ש]

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

מקצת מההבדלים:

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

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

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

- מסד הנתונים של שרת צריך לטפל במיליארדי בקשות, בעוד שבקליינט אחדות פעילות ואולי מאות או אלפים שמורות היסטורית. זה משנה לגמרי את סט הכלים וההבנה הנדרשת בהם. בקליינט אם אתה צריך קצת אחסון תמיד אפשר לעשות משהו לא הכי יעיל (גם בשטח וגם ב CPU), כי מי ירגיש? הקליינטים חזקים. אבל בשרת כל שומן כזה הופך לצווארי בקבוק שמצריכים עוד ועוד שרתים (שעולים כסף) ואולי קורסים בסוף. לא ניתן להגדיל שרת SQL ללא גבול ואולי באיזשהו שלב עוברים ל no-sql שמצריך חשיבה מחודשת על כל מבנה ה DB, האינדקסים שלו, הטבלאות, והקשרים ביניהן על מנת לייעל.

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

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

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

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

בשרת השתמשנו ב Java ו- ++C. בצד ה Java השתמשנו בספריה אסינכרונית שהיתה לי קשה ללימוד והבנה בשם RX Java על מנת שלא יהיו נעילות של משאבים קריטיים. שים לב: הסביבה מאפשרת לך לכתוב קוד אסינכרוני, היא לא הופכת קוד רגיל לכזה, היה צורך לשכתב חלקים גדולים של המערכת כדי להשתמש.

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

וזהו.

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

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

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

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

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

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

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

 

[BravoMan]

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

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

( )

 

[Desslok]

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

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

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

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

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

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

 

[קלייטון.ש]

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

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

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

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

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

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

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

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

 

[חזי2003]

תוכנת פסטה === קוד ספגטי?
#סליחה