נהלי פיתוח נוקשים

[יבגני34]

נהלי פיתוח נוקשים

יש אצלנו מפתח בכיר שהוא גם מגדיר את נהלי הפיתוח,
הוא בכלל שייך לצוות אחר אבל הקוד משותף ל-3 צוותים,
לאחרונה הוא הגדיר מחדש את נהלי הפיתוח, בעיקר קוד ריוויו וקוד קונבציה,
הכול מתועד ב-wiki שלנו,

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

 

[grishab]

אני שמח לראות שעוד נשארו מקומות שמנסים לעבוד נכון.

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

אתה צריך רק להודות על זה, זה יחסוך גם לך הרבה שעות עבודה מיותרות בעתיד.

 

[vinney]

הגיוני למדי. מה הבעיה?

 

[יבגני34]

הבעיה היא שאני חושב שזו התחלה של דיקטטורה על קוד

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

 

[vinney]

למה זה בעיה? זה מצוין.

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

 

[BravoMan]

סתם מתוך סקרנות:

היכן ראיתה פרויקט תוכנה שמתנהג כדמוקרטיה?
&nbsp
אפילו בפרויקטי קוד פתוח תמיד קיימת "דיקטטורה נאורה", ושום דבר לא נכנס לקוד לפני שהדיקטטור הראשי או מי מטעמו מאשר את זה.
&nbsp
כמובן, בניגוד לחברה מסחרית שם יש פרויקט אחד שחייבים לעבוד עליו, בעולם הקוד הפתוח מי שלא מסכים עם הדיקטטורה תמיד יכול לעשות Fork ולהפוך בעצמו לדיקטטור, אבל זה לא רלוונטי לשרשור הנוכחי.
&nbsp
אהבתי את הביטוי "אני לא חושב שהבאג משפיע בכלל על הבדיקות שעושים".
אם אתה חושב שהקוד עובד בסדר, בשביל מה לבדוק בכלל? באמת?
יש לך מושג כמה כסף יכולנו לחסוך אם אפילו 10% מהזמן הקוד היה עובד כמו שמי שכתב אותו חושב שהוא עובד?
&nbsp
תראה מה קרה אפילו ב-Google: לפני זמן מה גילו אצלם באג רציני בספריית פענוח ווידאו של Android.
הם קיבלו פאטצ'ים ושילבו אותם.
ומה מסתבר? אחד הפטצ'ים לא מתקן את הבאג. כלומר, הוא מתקן חצי - מטפל באפשרות overflow אבל משאיר את אפשרות ה-underflow פתוחה לגמרי.
&nbsp
אני לא בטוח אם ההודעה שאני משרשר אליה נכתבה ברצינות או בסרקזם, אבל עד כמה אתה חושב שאתה אלוף ולך זה לא יקרה?

 

[ipv6]

אין לכם טסטים אוטומטיים שאפשר להריץ?

בכל מקרה הבחור צודק.
הוא מכריח אתכם לעבוד נכון.

 

[nocgod]

בדיוק בשביל מפתחים כמוך בGo החליטו להעביר את הדיקטטורה לשפה

שם אין שאלות של:
"סוגר למעלה או למטה?"
"הelse בשורה של הסוגר או שורה חדשה?"
"פונקציה מתחילה באות קטנה או גדולה?"
"אז מה שלא משתמשים ב import הזה? הוא לא עושה נזק"
"אז מה שיש פה warning על משתנה שלא משתמשים בו? לא נורא זה מתקמפל"
אז רגע זה עם אות קטנה או גדולה, או אולי בכלל להוסיף קו תחתון?
"זה camelcase? אולי pascal? ואולי בכלל snake?"
"פרטי זה אות קטנה או גדולה? וציבורי?"

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

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

 

[יבגני34]

אני מפתח טוב, נשמע שאתה מזלזל

פשוט זה נראה לי להיות רס"ר
מישהו שהוא כביכול בכיר בפיתוח, הוא לא מנהל אף אחד,
והוא נכנס לעבודה היומית שלי עם סנקציות כאלה האחרות,
הוא בכלל לא בצוות שלי, אבל הקוד שלי נכנס גם לפרוייקט שלו,
יש לי ראש צוות, ונוצר מצב שהוא מחליט או החליט על דעת עצמו,
איך ייראה תהליך הפיתוח,
נכון שהוא מוביל טכנולוגי, אבל לא של הצוות שלי!
אני חושב שכדאי 'יתעסק בצוות שלו ולא יחליט שאם מפתחים אצלו ככה אז גם צוות אחר שתורם לפרוייקט צריך להתיישר על אותם נהלים,
אותי זה ממש מעצבן ואני בטוח שעוד כמה אנשים בצוות שלי חושבים ככה,
האם כדאי ללכת איתו ראש בראש?

 

[vinney]

טוב, נראה לי גם הכינוי הזה שרוף...

 

[royagol]

 

[Miki Watts]

האמת אתה צודק

למה מי הוא חושב לעצמו שהוא יגיד לך מה לעשות? אתה מתכנת! אתה צריך חופש יצירתי! למי אכפת מהמתכנתים האחרים שעובדים איתך! יאללה בלגן להשפריץ קוד!

 

[nocgod]

ברור כדאי ללכת איתו ראש בראש...

תן לו, כנס בו, תראה לו מי הבוס, מי לובש את המכנסיים בבית...
לדעתי, תעשה גם deface ל wiki שהוא פתח עם החרא תיעוד שלו...

 

[zaske]

לגבי שיתוף קוד

הייתי מוביל טכני/ראש צוות בקבוצת התשתיות שלנו במוצר.
הבוס שלי היה תמיד אומר לי -
"אתה מבחינתי שומר השער לא רק בקוד של התשתיות עצמן, אלא גם בשימוש ושעושים בהן שימוש נכון" , והייתי צריך לעשות לא מעט code reviews למי שהשתמש בקוד המשותף.
לא תמיד אולי הייתי מספיק פדנט, ועדיף להיות יותר פדנט מאשר לחטוף וואחד באג בפורדקשן.

 

[הייתיאביבקיץ]

הישג לא, רע, אבל שרפת את הניק מהר מדי

שני דיונים משעשעים, אחד מהם טבול בקצת גזענות קלילה.
הישג לא רע

 

[הפרבולה]

אני מבין אותך ,

ב 95% מהמיקרים של שינויי קוד לא אמורים להשפיע על דברים אחרים ו\או לקלקל דברים אחרים שכבר עובדים, ולכן זה די מיותר להריץ מחדש את כל הטסטים הכלליים שבודקים את כל\רוב הפיצרים של התוכנה, לכל היותר יש לבדוק את הפיצר\התיקון הזה בלבד.

הבעיה ש ב 5% מהממקרים של שינויי קוד כן עלולים להשפיע ואף לקלקל דברים אחרים שכבר עובדים ולא קל לצפות זאת מראש. ולכן כדי להיות על הצד הבטוח יש להריץ את כל סט הפקודות אחרי כל שינוי בקוד ואף זה שנראה קטנטן ביותר.

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

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


אגב למשל אם השינווים בקוד שבצעת הם רק בתיעוד ובהערות בתוך הקוד אז אפשר להסתפק בבדיקה פשוטה של השוואת קובצי תוצרי הקומפילציה עם הקבצים של הגרסה הקודמת הם אמורים להיות זהים כי השינויים שביצעת הם רק בהערות ( כך תבדוק שלא בטעות נגעתה בקוד אמיתי )

 

[אנטונו ריפה]

שורה תחתונה, משלמים לך כסף כדי לעשות מה שנדרש ממך.

אולי כבר כתבתי את הסיפור הזה כאן, אבל...

בעבודה הקודמת שלי תוכנה קטנה שכתבתי נפלה אצל הלקוח. מה שעשיתי הוא:

א. לקבל דיווח מרה"צ על הבאג.
ב. לקרוא את הטופס של אנשי התמיכה עם הדיווח על הבאג.
ג. להוריד את הקוב. ולשחזר אץ הבאג.
ד. למצוא workaround, ולהעלות אותו לטופס של אנשי התמיכה, כדי שיוכלו לדווח עליו ללקוח, וכל לקוח שאולי יתקל בו בעתיד.
ה. לתקן את הקוד, מה שלקח שורה או שתיים של קוד + הערה "מתקן את באג שדווח בטופס מספר X, נפל כי ככה וככה".
ו. לבדוק את הקוד החדש על שש פלטפורמות (XP, ויסטה, 7, כולן 32 ביט ו 64 ביט)
ז. להכניס את התיקון לבקרת תצורה.
ח. להוסיף את הקובץ ל test cases שצוות ה QA מריצים על הקוד
ט. להכניס תיאור של הבאג כדי שיכנס ל release notes (הקוד נופל עד גרסה X במקרה Y, הפתרון הוא לשדרג גרסה)
י. לסגור את הטופס, עם הסבר שתיקנתי את הבאג, והלקוחות יקבלו אותו בגרסה הבאה של המוצר.

התיקון הקטן ה לקח לי בערך שש-שבע שעות על שעון-קיר, שכללו הפסקה לארוחת צהריים.

למה? כי ככה חברה מסודרת עובדת - היא דואגת שהלקוחות יהיו מרוצים, ושהתכניתן הבא בתור לעבוד על חתיכת הקוד שלי יבין מה עשיתי.

 

[הפרבולה]

את מה שתארתה נוהגים לעשות לגבי תוכנה

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

 

[אנטונו ריפה]

בדיקה מראש יכולה לחסוך באגים אצל הלקוח

ברור שחלק מהבירוקרטיה פשוט לא קיימת בקוד שנמצא בשלבי פיתוח, כמו למצוא workaround ללקוח שאין.

עם זאת, code review יכול לחסוך באגים לאחר המסירה ללקוח, וזה תורם לא רק לחסכון בבירוקרטיה, אלא גם לתדמית של החברה, למכירות, ולשורת הרווח שלה.

תיעוד של חלק מהשינויים עשוי להיות בעל ערך, בדיוק בגלל שהצורך בהם אינו אינטואיטיבי, והיה צורך ב code review כדי לעלות על הצורך בהם.

 

[Lhuna1]

קוד ריוויו + קונבנציות = נהלים סטנדרטיים ברוב החברות שעבדתי

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