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

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

הגיע הזמן שנתגבר על השקר הזה.

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

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

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

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

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

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

האמת היא שהפריימוורק הוא לא העניין פה.

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

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

פריימוורק הוא לא הבעיה וגם לא הפיתרון.

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

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

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

וכן הזן של פייתון משקר. כשהם כותבים:

There should be one-- and preferably only one --obvious way to do it.

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

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

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

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

export default function App() {
  const [keys, setKeys] = useState("");

  function handleKeyDown(e) {
    setKeys(keys + e.key);
  }

  return (
    <div className="App" onKeyDown={handleKeyDown}>
      <h1>Hello CodeSandbox</h1>
      <h2>Start editing to see some magic happen!</h2>
      <p>{keys}</p>
      <input type="text" />
    </div>
  );
}

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

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

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

import { useEffect, useState } from "react";
import "./styles.css";

function GlobalKeyboardEvents({ onKeyDown }) {
  useEffect(() => {
    document.body.addEventListener("keydown", onKeyDown);
    return function () {
      document.body.removeEventListener("keydown", onKeyDown);
    };
  }, [onKeyDown]);
  return <></>;
}

export default function App() {
  const [keys, setKeys] = useState("");

  function handleKeyDown(e) {
    setKeys(keys + e.key);
  }

  return (
    <div className="App" >
      <h1>Hello CodeSandbox</h1>
      <h2>Start editing to see some magic happen!</h2>
      <p>{keys}</p>
      <input type="text" />
      <GlobalKeyboardEvents onKeyDown={handleKeyDown} />
    </div>
  );
}

ואפשר לשחק איתו לייב בארגז החול בקישור: https://codesandbox.io/s/frosty-violet-llfo2g?file=/src/App.js:0-711

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

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

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

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

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

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

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

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

I am experiencing this breaking change, my production app is broken and unusable to my clients.

Me three. Prod is down. Got woken up here by confused users

It affected my app in production too, axios is not a function.

Confirmed as breaking production applications on my end as well. This is a big miss in testing coverage for a library like this.

Also having multiple broken production apps here.

Experiencing issues as well on production apps. Error: "axios is not a function"

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

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

<script src="https://unpkg.com/axios/dist/axios.min.js"></script>

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

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

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

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

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

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

אז למה בעצם להתאמץ?

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

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

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

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

Nokia, our platform is burning.

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

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

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

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

2. ללמוד, גם (ובמיוחד) דברים שלא קשורים לעבודה.

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

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

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

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

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

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

This crate provides a library for parsing, compiling, and executing regular expressions. Its syntax is similar to Perl-style regular expressions, but lacks a few features like look around and backreferences.

מה הם אותם look around features ואיזה כוחות על הם מוסיפים לביטויים רגולאריים? בואו נגלה.