ארכיון חודשי: דצמבר 2018

5 דברים טכניים שלמדתי השנה

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

1. אני עדיין צריך ללמוד יותר VIM

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

אחד הדברים שלמדתי מחדש השנה הוא Text Object. היכולת של vim לזהות דברים למשל פסקאות, שאתה בין סוגריים, מרכאות, מילים וכיוב'.
בעוד שיש בברירת המחדל תמיכה די טובה. יש הרבה תוספים שמוסיפים לזה עוד יכולות, או רוכבים על הקיים ומוסיפים לזה תכונות.
למשל היכולת להבין "מתודה" כפסקה, או class ככזו. ויצא לי בעצם ללמוד מחדש את כל השימוש בה, שדי הדחקתי. אם עד השנה הזו הייתי משתמש המון ב visual mode, השה הזו ירדתי בכמות השימוש במצב זה, בזכות ה Text Objects.

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

2. אני יודע מה מפריע לי כל כך בלכתוב טסטים

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

אתחיל מכך שאני כן חושב שבדיקות הן חשובות, אבל לא בגישה העיקרית ששולטת בשוק.
למשל אם תלכו לחבילת go שיצרתי לאחרונה בשם gostrutils, תגלו כי יש לי שם בד"כ קרוב ל100% cover לפונקציות שם.
זה מאוד חשוב לי שיהיה 100%. עד כמה שזה נשמע מוזר, אבל מה זה אומר בעצם 100%?!

אז דבר ראשון מערך הבדיקות מתחלק למספר חלקים:

  • unit test – סט בדיקות שפונקציות עובדות כראוי – בד"כ זה אומר מעט קוד שבודק חלק קטן מתוך פונקציה.
  • בדיקות פונקציונאליות – מוכרת בשם integration testing – כלומר האם לוגיקה קטנה עושה מה שביקשו.
  • בדיקות שימושיות – בד"כ נקרא end to end או E2E בקיצור, אומר כי בודקים האם טופס מסוים מתפקד נכון
  • בדיקת מערכות – האם המערכת הכוללת עובדת ומתפקדת כמו שצריך, כולל תשתיות, ולא רק הקוד
  • בדיקות ביצועים – נקרא גם benchmarks – בדיקה עד כמה קוד, פונקציה או פוקציונאליות מהירה

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

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

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

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

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

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

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

3. אין לי אהבה לקוד

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

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

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

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

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

4. לא כל המפתחים חושבים זהה

יצא לי להביט על קוד אשר הבנתי אותו, אבל לא מה ניסו לפתור בו.
השתמשו ב hash map אשר מחזיק 3 דברים בתוכו בסה"כ ומוזן בזמן עליה, והבעיה היא ששינוי התוכן התבצע מתוך מספר טרדים, ואז קיבלנו race condition רנדומאליים וקריסות.

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

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

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

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

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

5. מבחנים לא נכונים

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

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

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

מבחן שגוי

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

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

אבל במקום, מקבלים שאלות בנושא של TCP/IP, כיצד מסד נתונים עובדים, איך יוצרים מודולים לקרנל וכיוב'.
מה עכשיו? האם אתם מתאימים לתפקיד?

אז הגזמתי קצת, נכון? ובכן לא.

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

שאלות בנושא התפקיד להראות יכולת והבנה חשובים הרבה יותר מאשר היכולת אז אני מדבר על full stack עבור פיתוח web, הנה מבחנים טובים יותר מאשר שאלות מדמ"ח:

  1. יש לי צורך לאסוף את הנתונים הבאים – מה הסכמה למסד הנתונים שתתכנן ולמה?
  2. האם מסד נתונים מבוסס סכמה באמת מתאים לזה, או אולי מסד נתונים מסוג אחר?
  3. תן לי הדגמה מתי תבחר בdjango/rails ומתי ב sinatra/flask?
  4. מתי Go עדיפה על פיתון/רובי?
  5. מה ההבדלים בין Vue/React לבין Angular?

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

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

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

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

זו כמובן דעתי, בלבד, בהצלחה 🙂