הבלוג של ינון פרק

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

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

נו, אז בואו נדבר על כמה זה באמת עולה:

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

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

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

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

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

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

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

אני מקווה שאתם כבר מכירים את הסקריפט wait-for-it שגם מגיע עם דביאן וגם אפשר להוסיף בקלות להתקנה של כל קונטיינר ופותר בדיוק את הבעיה הזאת. ובכל מקרה אם המערכת שלכם כתובה ב Node.JS שווה להכיר שיש פיתרון יותר מוצלח שמשתלב באפליקציה והוא המודול wait-on.

מודול wait-on מאפשר לקבל רשימה של משאבים מכל מיני סוגים ויודע לחכות עד שכל המשאבים יהיו באוויר. הסוגים הנתמכים כוללים: קובץ, נתיבי רשת (http ו https), חיבור tcp וחיבור socket.

בהמתנה לקובץ התוכנית תמשיך רק כשהקובץ יהיה במקום שאתם צריכים אותו. בהמתנה לנתיבי רשת הקוד ישלח בקשת HTTP Head ויחכה לקבל תשובת HTTP 200, ובהמתנה ל tcp או socket הוא יחכה שיווצר חיבור. אפשר לשלוט גם בכל הפרמטרים של ההמתנה באמצעות אופציות שמעבירים לפונקציה ושווה להסתכל בתיעוד כדי לראות את הרשימה המלאה.

הנה דוגמה פשוטה לתוכנית Node.JS שמחכה ששרת redis יעלה על localhost ורק אז מתחברת אליו ומעלה ערך של מפתח בשם count:

const redis = require('redis');
const port = 3000;

const waitOn = require('wait-on');
const resources = [
  'tcp:localhost:6379'
];

waitOn({ resources }, () => {
  // here everything's ready
    console.log('ready!');

    const client = redis.createClient({
      port      : 6379,
      host      : 'localhost',
    });

  client.get('count', (err, count) => {
    if (err) return next(err);
    console.log(`count = ${count}`);
    client.incr('count', () => {
        client.quit();
    });
  });
});

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

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

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

ושנתיים אחרי, ב 2013, Nguyễn Hà Đông פירסם את פלאפי בירד וזכה להצלחה פנומנלית.

וב 2014 גבְּריאֶלֶה צ'ירולי פירסם את 2048 שהפך ללהיט ממכר.

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

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

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

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

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

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

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

השלב הראשון בפיתרון בעיה הוא להבין שאפשר לפתור את זה, אבל לא בטוח שבדרך שאתה רוצה.

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

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

אז אם אתם בכרום וה Dropdown שלכם ידידותי, למשל כמו זה שכאן: https://developer.microsoft.com/en-us/azure-devops/components/dropdown

תוכלו להיכנס לכלי הפיתוח, ללחוץ Ctrl+Shift+p ולבחור באפשרות Emulate a Focused Page. אפשרות זו גורמת ל Dropdown לחשוב שהוא עדיין בפוקוס ולכן להישאר פתוח, גם אחרי שלוחצים על כפתור ימני ו Inspect Element.

נ.ב. הטריק הזה לא עובד בכל מקום לדוגמה על react-select כאן: https://react-select.com/home לא הצלחתי לגרום לו לעבוד. בכל מקרה שווה לנסות אותו - יש סיכוי מסוים שהוא יחסוך גם לכם עבודה.

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

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

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

אני רואה רק שתי דרכים להתקדם:

1. אפשר לתקן את הבדיקות כדי שיעבדו עם הממשק החדש.

2. אפשר למחוק את הבדיקות ולכתוב בדיקות חדשות לממשק החדש.

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

סייפרס הוא ספריית בדיקות ה End-to-end האהובה ביותר על מתכנתי Front End היום ו testing-library היא ספריית ה Unit Test המובילה. הנה סיכום קצר של ההבדלים בין שני הדברים ובסוף המלצה במה כדאי להשתמש.

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

ואם היית חושב שזה חשוב, היית מסכים לקום שעה קודם כל יום בשביל לעבוד על זה?

ואם היית מבין שזאת ההזדמנות האחרונה, האם היית מוצא דרך לפנות שעה ביום בשביל לבנות את זה?

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

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

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

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

3. אם המחשב לא בשימוש אפשר לסגור את התצוגה.

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

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

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

רק בגלל שכתבת את המנגנון זה לא אומר שחייבים להשתמש בו.