כשהתחלתי את התואר שלי במדעי המחשב באוניברסיטת ת"א לא היה לי כל רקע קודם במחשבים ובכלל לא ממש הבנתי לאיזה עולם אני נכנס.
די מהר במהלך השנה הראשונה לאחר שיחות רבות עם חברי לתואר, הבנתי שאני רוצה להיות מתכנת. למה? בגלל שהבנתי שזה נחשב תפקיד טוב יחסית להתחיל ממנו ולשם כדאי לי לשאוף. כששאלתי מה מתכנת אמור לעשות? ענו לי באופן מתפתיע, הוא זה שכותב את קוד התוכנה.
אז לאחר כמעט 5 שנים בתחום אני מרגיש מספיק בטוח לאשר את הטענה הזו, מתכנת הוא זה שכותב את התוכנה. אך מה שלא ידעתי אז הוא שכתיבת התוכנה נעשית בכ 50-70% מזמן העבודה.
אז מה מתכנת עושה כשהוא לא מתכנת? על זה אף אחד לא דיבר איתי לפני שהתחלתי לעבוד ולגלות את הדברים האלו בעצמי. מה שגיליתי הוא שיש אתגרים רבים בלנהל מספר רב של מתכנתים על מנת שיפתחו יחד מוצר בצורה יעילה וחכמה. האתגרים הללו משותפים לכל חברה בעולם שמפתחת מוצר טכנולוגי.
6 אתגרים שמשותפים לכל חברה שמפתחת מוצר טכנולוגי
1. יש צורך לסנכרן את קבצי הקוד של המוצר בין כל המתכנתים כל הזמן - לדוגמה, נניח ש2 מתכנתים בצוות עובדים יחד על פיתוח המוצר, כל אחד על דבר אחר. אבל, יש קובץ קוד אחד ששני המתכנתים צריכים לעדכן בו שורות קוד. כמובן שאם לא יהיה סנכרון בין המתכנתים, בהחלט יתכן שכל אחד מהם ישנה את הקובץ לצרכיו הוא אבל "ידפוק" את מה שעשה המתכנת השני.
2. יש צורך בניהול של באגים. בכל מוצר טכנולוגי יש באגים (נקודה). אז איך מנהלים אותם? מי אחראי לתעד באגים שהתגלו אצל לקוחות? איפה כותבים את כולם? ואיך מחליטים איזו בעיה דחופה יותר ואת מי צריך לפתור קודם?
3. יש צורך בתקשורת שוטפת בין אנשי הצוות - פיתוח של מוצר תוכנה הוא דבר דינאמי, כל יום יכולות להתקבל החלטות שמשפיעות על אופן פיתוח המוצר, לדוגמה: שינוי סדר עדיפויות של משימות, טיפול במקרים דחופים אצל לקוח, התייעצות בין כמה עובדים למציאת פיתרון לבעיה במוצר.
4. יש צורך בניהול של פיתוח המוצר - כל מוצר טכנולוגי הוא מוצר שמתפתח באופן שוטף, כל הזמן צריך להוסיף לו יכולות חדשות, לשפר דברים קיימים לתקן באגים וכו'. איפה שומרים את כל המשימות שצריך לעשות בחצי שנה הקרובה, איך מחליטים מה עושים לפני מה, איך בוחרים מי המתכנת שיעשה כל משימה, ואיך מעריכים כמה זמן יקח לעשות על משימה? הרי בסופו של יום יש לקוחות שמחכים למוצר שיהיה מוכן ומישהו צריך לתת להם הערכה פחות או יותר סבירה של מסירת המוצר.
5. יש צורך בכתיבת קוד קריא - אם מתכנת מסויים התחיל לעבוד על משימה מסויימת אבל מישהו אחר צריך להמשיך אותה (כי המתכנת הראשון יצא לחופש \ עזב את החברה \ החליף תפקיד), באילו עקרונות פיתוח אפשר להשתמש על מנת שלמתכנת השני יהיה כמה שיותר קל להבין קוד שלא הוא כתב ולהמשיך לפתח את המוצר מאותה נק'.
6. יש צורך לשתף ידע בין כל אנשי הצוות - לכל חברה ולכל צוות בחברה, יש כמות גדולה של ידע שבזמן כזה או אחר יהיה רלבנטי לכל אחד מחברי הצוות. לדוגמה, לפיתוח מוצר תוכנה שעובד עם Data Base יש צורך בכל פעם שגירסת התוכנה מתעדכנת - להיכנס לשרת המרכזי של החברה, למחוק את הDB וליצור אותו מחדש. המתכנת הראשון שנתקל בבעיה הזו מבזבז שעתיים מזמנו כדי לפתור את הבעיה. לאחר שבועיים כשהבעיה חוזרת, אותו מתכנת שפתר אותה כבר לא נמצא, מה עושים? עוד פעם ילכו לאיבוד שעתיים של עבודה? אם המתכנת שפתר את הבעיה יקדיש עוד רבע שעה לשם תיעוד הפיתרון ושיתופו עם אנשי הצוות, בפעם הבאה שתחזור הבעיה יקח כבר זמן קצר מאוד לפתור אותה.
6 כלים שתצטרכו להכיר בעבודתכם הראשונה
1. source control \ version control - כל חברה שמפתחת מוצר תוכנה עושה שימוש בכלי לניהול וסנכרון קבצי הקוד של המוצר. בדר"כ מתארים את הכלי בשם source control או version control. הנה כמה דוגמאות ליכולות בסיסיות של הכלי הזה:
- אפשרות למספר רב של מתכנתים לעבוד על אותם קבצי קוד בו זמנית ולהיות מסונכרנים ביניהם כל הזמן.
- אפשרות לגבות גירסאות של המוצר, כלומר את כל קבצי הקוד, על מחשב מרוחק.
- אפשרות לחזור אחורה בזמן, למשל ביום ג' התגלה באג קריטי במוצר באופן פתאומי ואף אחד לא יודע מה המקור לבעיה. בעזרת ה source control אפשר לחזיר את כל קבצי הקוד למצב שהיו בו ביום א' ובכך להחזיר את המוצר למצב יציב וגם מהנק' הזו אפשר לנסות לעקוב אחר השינויים ולראות מה גרם לבעיה.
- אפשרות לשים חותמת stamp על כל קבצי הקוד כאשר גירסה יוצאת ללקוח. די דומה לדוגמה הקודמת רק שהפעם בהקשר של לקוחות. נניח לאחר חודשיים כאשר הצוות שינה כבר דברים רבים במוצר לקראת הגירסה הבאה, אבל לקוח פתאום מדווח על באג קריטי במוצר - ניתן לחזור אחורה בזמן, לשחזר את הבעיה ולמצוא את הפיתרון.
למי שהנושא של source control חדש לו אני ממליץ בחום לקחת חצי שעה וללמוד מעט על הנושא, זה יעזור לכם מאוד בעבודתכם הראשונה כמתכנתים. אתם יכולים להתחיל עם המאמר הזה.
2. ניהול באגים - כל חברה עושה שימוש בכלי כזה או אחר לניהול באגים. כל מתכנת צריך להיות מסוגל:
- להכניס למערכת באג חדש במקרה שהוא נתקל באחד כזה (וזה קורה לכל מתכנת לפחות פעם בשבוע)
- לקבל מהמערכת רשימה של באגים במוצר שרלבנטים עבורו לפי סדר עדיפויות על מנת שיוכל לעבוד על תיקונם.
- אפשרות לעדכן באג שקיים במערכת במקרה שהוא תוקן הוא שגילו עליו משהו חדש (קורה רק בזמן עליה ולא במערכת שכבר רצה למשל).
דבר שני, לפעמים אתם תכתבו מייל למי שיושב בחדר שלידכם, זה יכול להיראות טיפשי בהתחלה (ולפעמים זה באמת טיפשי) אבל יש מקרים שבהם נוח יותר לכתוב מייל, למשל: כדי שניתן יהיה לעקוב אחרי הנושא (הוא שמור בתוכנת האימייל), כדי לכתב אנשים נוספים שלא נמצאים בסביבתכם הקרובה וגם כדי לא להפריע לעבודה של מי שאתם צריכים ממנו עזרה, כך הוא יוכל לענות לכם כשיהיה לו נוח.
יש עוד דברים נוספים שאפשר להוסיף לנושא המיילים בתוך חברה אבל קצרה היריעה מלהכיל את כולם כאן.
4. כלי בקרת פיתוח המוצר - כאן הנושא הוא קצת יותר מורכב מכיוון שבחירת הכלי לניהול המוצר הוא חלק מבחירת גישת פיתוח המוצר, יש כל מיני אסכולות לדרך שבה יש לפתח מוצר טכנולוגי, ניתן לומר ש scrum היא הפופלרית ביותר. בכל מקרה, לא משנה מהי הגישה, כל חברה טכנולוגית עושה שימוש בכלי ניהול שמשמש אותה לפיתוח המוצר, לרוב האחראי על הכלי הוא מנהל המוצר. הנה כמה דוגמאות לשימוש בכלי:
- ניהול ה backlog - דבר ראשון, backlog זו רשימת ה features העתידיים של המוצר, בכל פעם שעולה רעיון להכניס יכולת חדשה למוצר על ידי לקוח או מישהו מתוך החברה - מכניסים את הרעיון לרשומה בתוך ה backlog.
- ניהול גרסאות - לכל מוצר טכנולוגי יש גרסאות. עבור כל גירסה יש לקבוע אילו features מתוכננים להיכנס אליה (מתוך ה backlog). התוכן של כל גירסה מנוהל מתוך הכלי הזה.
- ניהול משימות - לאחר שהוחלט אילו features יוכנסו למוצר בגירסה הבאה צריך לחלק את המשימות בין אנשי הצוות וכמו כן להעריך את הזמן שיקח לבצע כל משימה. כל התיעוד של זה נשמר גם הוא בתוך אותו כלי.
5. כתיבת קוד איכותי וקריא - זהו הסעיף היחיד שהוא לא באמת כלי אבל בכל זאת ראיתי לנכון להכניס אותו לכאן כי הוא עיקרון חשוב ביותר שתצטרכו גם כן ללמוד להכיר בעבודתכם הראשונה. עד שמתחילים לעבוד בחברה אמיתית, בדר"כ כל כתיבת תוכנה שאתם עושים היא במסגרת פרוייקט אישי או לכל היותר פרוייקט שמשותף ל3 אנשים.
בתוך חברה שבה יש מספר רב של אנשים שעובדים על אותו מוצר וגם עם הזמן מתחלפים האנשים באנשים חדשים - יש יתרון גדול מאוד למי שיודע לכתוב קוד קריא וברור. הכוונה היא שמעל כל פו' יש תיעוד של 3 שורות שמסביר מה היא עושה ולמה היא קיימת. ליד כל קטע קוד לא טריויאלי יש הסבר מילולי שמסביר בשפה פשוטה מה קורה שם. ובכלל כדאי קצת ללמוד ולקרוא איך כותבים קוד בצורה טובה.
6. Wiki - כולם מכירים את Wikipedia נכון? אז בכלי של ויקיפדיה שבו כל משתמש יכול להעלות דף על נושא חדש ולכתוב עליו או להמשיך דף קיים שמישהו אחר התחיל - כמעט כל חברה עושה שימוש באופן פרטי, על מנת לתעד את הנושאים הפנימיים בארגון שרוצים לשתף בין העובדים.
גם אתם תצטרכו לדעת לעבוד עם הכלי הזה. נניח למשל שהמערכת שלכם עובדת על Windows ואתם הייתם הראשונים שהצלחתם לגרום לה לעבוד על Linux. סביר להניח שהמנהל יגיד לכם להכניס עמוד חדש ל Wiki עם תיאור מפורט של הצעדים שעשיתם. בצורה זו, אם בעוד מספר חודשים מישהו יצטרך לחזור על אותו תהליך, יקח לו רבע מהזמן שלקח לכם. זהו כלי מצויין ליעילות ושיתוף מידע רלבנטי בין עובדים רבים שצריך להישמר בתוך הארגון בלבד.
לסיכום
להיות מתכנת זה לא רק לכתוב קוד מהבוקר עד הערב. כדי לעבוד בצורה נכונה ויעילה ביחד עם עוד אנשים רבים יש צורך בשימוש בכלים חיצוניים נוספים שיעזרו להתמודד עם האתגרים הרבים שעולים בזמן פיתוח המוצר.
זה נכון שכל זמן שתעבדו עם כל אחד מהכלים האלו זהו זמן שתיאורטית יכלתם לכתוב שורות קוד ולקדם את המוצר, אך בפועל, ללא שימוש בכלי הניהול הללו, אין סיכוי להצליח לפתח מוצר בצוות גדול לאורך זמן. אני ממליץ לכם לקחת קצת זמן ולקרוא מעט על כל כלי שלא הכרתם לפני קריאת הפוסט. אתם תגיעו הרבה יותר מוכנים לעבודתכם הראשונה אם תכירו, אפילו מעט, את כל הכלים האלו.
כמו תמיד, אני אשמח לענות בתגובות של הפוסט על כל שאלה שיש לכם ובכלל תרגישו חופשי לשתף את המחשבות והרעיונות שלכם עם קהל הקוראים של הבלוג.