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

מעבר לצורך להישאר רלוונטים, יש עוד שני יתרונות בגללם אנחנו חייבים להישאר פתוחים לרעיונות חדשים-

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

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

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

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

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

פיצ'ר Server Components של ריאקט הוא חלק מריאקט 18 ומאפשר סוג של Server Side Rendering לקומפוננטות ספציפיות. בגירסה 13 של Next.JS התווספה תמיכה ב Server Components מה שהפך את העבודה איתם להרבה יותר פשוטה. בואו נראה איך זה עובד ומה היתרונות שלהם על פני פיתוח ריאקט רגיל או על פני Server Side Rendering.

יש לא מעט סיבות שיכולות לשכנע אנשים לבחור בארכיטקטורת Micro Services, ביניהן:

יכולת גדילה אופקית - כשסרביס מסוים עמוס אפשר להוסיף עוד מופעים שלו

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

זריזות בפיתוח - אפשר לעדכן מיקרו סרביסים בלי לדאוג ששברת קוד במקומות אחרים ביישום.

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

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

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

הבעיה שבהרבה מקרים הבחירה בארכיטקטורת Micro Services לא מביאה לתוצאה הרצויה: אי אפשר באמת להוסיף עוד עותקים של סרביס מסוים כי המקביליות גורמת לנעילות, כשסרביס נופל הסרביסים האחרים נכנסים ל Retry Loop ושוברים את כל המערכת כמו דומינו, סרביסים משתפים מידע דרך בסיס נתונים משותף ולכן אי אפשר באמת לשנות אחד בלי לשבור אחרים ואפילו ה Deployments נשארו מסובכים כי צריך להעלות גירסה של כמה סרביסים במקביל. כל זה לפני שדיברנו על הקושי להקים סביבת עבודה מקומית או היכולת לבדוק גירסה מסוימת של המערכת (או באופן כללי לדבר על "גירסה" של מערכת בעולם של מיקרו סרביסים).

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

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

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

במהלך הפיתוח ובמיוחד בתוך רצף עבודה מאוד מפתה להשתמש בפקודות:

$ git add .
$ git commit

או בגירסה המתונה יותר git commit -a. הבעיה בשתי הגירסאות נובעת משילוב שני גורמים:

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

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

מה עושים במקום? האפשרות המועדפת עליי היא להפעיל git status ו git diff לפני שמתחילים להכניס דברים לקומיט, ואז להכניס את השינויים לקומיט בצורה מבוקרת - או באמצעות הוספת קבצים מלאים או אפילו באמצעות git add -i שמאפשר לבחור איזה שורות בקובץ צריכות להיכנס לקומיט.

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

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

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

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

האם תוך כדי הפרויקט, כדי לא לבזבז זמן?

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

בפיתוח תוכנה - כל התשובות נכונות.

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

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

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

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

פותח פרויקט ריילס חדש, ומיד מיליון שאלות: רוצה import maps או webpack (או אולי בכלל parcel)? איך לנהל משתמשים? באיזה ספריית בדיקות להשתמש? מה ה Database? האם זו מערכת מלאה שכוללת HTML או שמספיק רק API? איזה כללי Style לשים ב Rubocop? רוצה להשתמש ב tailwind או לכתוב CSS רגיל?

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

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

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

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

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

1. Product Hunt - מרכז השקות של מוצרים ותמיד מעניין לראות מה אנשים אחרים בונים

2. r/programming - חדשות מעניינות על פיתוח תוכנה

3. Hacker News - עוד אתר חדשות מעולה עם עיצוב בסיסי ודיונים ששווים זהב

4. Indie Hackers - פורום ולוח מודעות לסטארטאפים קטנים

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

6. Cybersecurity Dive - חדשות ומאמרים קצרים על אבטחת מידע, לא טכני מדי ולא שיווקי מדי

7. Geektime - ואי אפשר בלי גיקטיים שמלווה כבר שנים את התעשיה בארץ

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

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

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

ולקח רק 7 שנים לבועה הזאת להתפוצץ.

רשימת ההמלצות שהיום מופיעה באותו דף תיעוד מספרת לנו על הכיוון העתידי של ריאקט. היא כוללת את Next.JS, Remix ו Gatsby לפרויקטי ווב, Expo לפרויקטי ריאקט נייטיב ובאותיות קטנות בתוך אקורדיון סגור בפינה מתחבאת האופציה של vite כדי להשתמש בריאקט בלי פריימוורק.

הפיצ'ר הגדול שעובדים עליו בריאקט היום נקרא React Server Components, והוא אמור לאפשר לקוד ריאקט להסתנכרן בין חלקים שרצים בצד השרת לחלקים שרצים בצד הקלאיינט. בצד של האיחסון יישומי ה Full Stack האלה יכולים לרוץ על התשתית של AWS, Netlify, Vercel ועוד באמצעות התקנה מהירה בלחיצת כפתור ובחינם - מה שמזכיר לי לפחות ימים מאושרים ב PHP.

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

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

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

יש שתי גישות להתמודד עם התהליך הבלתי נמנע הזה-

1. אפשר להילחם ב Complexity - לשמור על מודולים קטנים, לשכתב בקיצוניות קוד ברגע שמתחיל להיות מסורבל, הביטוי Move fast and break things מתאר סוג כזה של פיתוח.

2. אפשר להכיל את ה Complexity - לבנות ארכיטקטורות Object Oriented מורכבות, להשתמש ב Type System, לכתוב בדיקות, ללמוד לחיות עם זה שלעולם לא תצליח להבין כל פרט בקוד, ללמוד להשתמש ב Debugger, לכתוב המון תיעוד ו wikis ואפילו להיעזר ב AI כדי לקבל תשובות על הקוד.

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