הספק

[tapas tapas]

הספק

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

 

[hg1979]

מה ההגדרה שלך לשורת קוד ?

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

 

[T i k t a k i t]

זה מדד יותר מעניין?../images/Emo13.gif

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

 

[hg1979]

זה תלוי בהגדרה של מהי שורת קוד

אפשר להתפלסף עד אחרית הימים אבל לדעתי בצורה המופשטת ביותר : לא שורת קוד : I = "myname"; i = 1; i+=1; שורות קוד : i = i + "myname"; i+=j; ואני מקווה שזה דיי ברור מה ההבדל

 

[אוֹריארד]

זה יעיל אם יודעים איך להשתמש...

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

LOC - lines of code SLOC - source lines of code CLOC - comment lines of code ELOC - Effective lines of code NCLOC - non-comment lines of code WLOC - whitespace lines DC - Density of Comments (DC = CLOC / LOC)​

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

 

[ייוניי]

25 שורות ביום

זה המדד שלי...

 

[ייוניי]

אגב

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

 

[hg1979]

זה רלווטני בעיקר למערכות מידע

שכותבים DRIVER לרכיב כלשהו זה דיי לא רלוונטי כי לרוב הדברים כותבים 2-3 גרסאות וזהו...

 

[ייוניי]

נכון

 

[אוֹריארד]

תשובה מ"שפות תכנות"../images/Emo26.gif

חפש למשל על COCOMO ו-COCOMO 2 (הראשון אפילו מבוסס על מספר שורות קוד כמו שציינת). המדד של שורות קוד בפני עצמו (כמו שפרסמת כאן בהודעה שלך) הוא כמו שהגיבו - לא אינדיקציה לכלום. לנו אין כלים להעריך אם זה הרבה או מעט, כי אנחנו לא מכירים את סוג העבודה שאתה עושה, את הסביבה, את התקנים... אם לדוגמה על כל קטע קוד שאתה כותב, אתה צריך גם לעשות design, להעביר מצגת DR, לתעד אותו פנימית וחיצונית, לכתוב לו test-ים וסימולציות ולמלא check-lists - אז סביר שהספק שורות הקוד שלך יהיה נמוך יותר משל מתכנת שכל היום טוחן קוד. לעומת-זאת, מספר שורות קוד יכול להיות מדד שימושי (אם כי לא אידיאלי) לראש-הצוות שלך למשל. אם הוא מכיר את אופי העבודה שלך, יכול להשוות את ההספק לאנשים אחרים בצוות שעושים עבודה דומה בתנאים דומים, ומכיר את איכות הקוד שלך (למשל - כי הוא עשה code-review וקיבל מצוות unit-test פידבק לגבי כמות השגיאות שנמצאו) - הוא יכול להפיק תועלת מהמדד של מספר שורות הקוד שכתבת. הבאתי כאן מקרים קיצוניים, אבל המסקנה היא שמצד אחד אסור לתלות את כל ההתרשמות במדד KLOC (אלפי שורות קוד) - אבל מצד שני, לא כדאי לזלזל לגמרי ולבטל אותו כלא היה.

 

[T i k t a k i t]

צוות unit test? תוכל

לפרט מה זה בדיוק? [האין הרעיון בunit testing שהמתכנת יכתוב אותם בעצמו וגם ירוץ אותם תוך כדי עבודה?]

 

[vinney]

לא בהכרח בכלל

תלוי איך מגדירים את זה. יש תורה שלמה איך לעשות UT, וזה בכלל לא קשור למתכנת, אבל בד"כ לא עושים את זה בבדיקות פורמליות, אלא עושים את זה כמו שתיארת (וחבל...)

 

[אוֹריארד]

תלוי...../images/Emo26.gif

מצד אחד, אם אתה כותב test-case שהוא black-box, כלומר - מתעלם מהמימוש של הפונקציה (/מחלקה/מודול) ובודק רק את תקינות המנשק - אז זה דווקא יתרון שכותב הבדיקות לא יהיה זה שכתב את הקוד. מצד שני, אם אתה כותב בדיקת white-box אז יש יתרון דווקא למי שמכיר את המימוש ויודע מה נקודות התורפה שלו. ואז הוא יתן קלטים שמביאים את הלולאות, התנאים וכו' למקרי-קיצון (וידאג לבדוק את כל ה-control-paths בקוד) - בשביל זה חייבים להתייחס למימוש של הפונקציה. מצד שלישי, צוות unit-tests ייעודי - מקבל קוד שכתב תוכניתן ועפ"י המימוש יכול גם הוא לבנות בדיקות white-box. התופעה של צוות unit-test לא מאוד נפוצה - היא צורכת לא מעט משאבים (=כסף). לכן בדרך-כלל תפגוש אותה בחברות ובפרוייקטים שעובדים תחת תקנים מגבילים ומחמירים של בטיחות ואיכות. לדוגמה - מערכות צבאיות, רפואיות וכד' שבהן כשל בתוכנה יכול להביא לפגיעה פיסית בבני-אדם... במקרים כאלה יש תקני-בטיחות שממש מגדירים לך סטנדרטים לקידוד ולבדיקות תוכנה. בחברות כאלה, יש הגיון בהקמת צוות מיוחד שזו ההתמחות שלו. הוא מכיר את הנהלים, מכיר את התקנים, הטכניקות והכלים שבבדיקות הקוד.

 

[שלמה שוורץ]

נשמע לגמרי לא רלוונטי

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

 

[arnonrgo]

שורות קוד כמדד

היום כבר לא כל כך משתמשים במדד של שורות קוד בפני עצמו (שיטות ישנות כמו COCOMO כן הסתמכו על זה) שיטות יותר חדשות להערכת תוכנה (כמו COCOMOII והנגזרות שלו) משתמשות בfunctional points או use case points (כאשר כמות שורות הקוד למימוש שונה משפה לשפה) אבל זה בד"כ להערכה של גודל פרויקט ןלא של הספק לגבי הספק מה שיותר חשוב זה התקדמות יחסית (יש הבדל גדול בין 10 שורות קוד בדוקות ומדובגות ל100 שורות קוד שלא ידוע עליהן כלום) אתה יכול לקרוא גם את הלינק הבא : http://www.martinfowler.com/bliki/XpVelocity.html