TDD בסטרטאפים

zaske

New member
TDD בסטרטאפים

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

האם יש לכם Integration tests?
CI/CD?
באיזה שלב של הסטרטאפ הרמתם את כל זה?

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

ושאלת בונוס לעונים -
באגים שקשורים למערכות מבוזרות עם כמה nodes - כמה מהבאגים האלה לדעתכם אפשר לשחזר בסביבה של 3 nodes או פחות, באחוזים? (אני הופתעתי מאוד מהתשובה).
 

vinney

Well-known member
את המחקרים האלה עושים כבר עשורים.

זה לא סוד שככל שהבאג מתגלה יותר מאוחר כך עלות הטיפול/נזק מזנקת בצורה אקספוננציאלית. כולם יודעים את זה, ועדיין לא רק בסטארטאפים (ובטח ששם...), TTM אלה ראשי תיבות החשובים הרבה יותר מTDD...
&nbsp
"כמה מהבאגים האלה לדעתכם אפשר לשחזר בסביבה של 3 nodes או פחות" - תלוי בבאג. ברוב המקרים אפשר לשחזר על כמות קטנה של nodes. במקרים מסויימים מספר nodes באמת משמעותי לשחזור הבאג, ואז זה יותר קשה (אפשר לעשות סימולציות וכו').
 

Rשף

New member
אתה יודע שמדובר על מחקר משנות השישים?

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

vinney

Well-known member
יש יותר ממחקר אחד בנושא

זה לא בדיוק משנה באיזו שיטת ניהול פיתוח אתה משתמש. זה שככל שהמרחק בין הכנסת הבאג לתיקונו בגאנט הפיתוח גדל כך גם עלות התיקון - זאת עובדה די בלתי מעורערת. עד כמה גדלה עלות הפיתוח ואם זה באמת אקספוננציאלית - על זה אפשר להתדיין, אבל גם ההגיון הבריא שלך יגיד לך שאם אתה מתקן באג מיד עם כתיבתו בקוד זה יהיה כנראה הרבה יותר פשוט (=זול) מאשר גילויו באתר הלקוח והוצאת גרסת חרום.
&nbsp
"אז לפעמים בהחלט עדיף לרוץ קדימה ולתפוס נתח שוק מאשר לצאת מאוחר עם מוצר טוב יותר" - זה בדיוק מה שאמרתי, הTTM חשוב יותר מהTDD. ואני כבר ראיתי מפתחים (ומנהלים) חוסכים על כל נושא הטסטים ומוציאים מוצרים בלי שום בדיקות בכלל (פרט לבדיקות ידניות של מפתחים) והמוצרים האלה היו "בפרודקשן" במשך שנים על גבי שנים. רק שהאיכות הייתה ירודה, ונתח השוק נתפס לא בגלל איכות המוצר אלא בגלל גורמים אחרים (התניה במוצר אחר, מונופול בשוק, וכד'). סטארטאפים שמוציאים זבל לשוק העיקר לצאת מהר - לפעמים מצליחים, אבל הרבה יותר נכשלים ממצליחים כי משתמשים שנכווים על המוצר הגרוע הראשני עלולים שלא לחזור בכלל ליצרן הזה - כי יש הרבה דגים בים.
 

zaske

New member
אתה צודק בהסבר שלך לגבי הבאגים בסביבה מבוזרת

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

רמז: צדקת ב"רוב".

אגב,
במחקר הם עברו על מאות באגים (עם לא יותר) בכמה וכמה פרוייקטי אופן סורס.
 

vinney

Well-known member
חוכמה בדיעבד זאת החוכמה הכי טובה

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

ipv6

Member
זה מוגדר היטב..

A distributed system is a model in which components located on networked computers communicate and coordinate their actions by passing messages.[1] The components interact with each other in order to achieve a common goal.

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

choo

Active member
זו תמיד שאלה של עלות מול תועלת

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

zaske

New member
אתה צודק לגבי "דמיון" כותבי הבדיקות

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

ההערה שכתבת על הדיבאגביליות היא חשובה.

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

bismark1

New member
השאלה מה מטרת הטסטים

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

choo

Active member
המטרה של בדיקות באופן כללי היא לדעת מתי הקוד פועל נכון

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

bismark1

New member
אני מסכים

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