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

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

feature "Clicking on the editable header will enter edit mode", %{session: session} do
    session
    |> visit("/")
    |> WallabyWorkflows.login("user@demoapp.com", "10203040")
    |> click(Query.css(".hero-main-header.editable"))
    |> assert_has(Query.css(".is-editing"))
end

אפילו בלי להכיר את אליקסיר קל מאוד להבין 3 מתוך 4 הפעולות בתוכנית הבדיקה פשוט בגלל השמות שלהן: visit כנראה שולחת את הדפדפן לנתיב מסוים, click כנראה לוחצת על אלמנט שמזוהה לפי השאילתה שעברה כפרמטר ו assert_has מוודא שאלמנט מסוים נמצא בעמוד. אבל מה עושה WallabyWorkflows.login?

הדבר הראשון שמפריע בפונקציה הזאת הוא שם המודול - WallabyWorkflows. המילה Wallaby היא השם של ספריית הבדיקה, והמודול מרכז פעולות מוקלטות שאני יכול להשתמש בהן בבדיקות השונות. הפעולות רצות בתוך דפדפן ואני חושב שהמילה Browser תעבוד כאן טוב יותר מאשר המילה Wallaby, כלומר עדיף יהיה לקרוא למודול BrowserWorkflows או BrowserMacros. אנחנו רוצים שם שירמוז על זה שמדובר ברצף פעולות מוקלט שהדפדפן הולך לבצע.

הבעיה השניה היא שם הפעולה login. השם הזה לא עוזר לי להבין מה הקשר בין הפעולה לבין הפרמטרים שלה והמעבר מ login ל user@demoapp.com כאילו נקטע באמצע. שימוש בשם כמו login_as והעברת האימייל והסיסמה בתור Named Arguments יכולים לעשות הבדל גדול. סך הכל אחרי שינוי השורה נקבל:

feature "Clicking on the editable header will enter edit mode", %{session: session} do
    session
    |> visit("/")
    |> BrowserMacro.login_as(email: "user@demoapp.com", password: "10203040")
    |> click(Query.css(".hero-main-header.editable"))
    |> assert_has(Query.css(".is-editing"))
end

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