2020-08-22

תאוריה ארגונית: מתן משוב

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

הפעם אני רוצה לדבר קצת על תיאוריה ניהולית, וספציפית על מתן משוב (feedback).

באופן מעט מפתיע, למרות שבני-האדם לא משתנים כל-כך לאורך השנים - התיאוריה הניהולית עוברת trends ומהפכות לא הרבה פחות מעולם הטכנולוגיה. אני זוכר סשן מפתיע של מדען הנתונים של SafariBooksOnline (ספריית הספרים המקוונת של O`Reilly) שבו הוא הראה שגם בתחום הניהול הצרכנים רוצים את ״החדש ביותר״ ונותנים עדיפות גבוהה לספרי ניהול חדשים, על חשבון תשומת לב לספרים ״ארכאיים״ בני חמש או עשר שנים. הנחתי, קודם לכן, שזה דפוס ייחודי לעולם הטכנולוגיה.

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

למשל: רבים מאיתנו רגילים לשיחות הערכה שנתיות בהן אנו מדורגים למדד ביצועים בטווח בין 1-5 (כאשר רוב האנשים נופלים לערך 3 שאומר ״אתה בסדר״). ובכן, המודל המאוד-נפוץ (ולא אהוד?) הזה, שהיה קיים בכל חברה שעבדתי בה ב 17-18 שנות הקריירה שלי - כבר נחשב, ב cutting edge של התאוריה ניהולית, כשנוי-במחלוקת במקרה הטוב - או ממש מזיק במקרה הרע.

למה? - על זה ארצה לספר בפוסט.



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

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


מדוע לתת משוב?

כי אנחנו רוצים להשתפר - כל הזמן. משוב הוא כלי לחזק ״התנהגויות חיוביות״ ולתקן / להכחיד ״התנהגויות שליליות״.

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

אלו הם רעיונות ניהוליים בסיסיים ומקובלים.


מהו משוב ״טוב״?

קשה לי להאמין שיש מנהלים שעברו הכשרה בשנים האחרונות ולא מכירים את מודל ה SMART למתן משוב (ו/או יעדים):

  • Specific - דרשו תוצאה ברורה. תנו משוב על אירועים ספציפיים, עם דוגמאות.
  • Measurable - התמקדו במדדים אובייקטיבים ככל-הניתן. לא ״לא הרגשתי שעשית עבודה טובה״ אלא יותר ״איחרת כך וכך פעמים בלוחות הזמנים ברבעון האחרון״.
  • Achievable - העובד צריך להסכים ליעד, ולהאמין שהוא מסוגל להשיג אותו (גם אם לא בקלות). לגבי משוב - עליו להאמין שמה שמתבקש ממנו הוא אפשרי.
  • Relevant - התמקדו במה שמשמעותי להצלחת העובד בתפקיד (אפשר לנסות ״לדרוש יותר״ ו/או ״להוציא אותו מאזור הנוחות״ שלו).
  • Time-based - קבעו לוחות זמנים לשיפור הרצוי. ברור ששינוי לא קורה ברגע - אבל יש גם סכנה שללא מסגרת זמנים ברורה - השינוי הרצוי ״יתמסמס״.
אפשר להקביל את ה SMART לעקרונות של Gamification: אנו ״משחקים״ במשחק השגי, אך נוכל להשיג את המעורבות של העובד רק אם המשחק יהיה צפוי (specific, measurable), הוגן (relevant achievable, specific), שלא משנים את החוקים באמצע, ועם מסגרת כלשהי (time, rewards).


עוד רעיונות מקובלים:
  • אדם (העובד) לא יכול לספוג כמות גבוהה של משוב שלילי ברצף - וחשוב מאוד לאזן בין משוב חיובי ושלילי. מדדים מוכרים ומקובלים הם:
    • אתם יכולים לתת משוב שלילי אחד על כל 5-6 משובים חיוביים שנתתם.
    • מנהל נדרש לתת לכל עובד משוב חיובי לפחות אחת לשבוע. ואם הוא לא מסוגל - יש לשקול את הדרך מחדש: שינוי משמעותי או פרידה.
  • לבני-אדם יש Blind Spots (כמו כתם על החולצה שהם לא שמים אליו לב). אם לא נעיר את דעתם לעניין - הם פשוט לא ידעו.
  • נותן המשוב צריך להיות מקובל (Creditable) בעיני מקבל המשוב. ללא אמון - המשוב לא יתקבל ברצינות.
    • יש יתרון למתן משוב דומה מכמה מקורות שונים - מה שמקשה על מקבל המשוב לפטור את המשוב כ״טעות אקראית בהבנה״.
    • לעתים מנסים ליצר סימטריה ולעודד משוב מהעובדים, במידה רבה בכדי לבנות אמון, ולא רק בכדי להשתפר בעצמם.
  • שימוש בחיוביות: מתן דגש על שימוש בשפה חיובית ולהימנע ממילות-שלילה / מילים המעוררות התנגדות.
    • יש זרם כללי של ״ניהול חיובי״, שנראה לי שהוא דיי פופולרי בארה״ב.
    • גרסה מתונה יותר: לא להיות שיפוטיים. לציין את האירוע וההשלכות המזיקות, אבל לא לשפוט ״זה חמור״, ״נכשלת״, וכו׳. בכל מקרה ותמיד: להתמקד בהתנהגות ולא באדם.
  • משוב, אסור שיהיה אירוע תקופתי. שיחת הערכה שנתית - היא רחוקה מדי. משוב צריך להיות על בסיס יום-יומי, קרוב במידת האפשר להתנהגות אליה אנו רוצים להתייחס. הרעיון הזה נקרא כך לעתים ״משוב מתמשך״ (קצת באזז).
    • שיחת משוב תקופתית אמורה רק לסכם משובים ממהלך התקופה ולוודא ששום דבר לא התפספס.
באופן אישי: הרעיונות הללו מקובלים והגיוניים בעיני.

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

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


מגמות חדשות במתן משוב


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


Feedback or Feedforward?


ארצה להתחיל במונח בשם Feed Forward: אולי כמנהלים, במקום להתמקד בהיסטוריה, במה העובד עשה, נתמקד דווקא בעתיד - מה העובד יעשה הלאה?

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

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

האם סגנון ה״משוב החשבונאי״ באמת אפקטיבי? האם המטרה של ״חיזוק התנהגויות חיוביות וצמצום שליליות״ באמת מושגת ביעילות?


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

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

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

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



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

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




המשוב שלא מתיישב

את החלק הזה אני כותב על בסיס מאמר בשם The Feedback Fallacy שפורסם ב Harvard Business Review לפני כשנה. אחד הכותבים שלו הוא מרקוס בקינגהם, שאולי מוכר לכם בעקבות הרעיון שהוא מקדם לאורך שנים: ״התמקדו בשיפור החוזקות של העובדים, ולא בהתכתשות בחולשותיהם״.

כפי שציינתי, מגמה שהולכת ומתחזקת היא מתן ״משוב מתמשך״, בתכיפות, ולא כפעולה תקופתית.

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

האם משוב תכוף, גם כאשר מתקבל באופן חיובי - באמת משנה התנהגות?

ע״פ המאמר, מחקרים[א] מראים שדווקא לא כל-כך.

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

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

האם המידע הזה הוא באמת נכון? - גם כאן מוטלים ספקות גדולים:

  • קיים ספק האם באמת אדם חיצוני (מנהל / 360) יקלעו טוב יותר לנקודות שאדם יכול להשתפר בהן - מאשר האדם עצמו. 
    • אישית, אני יכול להעיד על מנהלים שנתנו לי משוב עם נקודות לשיפור - שהיו שגויות, ודווקא כיוון אחר לקח אותי למקומות טובים יותר. אציין שמצד שני קיבלתי גם לא פעם משוב שנראה לי מדויק, ולעתים אף מאיר עיניים.
  • כבר שנים רבות קיימת תפיסה שהעובד הוא ״כלי קיבול״ לידע / מיומנויות / התנהגויות - שמבטא את יכולותיו. לפי גישה זו ניתן ״להנדס״ את העובד ע״י כך שמלמדים אותו ידע / מיומניות / התנהגויות חדשות או משפרים קיימות.
    • מאוד מפתה כמנהל לאמץ את המודל הזה. זה עושה הרבה סדר בנושא של ״פיתוח עובדים״, אבל אנחנו כבר יודעים - שלחפש תחת הפנס (היכן שנוח), זה לא תמיד הדבר הנכון. נראה במודל הזה יש משהו נכון - עד גבול מסוים. מעבר לידע ומיומנות בסיסית קשה עד לא יעיל לנסות ו״להנדס״ עובדים ל״גרסה טובה יותר שלהם״.
  • הרעיון שניתן למדוד ביצועים של עובד על סקאלה מספרית/עקבית - הוא גם בעייתי. אנשים שונים מבצעים שונה בהקשרים שונה. אולי משימה אחת אני עושה מצוין, ואחרת בינוני - אז מה ״הציון״ שלי? אולי אנשים הם יצור רב-מימדי מורכב, וניסיון לתאר אותם או את הביצועים שלהם על ציר יחיד - הוא הפשטת יתר?
    • ושוב: לפעמים אנו נוטים מאמצים גישה בעיקר כי ניתן לעבוד איתה. לא בהכרח כי היא מדוייקת או הוכחה כיעילה.


לסיכום, אם אני כמנהל: 

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


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

הגישה הזו מציעה גישה ״חברית״ ושל ״מנטורינג״ למתן משוב - משאירה המון מהאחריות אצל העובד, ולא אצל המנהל שצריך ״לנהל״ או ״להנדס״ את העובד.

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

הגישה הזו גם פחות מתיישבת עם סגנון ניהול סמכותני (״אני יודע!״) או סגנון ניהול גנרי (״מתודולוגיה ניהולית היא מה שיש לי להביא כמנהל״). 


מצוינות



אבל מה עם מצוינות?
האם אנחנו לא הופכים ל״נחמדים״ על חשבון המצוינות? סלחני כלפי בינוניות?


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

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

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

כמובן שאמירה כללית כמו ״מצוין, מלך!״ היא לא משמעותית כל-כך:
  • היא לא משדרת כנות והבנה.
  • האם אתם בטוחים שזו הצלחה? שאתם לא מחזקים משהו שנראה ברגע הראשון כמו הצלחה - אבל תצטערו על זה?
    • בוודאי אתם מכירים פרויקט שנראה נהדר בהתחלה וזוכה לתשבוחות - אבל אז מתבררים שבעצם הוא לא תופעל כל-כך טוב...
  • היא לא עוזרת לעובד לפתח את המקור להצלחה - מה שנדרש בכדי לשחזר אותה.
המודל המועדף על כן הוא משוב בנוסח: ״התוצאה טובה מאוד בעיני בגלל סיבה 1 סיבה 2 סיבה 3; מה בעצם גרם להצלחה הזו? אתה יודע להסביר?״

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

הנה דוגמה נוספת. במקום לומר ״זה לא עבד טוב״, עדיף לומר: ״כשעשית x לא הרגשתי שזה עבד טוב בגלל y ו z״. שוב סיפקנו מידע ודעה לעובד, שעליו לקחת בחשבון - אבל נמנענו מכשלים אפשריים שכמנהלים אנו מועדים אליהם.

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

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


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

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

זו תוכנית טובה לכתיבת תסריט הוליוודי. בסרטים זה עובד. 
במציאות - זו לא תוכנית כל-כך יעילה.


סיכום


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

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

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

אתם יותר ממוזמנים להגיב ולשתף מניסיונכם בנושא.



שיהיה בהצלחה!



-------

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


קישורים רלוונטיים


2020-07-11

תזכורת להשתמש ב SLAP כאשר אתם כותבים קוד....

בפוסט הזה להכיר (או להזכיר) עקרון חשוב בכתיבת קוד, הנקרא SLAP.

Single Layer of Abstraction Principle (בקיצור SLAP) - הופיע לראשונה בספר Smalltalk Best Practice Patterns של קנט בק (כן, שוב הוא...). העיקרון אומר שפונקציה צריכה להכיל ביטויים באותה רמת-הפשטה.


פירוש הגדרת ה SLAP


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

למשל:

מג״ד א: ״פלוגה 1136 תזוז צפונה ותתפוס את ציר בנימינה״ 
חפ״ש: ״שנייה, הגי׳פ שלנו כל הזמן חורק. אולי כדאי לקחת אותו לטיפול לפני?״.

זו הכוונה.

מי הם בקוד המג״דים? מי הם החפ״שים? את זה אנחנו צריכים לבדוק ולהבין.


דוגמה 


הנה פונקציה (ממערכת אמיתית), שתשמש כדוגמה. קראו אותה עד הסוף:



הפונקציה אכן ארוכה. במקור היא ארוכה אפילו יותר - קיצרתי אותה לצורך הקריאות.

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

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

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


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

הכלי העיקרי לתיקון פונקציה עם רמות הפשטה שונות הוא Extract Method Refactoring. הנה התיקון שלי:



סימנתי ב:
  • צבע תכלת - מג״דים
    •  => flow logic, קוד שמנהל החלטות גדולות ב flow המערכת.
  • צבע כחול - מ״פים 
    • => פעולות טכניות ברמת הפשטה גבוהה: גישה לבסיס נתונים או מערכות צד-שלישי, הפעלה של לוגיקה עסקית ממוקדת (במקרה הזה: ולידציה), וכו׳.
  • צבע כחול עמוק - חפ״שים 
    • => פעולות לוגיות בודדות ("one liners״), control flow בסיסי, כתיבת לוגים, וכו׳.

אתם בוודאי מסכימים שהפונקציה קצרה וקריאה יותר. עכשיו היא נראית יותר כמו ״סיכום מנהלים״ - שקל לקרוא ולעקוב אחריו. כל אחת מהפונקציות שהוצאתי: ()startFlowTypeI ו ()startFlowTypeII, וכו׳ - צריכה לשמור על SLAP בעצמה, ואם לא - אוציא ממנה גם עוד פונקציות.

ברמת המטאפורה: פיצלנו את דיון המג״דים לדיוני משנה בפורום המ״פ - וזו פרקטיקת ניהול טובה.


בשלב הזה אתם אמורים להרגיש חוסר נוחות מסוים עם מה שאני אומר, גם אם אתם חושבים שה Refactoring היה מוצלח: למה לעזאזל עדיין יש חפ״ש בפורום המג״דים? איך נכנסו לשם מ״פים? - לא אמרנו שזה לא צריך לקרות?

התשובה הקצרה, היא ש SLAP הוא בסה״כ guideline. לא כדאי להיות קנאים.

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

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

אם ננסה לשמור על SLAP ב 100% - סביר שהקוד שלנו יהפוך לקריא פחות. חשוב למצוא את נקודת האיזון הבריאה. 


מורכבת נוספת ביישום SLAP


שימו לב שהשינוי בפונקציה לא היה רק פעולות Extract function, אלא גם גם שינוי עמוק יותר למבנה. במקום להחזיר ערכי Status שונים של כישלון מגוף הפונקציה - הפכתי את הדיווח על שגיאות ל Exception ותפסתי אותו בפונקציה הראשית. ה try..catch לא היה בפונקציה המקורית.

החזרה של ערך מתוך גוף הפונקציה לפעמים היא קריאה יותר - אך היא מקשה מאוד על Extract method refactoring - כי הקוד שיצא לפונקצית-משנה לא יכול פתאום לשלוט בערך ההחזרה של הפונקציה הראשית.

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



הוספתי טיפוס חדש ופרטי של Exception בשם ValidationException. הוא ישמש אותי גם בפונקציות ()startFlowTypeI ו ()startFlowTypeII. הגדרתי טיפוס חדש כדי שאוכל ב catch להבחין בבירור בינו לבין שגיאה ממקור אחר.

היתרון ב Exception הוא שאני יכול להשתמש בו בפונקציות בקינון עמוק יותר, באותו האופן בדיוק.

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




סיכום

במהלך הפוסט נצמדתי לדוגמת-קוד קונרטיות, ובשאיפה שקל ״לחוש״ אותה.

התיאוריה של SLAP גורסת שמעבר בין רמות הפשטה שונות גוזלת משאבים קוגניטיביים מהמתכנת - ולכן אנו רוצים:
  • להימנע ממעבר תדיר בין רמות הפשטה שונות באותו שטף קריאה של קוד => באותה הפונקציה. שמירה על רמה אחידה של רמת הפשטה מקלה על הקריאה וההבנה של הפונקציה.
  • להשתדל שהמעבר בין רמות הפשטה שונות יהיה בקריאה לפונקציות-משנה. המעבר מפונקציה לפונקציה הוא אינטואטיבי לשינוי רמת הפשטה.

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

שיהיה בהצלחה.