בחלק גדול מהמקרים תגלו כי אתם מסיימים את המשימה שלכם רגע לפני שריקת הסיום (כמעט כל חברה תרצה להוציא מכם את המקסימום וזה גורר דדליינים לחוצים), ולכן יקרה שתחושו תחושת פזיזות ותדלגו על שלבים חשובים רגע לפני סיום הפיצ'ר ושחררו לפרודקשן, מה שעלול להחזיר לכם את הפיצ'ר בפנים, אם זה מצד הקיו איי, code review, פרודקט ומי יודע מה עוד עלול לקרות שעובדים בפזיזות..
יש כמה כללים שיעזרו לכם מאד להוציא פיצ'ר מושלם, כלומר בלי באגים ובלי הערות של CR (חלום של כל מתמכנת – לא מתחייב אבל לשמה מכוונים🙌 ). להלן תשעת השלבים לבדיקת הפיצ'ר רגע לפני הסיום:
- קחו מספר דקות ועברו שוב על התכנון שלכם ועל האפיון, בדקו שעברתם על כל השלבים ואתם מוכנים, בדקו את הuse cases , מובייל , דסקטופ וכו..
- הריצו לינטר, אם אתם לא עובדים עם לינטר אתם בוודאי מפספסים המון דברים קטנים ומציקים שיכולים לחזור לכם כ comments מה code review וחבל.
- וודאו שהפורמטר עובד והקוד מיושר היטב
- חפשו בכל הקבצים console.log debugger , לפעמים נוטים לשכוח שורות של debugg. כמו כן אם אתם עם linter אז הוא יבדוק את זה עבורכם.
- להריץ build. חשוב מאוד להריץ build , תתפלאו כי יש לכם ליקויים בקוד שלא יעבירו build מה שישבור את הdeployment.
- פתחו PR וקודם כל תעשו לעצמכם קוד CR, אם אתם מעלים לסביבת DEV בלי PR אז הייתי מציע לכם לשים את עצמכם דווקא בשלב הזה, אם CR מגיע בשלב הזה אז תעשו את תעשו CR אחרון לבראנץ שלכם ורק אז תפתחו PR לבראנץ המיועד , בקיצור לפני שאתם מצרפים את הreviewer אתם עושים CR לעצמכם.
- unit test – לא תמיד קורה, אבל אם אתם כן כותבים טסטים אז כמובן להריץ טסטים ולראות שהטסטים עוברים.
- פיצ'ר פלאג – אם אתם עובדים עם FF אז וודאו שאכן הגדרתם פיצר פלאג והוא אכן עובד בהתאם לתנאים הרצויים (קורה ששוכחים , בטח אם אתם לא רגילים לעבוד עם FF. וזה בהחלט יציל אתכם במידת הצורך)
- mini demo – מיני דמו יכול להתבצע עם ראש הצוות שלכם וגם הפרודקט בלבד, אפשר גם אחד מהם, המטרה לעבור על הפיצר ולקבל אישור כללי שאכן המשימה בוצעה. מעולה לעשות זאת אפילו בשלבי אמצע במידה וסיימתם איזה חלק שלדעתכם כדאי שפרוקדט או ראש צוות יראה ויסכים אתכם שזה בהתאם לדרישה. לפעמים אנשים נוטים לוותר על ההצגות הללו או ממתינים לdemo אבל mini demo יכין אתכם היטב לדמו וגם יחסוך רגעים מביכים. מדובר בפגישה של 10 דקות סהכ. אל תמתינו יותר מידי במידה והפרודקט עסוק, אז פשוט תתפסו את הראש צוות לכם.
בלתמים עם סיום הפיצר
פרודקט שכח
תתפלאו לגלות כמה בלתמים יצוצו לכם דווקא בסיום העבודה, (בישראל זה נראה לי עוד יותר נפוץ חח). פתאום יגיע הפרודקט וישאל שאלה מוזרה "למה זה לא מקפיץ עוד פופ אפ" (או משהו הזוי אחר). חשוב שתהיו בקיעים בחומר כך שלא יצליחו לבלבל אתכם, אם עבדתם לפי השלבים לרוב הפרודקט יבין לבד שהוא לא הגדיר את זה באפיון והוא פתאום קלט שחסר משהו. אין סיבה להתרגש, הסבירו לו שאפשר להוסיף את זה כמשימה נפרדת.
קונפליקטים
אולי אחד הדברים היותר שנואים זה קונפליקטים, לפעמים הם קטנים וקל להתמודד איתם אבל לפעמים הם כואבים מאד. במידה ויש קונפליקטים, עדכנו את הראש צוות שלכם, דברו עם מי שעשה את השינויים שנוגעים בקבצים שלכם וסדרו את הקונפליקטים. לאחר סיום הקונפליקטים, עברו שוב על השלבים 2-8 . כמובן שיישרו את הבארנץ שלכם וטפלו בקונפליקטים אצלכם בבראץ ואז תעלו PR מסודר לסביבה המרכזית ובקשו PR.
קיבלתם אישור? עדיין לא אומר שסיימתם עם הפיצר
אז QA אישרו לכם וגם עברתם את הCR ואתם מוכנים לעשות merge ולהתקדם למשימה הבאה. אבל עדיין לא תוכלו לשחרר לגמרי. חשוב מאד לעקוב אחרי הdeploy ולראות שהוא לא נשבר מסיבה לא צפויה, וגם לאחר שהכל עבר ועלה לסביבה הראשית, תעשו בדיקה ותראו שהפיצר שלכם אכן מנגן כמו שצריך. וכמובן מזכיר כי תמיד לעדכן בטיקט , מעבר לסטטוס וassign למי שצריך . תרשו בטיקט הערה מתאימה כמו "עלה לפרודקשן" ותייגו את ראש הצוות שלכם והפרודקט (במידה והם לא follow בטיקט) על מנת להסב להם רגע של אושר 💓 .
סיכום פוסט סיום פיצר מה עושים
מתכנתי פרונטאנד יקרים, כל הכבוד שאתם יסודיים, נסו לשמור על יסודיות וסדר בעבודה, זה לא קל, אך תתעקשו על עקרונות אלו ככל שתוכלו, ועם הזמן זה יהפוך להרגל שלכם והפיצרים יתחילו לזרום (חלום של כל מתכנת). כמו כן אני בטוח שישנם כלים נוספים שיכולים לסייע לכם בתהליכם הללו, וכן כל מקום עבודה עם השיטות שהוא רואה לנכון לעבוד איתם. אני מצאתי את השיטות הללו עובדות טוב וגם יעילות. נסו שיטות אלו ושלבו אותן בעבודה שלכם, ואם ישנם שיטות נוספות שאתם מכירים , אשמח אם תרשמו בתגובות. פוסט הבא סוף סוף נפתח IDE ונכין את סביבת העבודה האולטימטיבת.
בהצלחה 🐊😎.
