יש עוד כמה קישורי CSS שאני ארצה לדבר עליהם, אבל קצת קשה לי לכתוב כמה ימים ברצף על אותו נושא… מאחר שאני כותבת בעיקר להנאתי (אם כי אני מודעת לקיומם של כמה קוראים מפני שלפעמים הם קמים לתחיה בצורת תגובות 🙂 ), אני הולכת אחרי צו ליבי המורה לי לגוון קצת (הידעתם? יש עוד נושאים בעולם מלבד CSS).
אז הפעם נעבור לעורף – לשרת – והפעם מספר קישורים בנושאים שונים של קוד.
האם הקוד שלנו עובר את מבחן התורכי? (או ההודי, תלוי איך אתם מתרגמים Turkey…)
המאמר הזה משתמש בתורכיה כדוגמה לתרבות שיש בה שוני שיש בו כדי להשפיע על התנהגות קוד, ומראה איך אופני כתיבת קוד השגורים בידי האמריקאים אינם מתאימים – ויכולים להפיל מערכת – כשהם מועלים בתורכיה למשל. ההבדל הראשון המוזכר במאמר הוא בדרך כתיבת התאריך. בארה”ב רגילים לכתיבת תאריך בפורמט שבו החודש נכתב לפני היום, ואילו בתורכיה (ובעצם ברוב מדינות העולם מחוץ לארה”ב) הפורמט הוא של ציון היום לפני החודש. המאמר פשוט מזכיר שכאשר שמשתמשים בתאריך כלשהו בעשרת האובייקט DateTime, צריך להשתמש ב-overload שמקבל כפרמטר את הפורמט הרצוי לתאריך. מהבחינה הזו, הקוד שלנו (בכליקיט וגם בפרוייקטים אחרים) אכן עובר גם את מבחן התורכי וגם את מבחן האמריקאי, מפני שפעמים רבות ה-DB שלנו שייך לתרבות ארה”ב, ולכן בכל מעבר תאריכים בין ה-DB למסך אנחנו ממירים את הפורמט.
דוגמה נוספת שהוא נותן היא דוגמה ידועה – של השוני בין ה-i הרגיל של הא”ב האנגלי ל-i התורכי: כאשר אנו משוים בקוד בין מחרוזות, אנו בד”כ משתשים ב-ToLower כדי לוודא שהשוני בין שתיהן ינבע משוני אמיתי ולא משוני ב-case של האותיות (במאמר מוזכרים אופנים נוספים להשוואה: שימוש ב-RegEx, או ב-Equal עם הפרמטר CurrentCultureIgnoreCase). אך בתורכיה, הפיכת האות I ל-lowercase אינה מניבה את האות i, וכן הפיכת i ל-uppercase אינה מניבה את האות I. כדי שנוכל להשוות בין שתי מחרוזות באופן שגם גם האות i התורכית תכוסה, יש להשתמש במתודה ToLowerInvariant() (יש מקבילות גם לדרכים האחרות המוזכרות).
המאמר אמנם מתמקד בתורכיה כנציגת השוני מול ארה”ב, אבל הוא נועד, לדעתי, להזכיר לכולנו שאיננו כותבים קוד בואקום, והקוד שלנו עשוי להגיע למקומות שלא חשבנו עליהם ושיש שם שוני המשפיע על התנהגות הקוד.
ומעניין לעניין, עדיין בענייני קוד שרת – אם כי זה אולי מתאים לכל קוד, בכל מקום שהוא.
37Signals כתבו פוסט שמאד מצא חן בעיני: כל קוד סופו להתיישן. אני חושבת שלכל מתכנת קורה לפעמים שהוא צריך לתקן משהו בקוד שהוא כתב מזמן. למתכנתים יש לעתים קושי בחזרה לקוד ישן מפני שהקוד ההוא פתאום נראה מיושן ובלתי מתאים למי שאנחנו היום. קשה לעבוד עם מבנים שאתה יודע שאפשר לבנות אותם טוב יותר, בפחות קוד, ועם פחות כפילות. אבל חשוב להבין: כל קוד בסופו של דבר יתן את ההרגשה הזאת. אך טבעי הוא שאדם מתקדם, לומד, וגם הטכנולוגיה מתפתחת (יש לקוות). העצה של 37Signals: תתמודדו. אם עובדים על יותר ממספר פרוייקטים, אי אפשר שלכולם יהיה הריח החדש והנעים של משהו שזה עתה נוצר. זה לא אומר שהמתכנת הוא גרוע, אלא שיש לו סדר עדיפויות. כי צריך להזהר כשנוגעים בקוד ישן: אם נעשה בו נקיון יסודי, אנו עלולים לפגוע בפונקציונליות שלו.
אז מה – לא נשפר קוד ישן? נשפר, אבל במידה. נתקן את הבאג או נוסיף את הפיצ’ר, ונשאיר את הקוד במצב יותר טוב משמצאנו אותו, אבל זהו. את האנרגיות והתובנות החדשות שלנו נשקיע בפרוייקטים חדשים.
ומאמר אחרון בקצרה -בחינה מחדש של עובדות ושל רעינות מופרכים בפיתוח תוכנה . רשימה (מתוך ספר) של עובדות שונות בתחום פיתוח תוכנה. מעניין לקרוא את הרשימה. לי כל גל נושא מזכרת, ואני מאמינה שכך הדבר לכל מתכנת.
אז הפעם נעבור לעורף – לשרת – והפעם מספר קישורים בנושאים שונים של קוד.
האם הקוד שלנו עובר את מבחן התורכי? (או ההודי, תלוי איך אתם מתרגמים Turkey…)
המאמר הזה משתמש בתורכיה כדוגמה לתרבות שיש בה שוני שיש בו כדי להשפיע על התנהגות קוד, ומראה איך אופני כתיבת קוד השגורים בידי האמריקאים אינם מתאימים – ויכולים להפיל מערכת – כשהם מועלים בתורכיה למשל. ההבדל הראשון המוזכר במאמר הוא בדרך כתיבת התאריך. בארה”ב רגילים לכתיבת תאריך בפורמט שבו החודש נכתב לפני היום, ואילו בתורכיה (ובעצם ברוב מדינות העולם מחוץ לארה”ב) הפורמט הוא של ציון היום לפני החודש. המאמר פשוט מזכיר שכאשר שמשתמשים בתאריך כלשהו בעשרת האובייקט DateTime, צריך להשתמש ב-overload שמקבל כפרמטר את הפורמט הרצוי לתאריך. מהבחינה הזו, הקוד שלנו (בכליקיט וגם בפרוייקטים אחרים) אכן עובר גם את מבחן התורכי וגם את מבחן האמריקאי, מפני שפעמים רבות ה-DB שלנו שייך לתרבות ארה”ב, ולכן בכל מעבר תאריכים בין ה-DB למסך אנחנו ממירים את הפורמט.
דוגמה נוספת שהוא נותן היא דוגמה ידועה – של השוני בין ה-i הרגיל של הא”ב האנגלי ל-i התורכי: כאשר אנו משוים בקוד בין מחרוזות, אנו בד”כ משתשים ב-ToLower כדי לוודא שהשוני בין שתיהן ינבע משוני אמיתי ולא משוני ב-case של האותיות (במאמר מוזכרים אופנים נוספים להשוואה: שימוש ב-RegEx, או ב-Equal עם הפרמטר CurrentCultureIgnoreCase). אך בתורכיה, הפיכת האות I ל-lowercase אינה מניבה את האות i, וכן הפיכת i ל-uppercase אינה מניבה את האות I. כדי שנוכל להשוות בין שתי מחרוזות באופן שגם גם האות i התורכית תכוסה, יש להשתמש במתודה ToLowerInvariant() (יש מקבילות גם לדרכים האחרות המוזכרות).
המאמר אמנם מתמקד בתורכיה כנציגת השוני מול ארה”ב, אבל הוא נועד, לדעתי, להזכיר לכולנו שאיננו כותבים קוד בואקום, והקוד שלנו עשוי להגיע למקומות שלא חשבנו עליהם ושיש שם שוני המשפיע על התנהגות הקוד.
ומעניין לעניין, עדיין בענייני קוד שרת – אם כי זה אולי מתאים לכל קוד, בכל מקום שהוא.
37Signals כתבו פוסט שמאד מצא חן בעיני: כל קוד סופו להתיישן. אני חושבת שלכל מתכנת קורה לפעמים שהוא צריך לתקן משהו בקוד שהוא כתב מזמן. למתכנתים יש לעתים קושי בחזרה לקוד ישן מפני שהקוד ההוא פתאום נראה מיושן ובלתי מתאים למי שאנחנו היום. קשה לעבוד עם מבנים שאתה יודע שאפשר לבנות אותם טוב יותר, בפחות קוד, ועם פחות כפילות. אבל חשוב להבין: כל קוד בסופו של דבר יתן את ההרגשה הזאת. אך טבעי הוא שאדם מתקדם, לומד, וגם הטכנולוגיה מתפתחת (יש לקוות). העצה של 37Signals: תתמודדו. אם עובדים על יותר ממספר פרוייקטים, אי אפשר שלכולם יהיה הריח החדש והנעים של משהו שזה עתה נוצר. זה לא אומר שהמתכנת הוא גרוע, אלא שיש לו סדר עדיפויות. כי צריך להזהר כשנוגעים בקוד ישן: אם נעשה בו נקיון יסודי, אנו עלולים לפגוע בפונקציונליות שלו.
אז מה – לא נשפר קוד ישן? נשפר, אבל במידה. נתקן את הבאג או נוסיף את הפיצ’ר, ונשאיר את הקוד במצב יותר טוב משמצאנו אותו, אבל זהו. את האנרגיות והתובנות החדשות שלנו נשקיע בפרוייקטים חדשים.
ומאמר אחרון בקצרה -בחינה מחדש של עובדות ושל רעינות מופרכים בפיתוח תוכנה . רשימה (מתוך ספר) של עובדות שונות בתחום פיתוח תוכנה. מעניין לקרוא את הרשימה. לי כל גל נושא מזכרת, ואני מאמינה שכך הדבר לכל מתכנת.
הכתב שלנו חברה’מן
שמחתי לשמוע שהכליקיט בסדר וגם אהבתי את הקטע בסוף על קוד ישן. מסכים. מצפה לעוד בנושא