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

לדעתי הבעיה המרכזית היא הקשר, הרופף בדרך כלל, בין שמות פנימיים של רכיבי המערכת לאיך שהם מוצגים למשתמש. אתחיל מדוגמא קטנה (אין כל קשר בין הדוגמאות לשום מציאות): פיתחתם חלון סטנדרטי שנקרא Options. איך ייקרא המודול וה-class שמממש את הפונקציונליות? Settings? Configuration? Preferences? Options? התשובה היא, כמובן, שזה תלוי. זה תלוי למשל האם אותו בן אדם מפתח גם את ה-UI וגם את ה-backend - במקרה כזה עולים הסיכויים של ה-Options להיות גם במימוש. אם מישהו אחר פיתח את התשתית לפני כחודשיים לפני תכנון ה-UI, יש סיכוי טוב שזה יהיה משהו אחר.

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

הסיפור כמובן מסתבך כאשר נוצר בתוכנה שילוב מופלא של גם options גם settings וגם configuration. אין דרך טובה יותר לבלבל את המשתמש עם 2 או 3 מקומות שבהם אפשר להגדיר הגדרות, במיוחד עם מקום אחד משפיע על משמעות ההגדרות שנתנו במקום אחר. אלא אם כן קוראים לו super options.

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

מרוצים מעבודת ה-UI המופלאה אתם נוסעים ללקוח להציג את פרי עמלכם. המנהל עומד ליד הלוח והאיש הטכני מפעיל את התוכנה. הלקוח מתעניין ביכולת ניתוח הרכישות באתר ואז המנהל אומר משהו כמו "Yossi, please do me weekly". אולי כבר עדיף היה שזה יהיה rakefet.

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

העיקרון הזה תקף לא רק בממשק בין ה-UI ל-backend. הוא תקף בכל תכנון, פיתוח או review. אם אתם רואים class ששמו WeeklyDataAnalyzer אבל כל מה שהוא עושה זה לכתוב את התוצאות לקובץ, צריך לשנות לו את השם למשהו כמו AnalysisResultsReporter או כל שם אחר שמתאר את הפעולה.

ומה קורה כאשר אין לנו שם טוב ל-class או למודול? מה אם ה-class גם מכיל את האלגוריתם וגם כותב את התוצאות? במקרה שאין שם טוב ל-class ייתכן שמדובר בבעית design וצריך לשקול לשנות (או לפצל) את ה-class ולהגדיר מחדש מה הוא עושה ואת הממשקים בינו ל-classes אחרים.

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

ורגע של עברית: יש כמובן גם את פניני העברית הטכנולוגית כמו למשל הפוסט מהבוקר (http://cafe.themarker.com/view.php?t=542974) שמביא כמה דוגמאות. גם אני משתמש ב"לקמפל" וב"לדבג" אבל עם מילים כמו "לקסטם" אני כבר מרגיש אי נוחות מסויימת. אז האם אצלכם "to parse" מתורגם ל"לפרסס" או "לפרסר"?

קודם כל אני אומר ל"פרסס" :)

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

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

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

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

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

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

ומה אם מוצר לשוק הבין לאומי שבו לכל feature יש שם גם באיטלקית ובקוריאנית?

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

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

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

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

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

צטט: sivan 2008-08-29 00:57:42

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

בהחלט.