אז למה מתכנתים שמשתמשים ברווחים במקום טאבים מרוויחים יותר?

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

רגע, מה?

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

if ('this_is' == /an_example/) {
  of_beautifier();
} else {
  var a = b ? (c % d) : e[f];
}

מאשר קוד כזה:

if ('this_is'==/an_example/){of_beautifier();}else{var a=b?(c%d):e[f];}

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

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

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

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

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

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

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

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

כשקראתי את המחקר, מיד הלכתי להסתכל על הקוד שלי. לא נעים לי לומר, אני בכלל לא זוכר איך עושים אינדנטציה כיוון שעורך הקוד (IDE) שלי עושה את זה עבורי. ברגע שאני יורד שורה חדשה, ההזחה מתבצעת באופן אוטומטי. זה קורה בכל סביבת עבודה שאני עובד עליה כיוון שבכל פרויקט אני יוצר מיד editorconfig. מדובר בקובץ קטן שקובע את ההגדרות של עורך הקוד. הוא תמיד מיושר עם הגדרות בדיקת הקוד הסטטית. בדיקת קוד סטטית היא בדיקה אוטומטית שבודקת את נראות הקוד – למשל רווחים לאחר סוגריים, הזחה מתאימה, שורה בין מתודה למתודה והגדרות רבות אחרות ומתקנת באופן אוטומטי את הקוד. קוד שלא כתוב לפי ההנחיות של בדיקת הקוד הסטטית לא יכול להיכנס למוצר/אתר/אפליקציה.
קוד שעובד לפי ההנחיות של בדיקת קוד סטטית (או לינט) נחשב לקוד איכותי יותר כיוון שגם אם 1,000 איש יעבדו עליו, הוא יראה כאילו אדם אחד כתב אותו – כלומר הוא מאוד נוח לקריאה. גם בדרך כלל בדיקת קוד סטטית עושה בדיקות אבטחה, ביצועים ועוד. לפיכך בדיקת קוד סטטית היא חלק קריטי מהתשתית של כל מוצר. כל מוצר איכותי הכוונה. לא מעט מתכנתים, במיוחד אלו שמייצרים מוצרים באיכות נמוכה לא מקפידים על בדיקת קוד סטטית. בטח ובטח לא בדיקת קוד סטטית כחלק מהליך Continuous integration (כלומר הליך של שילוב קוד חדש בקוד קיים).

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

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

אלא אם כן אתם מאמינים במתאם ובנומרולוגיה ואז זה מאוד הגיוני ש’רווח’ === ‘רווחים’.