עם כל היופי של המקצוע הנחשק הזה שנקרא "מתכנת" , אנחנו עדיין עובדים קשה, ממש כמו עובדי בניין בונים תוכנה. וכמובן שיגיעו אליכם הרבה בקשות, הרבה טענות וגם דברים שיסתרו אחד את השני. למשל יכולים לבקש ממכם לעשות איזה שינוי קטן של איזה אייקון ואחרי זה גם יבואו ויגידו לכם למה שיניתם וזה יהיה אשמתכם לא משנה כמה תנסו להסביר. לכן, יש כמה דברים שאני ממליץ שתכירו על מנת למנוע מצבים לא נעימים שבסופו של דברים אתם תהיו אשמים בהם
לדעת להגיד לא אבל תנו את התחושה שהכל אפשרי.
להגיד לא זה מאד חשוב, אך גם יכול להתצייר כי אתם לא רוצים לעבוד או לא מסוגלים לעשות (בטח אם מישהו אחר אמר כן על אותו הבקשה שאתם סירבתם) ולכן צריך לראות מתי זה עשוי להתאים. אנחנו לרוב נרצה לסרב לבקשות שאינם מקצועיות, למשל אם מנהל מבקש ממכם שינוי עיצובי, ברור שתסרבו כי הוא אינו הגורם המקצועי לכך , שיעביר את זה דרך המעצב, ושיחזור טיקט בהתאם מהפרודקט
בפגישה שלכם עם הפרודקט על פיצר חדש , בה תקבלו את ההסברים על הפיצר, אם יש משהו שלא ניתן ליישם (אסביר כמובן), יש להעלות זאת, לפעמים המעצבים עושים שינויים קלים ברכיבים קמיים, ואם יש רכיב שמשתמשים בו באפליקציה וצריך לשנות אותו פתאום, זה ישנה אותו בכל המקומות, מה שיכול לגרום לבלגן כמו כן , אם תעשו את השינוי ספציפית בפיצר הזה, ישנה אפשרות שיהיה חוסר התאמה בשפה העיצובית וכן קוד מיותר ייעודי לפיצר הזה, אפשר אולי לתת וורסיה נוספת לרכיב ולהוסיף את זה ברכיב עצמו , כמו כן זה מקור לצרות, הרימו דגל במקרה כזה, אמרו שזה לא אפשר לשנות את הרכיב כי זה ישנה בכל המקומות השונים, אם זה מה שמקובל והוחלט על יהיה צוות הפרודקט , אין בעיה, תיישמו את זה וציינו בטיקט שמדובר בשינוי רוחבי עבור רכיב זה.
תנו תחושה שהכל אפשרי. אם אתם מרגישים שיש איזה מתח בשיחות עם המנהלים, כי חסמתם אותם בכך שאמרתם "לא" על מספר פיתוחים שונים שהם רצו לעשות, הסבירו להם כי הכל אפשרי ואפשר לפתח כל מה שהם יבקשו, אבל יש לזה מחיר ומחובתך היא להעלות זאת כי אנחנו אלו שחיים את השטח ולפעמים יש ליישר את הפרודקט ולהסביר להם שישנם דברים לא אפשריים כי יש לוגיקה אחרת שמונעת זאת ולשנות עכשיו הרבה לוגיקה לא תמיד תיהיה משתלמת ותתפלאו לגלות כי זה ישרת אתכם וגם יהפוך את הפרודקט ומבינים יותר ויצירתיים יותר בפתרונות שלהם, כמו כן במידה ואמרתם לא, אם יש לכם רעיון יצירתי אחר איך לממש שכן יכול להיות בחשבון, אל תהססו להציע.
שום סמכות לא יכולה לנהל אתכם מלבד הראש צוות שלכם.
כמובן שברגע שיבינו שאתם בעלי מוטיבציה גבוהה יגיעו אליכם בקשות רבות, כמו פגישות, או תיקונים או משימות פתאום שבכלל מגיעות מהשווק ולא חסר מאיפה יגיעו הבקשות. זה מאד נחמד ומחמיא, אבל למען הסדר הטוב, הפנו את כל הבקשות שלכם למקום אחד שיעשה לכם סדר וזה גם תפקידו, וזה הראש צוות שלכם, כל נסיון שלכם לסייע מתוך מקום של אכפתיות יבטל את ראש הצוות שלכם ואתם לא מעוניינים שזה יקרה, אתם לא רוצים "לעקוף" אותו ובטח שלא בטוח שאתם בנויים לסדר משימות בצורה הגיונית כי ראש הצוות שלכם עם תוכניות אחרות בשבילכם לעתיד הקרוב. ולמען הסדר והשקט הנפשי שלכם, תנו לראש צוות שלכם לדעת על מקרים כאלו.
חוזר ומזכיר, לתעד הכל במקום אחד – טיקט
אולי הדבר הכי חשוב בהתנהלות שלכם זה לתעד בטיקט. כך שהכל שקוף למנהלים למעלה גם אם יש נושא שקשור לאחריות של מישהו , לתייג אותו ולא לחשוש, אם הוא לא יאהב את זה, שירשום את דעתו בנושא בתגובה בטיקט כך אתם משקפים את סטטוס העבודה שלכם וגם יש גורמים מעכבים ומי אחראי להם.
דדליין ואי עמידה בדדליין
דדליין היא מילה גסה. רובנו הגדול לא אוהב דדליין, אבל במציאות שלנו הכל מסתמך על זה, וחשיבותו עליונה מכל. התייחסו אליו כך. זה משעשע מאד שמישהו ניגש אליי ואומר לי "תן לי הערכה של זמנים" שכן פתחתי את הfigma. לרוב אני אומר בין שנה לשנתיים סתם בקטע מצחיק כי זה לא באמת יכול לעבוד ולגזור לא זמנים, ותתפלאו כי אם תענו לשאלה הזו תשובה שנראית הגיונית עוד ימדדו אתכם על כך. תשובתכם המקצועית יכולה להיות " תוך X זמן (נגיד יום) יהיה לי הערכת זמנים ואציין זאת בטיקט".
כפי שכבר ציינתי בפוסט הקודם איך לגזור זמנים, הדדליין שאתם נותנים זה דדליין שאתם מחוייבים עליו , קודם כל לעצמכם. ואם לא תעמדו בו , מה שיקרה, זה שתצטרכו להזיז אותו, וכדאי מאד שבשניה שאתם מזהים שהולך להיות עיכוב, אז תשנו, אם לא תשנו בכלל זה יהיה חוסר מקצועיות מוחלט וככל הנראה תגידו לסוף הספרינט עם leftovers מה שאתם לא רוצים שיקרה כי זה בסופו של דברים אומר למנהלים למעלה שאתם under delivered אבל אם אתם מעדכנים בעוד מועד , הנזק קטן בהרבה, כי מה שיקרה, ראש הצוות שלכם יבין שעליתם על משהו ויש איזה עיכוב שהיה קשה לצפות בהתחלה והוא יזיז לכם את שאר המשימות בבורד שלכם וכך שהסיכוי שתגיד לסוף הספרינט עם leftovers נמוך בהרבה.
קומיטים מסודרים! יצילו אתכם בגדול.
יש מקומות שמודדים אתכם לפי קומיטים שאתם עושים. ידעתם את זה? מוזר מאד אבל יש כאלו, לא כי משעמם להם, כי יש חשיבות לקומיטים ורוצים לדרבן אתכם לעשות יותר קומיטים, אבל זה יכול ליצור בעיה שתעשו יותר מידי קומיטים בלי שום ערך אמיתי, לכן נשים רגע את נושא המדידה של התפוקה שלנו ונתייחס לערך האמיתי של קומיט טוב.
אז כפי שאתם יודעים אבני הבניין של עבודה בגיט הם הקומיטים, כל קומיט מציין נקודת זמן ומצב של הקוד בנקודה זו, כל קומיט מספק את המידע: מתי נוצר הקומיט, מי עשה את הקומיט והודעה (message) כאשר עובדים בצוות וכל אחד עושה merge מהברנץ שלו למאסטר והענף הזה למעשה מכיל את כל הקומיטים של כולם. ואם יש איזו בעיה מסיבה כלשהיא, יהיה יחסית קל למצוא את הקומיטים שעלו באותה עת ולמצוא איזה בארנץ נכנס ואיזה קומיט יכול להיות הגורם לבעיה, כמו כן ניתן לחזור לקומיט ספציפי עד ידי פקודה:
git checkout <commit hash>
אם תעשו קומיטים קטנים זה מאד שימושי ויציל אתכם שדברים הסתבכו. יצא לי לא פעם שדיבר איתי אחד הבחירים והתחיל לעבור איתי על הקומיטים שלי על מנת להבין מה עשיתי בטסק ולמזלי אני מסודר מאוד ומתאר מה אני עושה בכל קומיט וכך היה לו מאד קל התמצות בקוד שכתבתי עוד לפני שישב לקרוא את קוד, כמו כן ציין בפניי כי אני צריך לעשות יותר קומיטים. כל פעם שאני רשמתי משהו כמו
fix: fix the menu to close when click outside. and change the margin of the menu items
יש מצב שזה קומיט אחד כי הכל קשור לmenu אבל באיזה מקום יש צדק לפצל, עדיף שלא תרשמו את המילה and , מבחינת חלוקה לקומיטים נכונה יהיה עדיף שכל משפט יהיה קומיט נפרד ולא לחבר בין דברים למרות שזה נשמע דיי מוזר ולמה "לבזבז זמן" על זה. מאמין שזו דוגמה שכנראה תעבור ברוב המקרים אצל הרבה בכירים, וגם לא בכל מקום שמים דגש על זה, אבל זכרו כי קומיטים שמתארים יישום אחד יהיה אידאלי וכך גם יעריכו אתכם וגם יהיה קל יותר לפתור בעיות שיצוצו במידה וידרש ממישהו להתחיל לחפור בקומיטים על מנת לאתר זאת.
טיפול דחוף בבאג בפרודקשן שקשור אליכם, מה עושים ואיך מרגיעים את הרוחות
אחד הרגעים הכי דרמטיים במהלך חייו של מתכנת, זה הרגע שיש באג בפרודקשן והוא שייך לך. רגע קסום שיעלה לכם את לחץ הדם וזיעה תתחיל לזרום באצבעותיכם. האם יש באמת סיבה לחץ הזה? חד משמעית לא וגם יש פתרון.
עם כל הטירוף של המעמד, תקחו אחריות מלאה, קודם כל. זה הפיצר שלכם, זה באג שלכם. ברור שאתם יכולים להאשים אחרים, הרי יש בדיקות של QA יש אוטומציות ובדיקות קוד ומה לא עושים על מנת למנוע זאת והבכירים יודעים זאת ואם תראו להם שאתם יכולים לקחת אחריות מלאה אתם תקבלו את כל הגב לטפל בזה בקצב שלכם. ברור שישאלו אתכם למה זה קרה וינסו להבין איך הגענו למצב הזה, ברוב המקרים תגלו כי היה איזה רול או סט הגדרות אחר שאף אחד לא חשב לבדוק אותו, וזה בדיוק מה שהבכירים רוצים לאתר ולשפר. כמו כן בגלל שמדובר בפרודקשן , אם אתם לא עובדים עם פיצר פלג ואז פשוט היו מכבים את הפיצר ונגמר הסיפור, תוכלו להסתיר את הכפתור (אם מדובר איזה חיווי ספציפי) או להשמיט איזה קומיט קטן ולדחוף על מנת למנוע מיוזרים לקבל שגיאות ברגע הנתון. ואז אצלכם, (בנחת כמובן) לחזור אחורה בקומיטים ולאתר מאיפה מגיע הבאג. או אם צריך להוציא את כל הפיצר מתוך מאסטר ולחזור לבראנץ שלכם ולטפל ,ולהעביר לבדיקות שוב עם הקייסים החדשים שככל הנראה לא נבדקו אחרת לא הייתם מגיעים למצב זה.
סיכום קורס front end שיעור קשיי העבודה בארגון
הגענו לסיום הפוסטים מלאי ההסברים והתוכן, ומעכשיו הפוסטים יהיו בפרקטיקה ומטודולוגיות עבודה . אך היה מאד חשוב לציין עקרונות והבהרות על האגרון, כי זה הבסיס להכל. מכאן יהיה יותר נכון להתקדם ולהתמקצע וללמוד על הכלים ושיטות בעבודה שיסייעו לכם. אציג בהמשך כלים שאני מצאתי וראיתי לנכון לאמץ, שעזרו לי באופן אישי. אחרי הרבה זמן בתחום אני רואה לנכון שכל מפתח פרונט צריך להסתובב עם כלים שיעזרו לו לעבוד ביעילות וכן כלים אלו לרוב מוכנים ומיושמים בחברות השונות ומי שעוד לא אימץ ככל הנראה יאמץ בהמשך (או אולי יאמץ אותם בזכותכם , זה גם קורה).
