DCSIMG
"עייפות הקוד / התוכנה" - I Love C#
Sign in | Join | Help

I Love C#

Eyal Vardi

"עייפות הקוד / התוכנה"

פורסם בתאריך Jan 08 2012, 07:30 AM על ידי Vardi | ישנם 2 תגובות

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

"עייפות הקוד / התוכנה" – היא תופעה של קוד שלאחר תקופה מסויימת לא מצליח למלא את המצופה ממנו (Spec) כתוצאה ממספר סיבות:

1. נתונים שגדלים לאורך תקופת העבודה עם הקוד, לדוגמא קבצי לוגים, מבני נתונים...

2. כמות משתמשים שגדלה

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

4. שינויים שנעשו בקוד מאז הגירסה המקורית.

5. הצרכים של הצרכן של התוכנה השתנו במידה כזאת שהקוד המקורי כבר לא מתאים, ולא ניתן לשינוי או להתאמה לצרכים החדשים.

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

שאלות שאנחנו צריכים לשאול את עצמנו:

נניח שקוד א' ו-ב' עושים את אותו דבר אבל קוד ב' ממשיך לעבוד בדרישות לאורך זמן ארוך יותר.

1. האם אנחנו יכולים להגיד שקוד ב' כתוב יותר טוב מקוד א, איכותי יותר?

2. האם אנחנו יכולים לחזות מראש איזה קוד ישרוד לתקופה ארוכה יותר?

התשובות שלי לשאלות אלו הם בפוסט הבא סמיילי.

אשמח לקבל תגובות…

רשימת תגובות

# re: "עייפות הקוד / התוכנה"

פורסם בתאריך Sunday, January 15, 2012 10:54 AM על ידי שיאון כהן  

קוד ב' לא כתוב בצורה יותר איכותית אבל הארכטיקטורה שלו הרבה יותר טובה:

נתנו מחשבה מראש על דברים שיכולים להשתנות ואולי גם הריצו כמה Stress Tests לבדוק איך הדברים יעבדו בעתיד

# re: "עייפות הקוד / התוכנה"

פורסם בתאריך Friday, January 20, 2012 12:50 PM על ידי נואנדה  

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

אני רוצה לטעון שבדיקות אינטגרציה,בניגוד לUNIT TESTS ,מספקות מידע על ה EXTERANL QUALITY  בלבד,שהוא מאפיין שמעניין לקוחות חיצוניים כמו ה PRODUCT OWNER או  ה CUSTOMER או ה DEVELOPMENT MANAGER שאין לו מושג ירוק בתכנות.

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

מצד שני אני אשאל אותך....המוצר מרוויח 100 מיליון דולר כל שנה ומוביל את השוק...אם נפעל לפי הספר ,UNIT TESTS,עקרונות תכנות וכולי נחסוך 3 מיליון דולר משכורות ואולי נקצר את הזמן ללקוח בחצי....אבל זה באמת משנה?!? הלקוח מוכן לחכות(אין לו ברירה כנראה) אף אחד לא דורש להתייעל,כי כנראה לא יודע שזה אפשרי....3% שיפור לעומת הסיכון בהכנסת תהליכים חדשים לארגון זה לא כדאי!!!?

nounda.dee@hotmail.com

שלח תגובה

(שדה חובה) 
(שדה חובה) 
(אופציונלי)
(שדה חובה) 

Enter the numbers above: