Podcast (osim_software_feed): Download
הורדת הפרק (mp3)
איך מרגיש מתכנת שצריך לזרוק קוד לפח? איך הוא מרגיש שזה קורה כל כמה חודשים? האם מדובר על משהו רע או דווקא בריא שצריך לחגוג?
בפרק השני של עושים תוכנה אירחנו את אריק גלנסקי המקסים מ-HiredScore. אריק הוא בין העובדים הראשונים של HiredScore , סטרטאפ שקיים כבר 5 שנים, ומתפקד בו כ-VP Technology.
אומרים שסטרטאפ הוא רכבת הרים אבל לא תמיד מדברים על איך המתכנת הבודד מושפע מכך…מה הוא מרגיש? איך הוא מתמודד עם רכבת ההרים בצד הפיתוח? אריק והצוותים בחברה עברו לא מעט פעמים בהם היו בטוחים שמה שהם כתבו היה נהדר אבל גילו לפתע שהחברה צריכה עכשיו משהו אחר כדי להתקדם!
בואו להקשיב לסיפור המרתק שהמתכנתים עברו וללמוד בעצמכם לא מעט!
האזנה נעימה,
חן ועמית.
פרקים נוספים
רשימת תפוצה בדוא"ל | iTunes | אפליקציית אנדרואיד | RSS Link | פייסבוק | קבוצת עושים תוכנה
לאריק גלנסקי,
הדרישה שלך לכיסוי התוכנה בטסטים אוטומטיים לא חדשה, וקיימת בצורה מסודרת בהרבה אירגונים:
ראשית ישנם אנשי סיסטם שתפקידם האמיתי לכתוב דרישות ברורות וחד משמעיות, וכמובן טסטביליות. הדרישות אמורות לכסות את כל האספקטים של: "מה המוצר או הפיצר עושים (לא איך הם עושים זאת – זה שייך לאימפלמטציה). בד"כ אנשי הסיסטם מגדירים את הארכיטקטורה (כל מערכת היא בעצם מורכבת מתתי מערכות (ריקורסיה עד עומק סופי)… אז בד"כ הסיסטם נוגעים ברמה הראשונה או השניה – טופ דאון).
את הדרישות המוסכמות שזה OUTPUT של הסיסטם נותנים לשני לקוחות: לפיתוח כמובן, ולקבוצת ה QA.
הפיתוח מממשים – אבל חופשיים ב "כיצד לממש" (מלבד API או ממשקים לDB או כל קומפוננטה חיצונית להם), והם נמדדים לפי היעילות והביצועים – מעבר לרובסטנס.
אנשי ה QA לוקחים את אותם דרישות למגדירים וממשים את הטסטים לדרישות ברמת בלק בוקס (יתכן וחלק מהדרישות על קומפוננטות יועברו לפיתוח – אם הם דרישות ברמת הקומפוננטה – אבל הQA חייבים לנהל את מערכת הטסטים).
אני חולק על כך שאנשי הפיתוח גם כותבים את הטסטים כיוון שהם משוחדים: במימוש הם חשבו על סנריוז מסויימים אבל אדם חיצוני (כמו אנשי QA) אולי יחשוב עם דייברסיטי גדול יותר.
כל מה שכתבתי נקרא מודל ה V – למי שמכיר.
וכמובן אוטומציה גם של ביצוע הטסטים וגם של האנליזה שלהם… כי בחשיבה חיובית עתידית – אם המוצר ייצא לבטה גדול ויגיעו כמויות של לוגים צריך לנתח אותם במערכת וה QA יקבלו כמות קטנה יותר של מידע – לאחר הניתוח האוטומטי.
בהצלחה
חיים רוכברגר
שני הפרקים מאוד נחמדים ומעניינים.
מה שכן בשני הפרקים חוזר עיניין הטסטים ולמרות שהמרואיינים מאוד תומכים בטסטים נראה שהגישה היא שלכתוב טסטים לוקח יותר זמן בטווח הקצר ולכן אין טעם לעשות אותם בפרוייקט נסיוני או כשיש לחץ של זמן.
מהניסיון שלי זה בדיוק ההפך.
נכון להרים סביבת טסטים לפרוייקט דורשת זמן אבל אחרי שמשקיעים את הזמן להרים סביבה כתיבת הטסטים עצמם חוסכת זמן כמעט מהפיצ׳ר הראשון.
בהתחשב בעובדה שכל מפתח מריץ את הקוד שלו לפחות פעם אחת לבדוק שהוא עובד וכנראה שאפילו בודק כל מיני מקרי קיצון וכאלה בצורה ידנית (למרות שיצא לי לעבוד עם מפתחי על שרק כתבו קוד בלי להריץ אותו מעולם וב90% מהמקרים זה עבד להם).
הבדיקות האלה לוקחות דקה שתיים לבדיקה, לראות שיש איזה טעות קטנה ומפגרת לתקן אותה וחוזר חלילה.
אם יש טסטים כל בדיקה כזו לוקחת שבריר שניה ויוצא שעם לכתוב את הטסט הזמן שלוקח עד שיש פיצ׳ר מוכן הוא לא הרבה יותר ארוך כי חסכת הרבה מהבדיקות הידניות שגם ככה עושים.
וזה עם מתעלמים מהחסכון בזמן בגילוי רגראסיות ובאגים שאולי לא קשורים ישירות לקוד שעובדים עליו באותו רגע
נכון יוני, ברגע שמתרגלים לזה כמו כל הרגל טוב לוקח הרבה פחות זמן.
הקושי הוא באמת להכניס את התפיסה לראש באופן קבוע ולא לחשוש ממנה
שיחה מעניינת.
שאלה לאריק גלנסקי מ-HiredScore והמוצר שלה. מאחורי כל המילים וה-AI וכ"ו, יש מערכת שאוספת מידע על המועמד ומדרגת אותו.
אפשר דוגמאות למידע המשתתף בדירוג?
תודה.
[מועמד עתידי המעוניין טו-האק-דה-סיסטם]
שלום מועמד 🙂
המידע העיקרי שקובע האם אתה מתאים הוא הרקע שלך מול דרישות התפקיד, ממש כמו בסינון ראשוני של בן אדם.
מה למדת, מתי ואיפה, במה עבדת, מתי ואיפה, באיזה תחומים הניסיון שלך וכמה ותק וכו'.
באמת מדובר על מערכת חכמה ולומדת – אז הדרך הטובה ביותר "טו האק דה סיסטם" זה ללמוד דברים, לצבור ניסיון רלוונטי ולהגיש מועמדות למשרות שאתה מתאים להן.
ואל תשכח – בסוף אתה תפגוש מראיין אנושי, אנחנו רק שם כדי לעזור לו להיות יעיל יותר – אם תגיע לפגישה איתו על בסיס שקרים – זה סתם יבזבז לשניכם זמן יקר.
היתרון בזה שהמערכת שלנו חכמה – זה שאתה לא צריך למלא את הקורות חיים שלך בבאזוורדס מיותרים. פשוט תכתוב באמת מה עשית – אנחנו כבר נבין מה זה אומר…
תודה רבה, פרק מעניין!
תודה מירון!