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

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

בטווח הרחוק יש דברים אחרים שמפריעים לי בקוד:

1. קומפוננטה של מעל 100 שורות.

2. לוגיקה בתוך JSX.

3. קומפוננטה שמקבלת יותר מ-4 פרופס.

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

5. לוגיקה (פונקציות) בתוך קומפוננטה, במקום ב Custom Hook או קובץ נפרד.

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

יחד עם המעורבות של Vercel בליבה של ריאקט אנחנו רואים גם שינוי ארכיטקטורה בפיתוח יישומי ריאקט - מעבר מספריה לפיתוח קוד צד לקוח לפריימוורק לפיתוח Full Stack. בואו נראה מה האפשרויות שלנו היום ומתי כדאי לבחור כל אפשרות.

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

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

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

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

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

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

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

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

הקוד הבא ב Vue מראה על המסך את הטקסט Hello Vue:

<template>
    <template v-if="true">
        <p>Hello Vue</p>
    </template>
</template>

אבל זה כבר לא מראה כלום:

<template>
    <template>
        <p>Hello Vue</p>
    </template>
</template>

בואו נראה למה.

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

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

רק שני דברים הפריעו לחגיגה:

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

2. פיתוח מערכות מבוזרות הוא יותר מורכב מפיתוח מערכות על שרת יחיד.

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

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

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

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

אנחנו יותר חכמים היום. מותר לבנות דברים טוב יותר.

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

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