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

1. עורך טקסט או IDE

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

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

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

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

2. תכנות מונחה עצמים או פונקציונאלי

כמה קש אכלתי מתכנות מונחה עצמים. כמה קל היה להתמכר לאשליה הזאת שהנה עם Clojure או Elixir לא יהיו יותר באגים ולא יהיו יותר אבסטרקציות שגויות.

אבל אז ניסיתי גם שפות פונקציונאליות.

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

3. האם TDD שווה את הזמן שלכם

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

וזה בסדר.

כי זה באמת בזבוז זמן לפעמים. כמו שכותב ג׳יימס קופלין.

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

אז מי צודק?

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

4. האם קוד צריך להיות מובן גם לאנשים שלא מכירים את השפה

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

האם המושג שלכם של קוד קריא כולל קוד שקריא רק למי שדובר את השפה?

הקוד הבא ב perl למשל:

my $input_pattern  = [map {[split //]} split '/' => $input];

לוקח שורה מהצורה:

#.#/###/.../

והופך אותה למערך של מערכים:

$VAR1 = [
          ['#', '.', '#'],
          ['#', '#', '#'],
          ['.', '.', '.']
        ];

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

# split original string into an array of strings (each / is a line)
my @lines = split "/", $input;

my $input_pattern = [];
for my $line (@lines) {
  # split the line into its characters
  my @characters = split "", $line;

  # add characters array to input pattern
  push @$input_pattern, \@characters;
}

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

5. שימוש ב ORM או כתיבת SQL ישירות

בקורס אבטחת מידע שלימדתי בשבוע שעבר כמה אנשים דיברו איתי בשבחי ה ORM. איזה כיף שיש כלי אוטומטי שבונה שאילתות ולכן אין לנו יותר בעיות SQL Injection. זה נכון, אבל אז המשכנו לדבר ונזכרנו שבעצם היו לא מעט בעיות SQL Injections כולל במערכות שהשתמשו ב ORM. איך זה קורה? טוב זה ברור. השאילתות ש ORM מייצר הן לרוב לא אופטימליות. במקומות שחשוב לנו לתת תשובה מהר בדרך כלל נתאים את השאילתה בעצמנו. ואז מתחילות הבעיות.

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

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

המאמר הזה של Geoff Wozniak למשל דן באריכות בבעיות של ORM, והדיון בהאקרניוז שמלווה אותו מזכיר שהוויכוח הזה לא הולך להיעלם בזמן הקרוב.

6. הבחירות שלי (בקצרה)

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

7. עכשיו אתם

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