הבלוג של ינון פרק

כשאני מלמד Generators בפייתון אני אוהב להתחיל עם הפונקציה הזאת שמחשבת מספר בסידרת פיבונאצ'י:

def fib(n: int) -> int:
    a, b = 1, 1
    for i in range(n):
        a, b = b, a + b
    return a

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

print(sum(fib(n) for n in range(100)))

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

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

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

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

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

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

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

2. אפשר להתייחס לקושי החדש בתור תירוץ, ולהסביר לעצמי ולעולם למה אי אפשר להגשים את החלום.

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

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

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

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

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

1. חיבור טוב לכל מערכת צד שלישי שאפשר לדמיין.

2. תיעוד טוב ברשת ופיתרונות קיימים לכל בעיה.

3. יכולת שיחה עם Chat GPT בלי להפיל אותו להזיות.

4. קל לגייס אנשים (כן עם כל ההייפ, עדיין קל יותר לגייס מתכנתי Java מאשר מתכנתי Rust).

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

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

1. אפשר לפתח לבד את כל הכלים ולקבל רוח גבית חזקה מהאינטרנט גם לפרויקטים קטנים.

2. פוסטים הופכים ויראליים הרבה יותר מהר (כי מי בכלל הולך לשתף פוסט על Java היום)

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

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

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

החלק הראשון של יום 8 ב Advent Of Code היה ממש פשוט וכלל כמה טיפים לגבי פונקציית reduce בפייתון.

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

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

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

ומכאן צריך לבחור דרך פעולה-

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

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

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

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

אז כן אני שמח היום שאני יכול לכתוב ברובי קוד כזה:

3.1.1 :008 > x = 10
 => 10
3.1.1 :009 > y = 20
 => 20
3.1.1 :010 > data = {x:, y:}
 => {:x=>10, :y=>20}

אבל כשיצאה רובי 2.7 והייתי צריך להתרגל לכתיב הזה זה גם נראה לי מוזר.

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

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

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

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

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

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

3. לכתוב מספיק בדיקות כדי לשבור את הקוד, ולהבין איך הוא נשבר ומתי הוא עובד.

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

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

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

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

יש ימים שהדבר הכי טוב שאפשר לעשות בשביל הפרויקט הוא git stash. כן סטאש, לא ליצור איזה בראנץ שעוד חודשיים מישהו יבוא ויציע "להחיות את הפיצ'ר", סטאש שלא רואים (האמיצות יכולות לנסות git restore, אבל לי אף פעם לא היה אומץ), ושלא מספרים עליו לאף אחד.

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

הלינטר של פייתון התרגז עליי היום כי כתבתי קוד כזה:

if type(x) == int:
    ...

ולא, לא עניין אותו אם אני משתמש ב type או ב isinstance הפעם ובכל מקרה באמת רציתי לבדוק את ה type. מה שהפריע לו היה דווקא ה ==, כי בעולם של הלינטר השוואה בין טיפוסים תעבוד טוב יותר עם is, כלומר זה הקוד שהייתי צריך לכתוב:

if type(x) is int:
    ...

כי בעבודה עם טיפוסים זהות ושיוויון זה אותו דבר.

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

In [2]: %timeit type(8) == int
15.6 ns ± 0.091 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)

In [3]: %timeit type(8) is int
13.4 ns ± 0.0661 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)

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

נ.ב. במקומות יותר מעניינים השוואה עם is או == יכולה להיות בעלת משמעות, למשל בעבודה עם רשימות:

In [14]: [1, 2, 3] == [1, 2, 3]
Out[14]: True

In [15]: [1, 2, 3] is [1, 2, 3]
Out[15]: False

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