יש לכם blacklist של דברים שלא נכנסים לsource control?

[הפרבולה]

נראה לי בדוגמה הראשונה השואת בינרים ממש מתבקשת

אני מניח שהבג שהתכוונתה אליו הוא התוספת נקודה פסיק בdefine
אז אם הקוד המקורי משתמש במספר הקסם 10 ככה:
for (i = 0; i < 10; i++) a = 10 + i + 1;
, אז החלפת ה10 ב define כזה
#define BUG 10;

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

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

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

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

 

[BravoMan]

המקרה הראשון נועד להראות בעיה

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

 

[הפרבולה]

לפעמים משתנה הממשק של הפונקציה

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

 

[BravoMan]

מצטער, עדיין לא מבין...

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

 

[הפרבולה]

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

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

בדיוק בשלב הזה אני מוסיף את ההערות ומבצע קומפילציה חוזרת רק לבדוק שהתוצר הבינארי לא השתנה.

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

 

[BravoMan]

הייתי מת לקרוא אחת מההערות שלכם...

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

 

[הפרבולה]

חבל לכתוב ההערה שהפונקציה ממלאת ריבוע על המסך בצבע נתון

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

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

// verify that
// index is
// in the buffer size
// range
if( 0 <= index && index <BUFSIZE ) {
.....
}

לבין ככה ( חיסכון בשורות )

if( 0 <= index && index <BUFSIZE ) { // verify that index is in the buffer size range
.....
}

 

[BravoMan]

מה זאת אומרת "בסוף היום תמומש פונקציה אחרת"???

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

 

[הפרבולה]

כוונתי שהתחלת לכתוב פונקציה שעושה ריבוע

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

 

[BravoMan]

אוקיי, אולי זו סתם אי הבנה, אבל מה שאני קורא

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

 

[הפרבולה]

זה לא ככה שאני כאילו

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

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

 

[BravoMan]

אוקיי, אני יכול להבין השארת הערה עד שסיימת לכתוב את

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

 

[הפרבולה]

אני מדבר על בדיקות מינמליות קצרות

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

 

[BravoMan]

אוקיי, אני חושב שהבנתי:

התהליך הוא כזה:
&nbsp
1. אתה כותב קוד.
2. מקמפל.
3. מריץ בדיקות (קצרות)
4. אם יש בעיה מתקן וחוזר ל-2.
&nbsp
ברגע שהבדיקות תקינות יש תהליך נוסף:
1. אתה עושה commit או שם את הבינארי בצד.
2. אתה עובר על הקוד ומחפש היכן צריך הערות.
3. אתה כותב את ההערות.
4. אתה מקמפל.
5. אתה מבצע השוואה של הבינארים.
6. אם ההשוואה הצליחה -> אתה עושה commit, אם ההשוואה נכשלה, מתחיל בתהליך ציד בעיות.
&nbsp
האם ההערות שיכולות להשתנות בעקבות תיקון שרק נועד לעבור בדיקה, ולא refactoring של ממש, הן כ"כ ארוכות ורבות שלשכתב אותן בזמן שכתוב הקוד לקוח יותר זמן מאשר כל התהליך המשני שתיארתי כאן?
&nbsp
אני באמת מתקשה לדמיין מצב שכזה...

 

[הפרבולה]

כן זה פחות או יותר התהליך

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

 

[הפרבולה]

אגב אני מסכים איתך שרצוי להכניס את define כבר בהתחלה

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

 

[הפרבולה]

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

יש לי 2 אפליקציות שיש להם קובץ משותף של קוד מקור, אבל חלק מהקוד שונה בגלל אופי האפלקציה, דוגמה:

common code
............
#ifdef APPL_A
code of feature of application A
#else
code of feature of application B
#endif
.............
common code continue

כעת נניח ששיניתי קוד שקשור לאפליקציה B בלבד ( בתוך ה else# ), אני רוצה להיות בטוח שאפליקציה A לא השתנתה בטעות, אני מקמפל גם את אפליקציה A ומשווה את התוצר הבינרי לתוצר הקודם ומוודא שנשאר זהה.

 

[ipv6]

לאפליקציה A צריכות להיות בדיקות

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

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

 

[הפרבולה]

אני לא מבין למה להריץ שוב טסטים על אפליקציה A

זה יכול לקחת אפילו שנים רבות ( במידה ואפליקציה A רצה אצל לקוח הרבה זמן ).
וכל זה בגלל ששיניתי קוד שרלוונטי רק לאפלקיציה B ( ונמצא בקובץ משותף לשניהם ).
&nbsp
למה הכוונה ב HASH ? ( האם זה CRC או checksum או משהו אחרי ) , הכי בטוח זה להשוות את הקובץ כולו לקודם, בית אחרי בית. הקבצים לא כל כך גדולים ( פחות מ 500K ), ואכן יש לנו סקריפטים שעושים זאת.

 

[ipv6]

להריץ שוב בדיקות על A

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

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

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