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

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

import scala.jdk.CollectionConverters._

val m = Map("a" -> 10)
m.asJava.get("a", 2, 3)

התוצאה היא 0, למרות ש a נמצא במפה. אפשר לטעון ששני הפרמטרים האחרים בלבלו אותו אבל האמת שגם אם נעביר את המחרוזת a לכל הפרמטרים נקבל את אותו 0. הבעיה האמיתית כאן היא ש get של java.util.Map מצפה לקבל פרמטר אחד. העברת יותר פרמטרים לפונקציה היא טעות שהיתה צריכה להתגלות בזמן קומפילציה.

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

val m = Map("a" -> 10)
m.asJava.getOrDefault("a", 1, 2)

-- Error: ----------------------------------------------------------------------
2 |m.asJava.getOrDefault("a", 1, 2)
  |                              ^
  |too many arguments for method getOrDefault in trait Map: (x$0: Object, x$1: V): V
1 error found

אבל כשקומפיילר תופס בעיות רק ב 99% מהמקרים זה לפעמים יותר מתסכל מאשר שלא יתפוס בעיות בכלל.

עוד שבוע מתחיל וסופי שבוע הם זמן מצוין לפתור עוד תרגיל של Advent Of Code. הפעם אנחנו ביום 14 ועדיין עם מטריצות.

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

אבל כל זה היה הגיוני ב 2015. אולי ב 2018.

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

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

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

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

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

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

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

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

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

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

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

מאיפה יש להם את החוצפה?

וזה לא רק האייפון...

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

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

למה הם מנסים לתשאל את בסיס הנתונים בלי אינדקסים? ברור שזה יעבוד לאט.

מה פתאום הם בונים שאילתת SQL מקלט שמגיע בטופס? הרי אמרתי להם שצריך לנקות את הקלט לפני שמשתמשים בו.

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

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

2. בתור יוצרים עלינו להיות מוכנים לביקורת על המוצרים שלנו ויש לנו את הבחירה - לתקן או להתעקש. ריאקט אומנם מתעקשים על מנגנון ניהול הסטייט שלהם אבל מנגנוני ORM פתרו כמעט לגמרי את הבעיה שאנשים בונים שאילתות SQL בצורה ידנית ולא מאובטחת. גם כשמחליטים "להתעקש" אפשר לוודא שהמשתמשים שלנו מבינים מה הם עושים לא בסדר ואיך מתקנים. בריאקט בגלל זה דואגים להדפיס אזהרה כל פעם שאנחנו מרנדרים קומפוננטות בלולאה בלי key. בסיס הנתונים JanusGraph מדפיס לי אזהרה ללוג כל פעם שאני שולח שאילתה ואין לו אינדקס מתאים בשבילה.

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

אם עדיין לא שמעתם ככל הנראה ריאקט 19 תשוחרר עם תמיכה ב React Forget הקומפיילר החדש מבית ריאקט שאמור להוסיף useMemo אוטומטית לתוכניות שלנו. הנימוקים שלהם לפיתוח הפיצ׳ר (מתוך הפוסט) היו-

1. כתיבת useMemo ידנית מלכלכת את הקוד.

2. קל לטעות כשצריך להחליט ידנית למה לעשות Memoization.

3. תוספת הקוד מעמיסה על התחזוקה.

הנה משפט המפתח מתוך הפוסט-

Our vision is for React to automatically re-render just the right parts of the UI when state changes, without compromising on React’s core mental model.

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

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

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

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

3. הוספת מנגנונים כמו React Forget רק מרחיקה אותנו מפיתרון הבעיות האמיתיות של ריאקט. במובן הזה סיגנלים היו יכולים להיות תוספת הרבה יותר מועילה ומעניינת.

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

בשביל לקחת בסקאלה (או Java) את השעה הנוכחית ולשמור אותה כמחרוזת אוכל להשתמש בקוד הבא:

import java.time.*
import java.time.format.DateTimeFormatter

LocalTime.now().format(DateTimeFormatter.ISO_LOCAL_TIME)

והמחרוזת שתתקבל עשויה להיראות כך:

"16:51:44.748375"

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

14:54:10.140198Z

למה הם התכוונו? מאיפה ה Z הגיע? ואיך אני גם מקבל אחד?

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

OffsetTime.now(ZoneId.of("UTC")).format(DateTimeFormatter.ISO_OFFSET_TIME)

ה Z מסמן שזוהי תווית זמן באזור זמן UTC. אזורי זמן אחרים כבר מקבלים סימון יותר ברור לדוגמה עבור ישראל נקבל:

scala> OffsetTime.now(ZoneId.of("Israel")).format(DateTimeFormatter.ISO_OFFSET_TIME);

val res5: String = 16:57:24.769026+02:00

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

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

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

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

git config --replace-all user.name elite-hacker
git config --replace-all user.email hacker@theboss.com

ואז הכניסו קומיט למערכת. יכול להיות גם ריק, והפעילו git log. מה הפרטים שאתם רואים בקומיט?

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

הדרך של גיט לאמת את הזהות שלכם בקומיט היא חתימה על קומיטים. כאן יש מדריך איך לקנפג הכל בגיטהאב: https://gist.github.com/troyfontaine/18c9146295168ee9ca2b30c00bd1b41e

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

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

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

3. האקרים ממילא יודעים לזייף את החתימות שלנו אז בשביל מה להתאמץ.

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

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

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

3. אז למה לעשות להם חיים קלים? שיתאמצו קצת ההאקרים.

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

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

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

את הבדיקות כותבים לפני או אחרי הקוד?

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

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

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

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

התוכנית המקורית שלי לפוסט סופשבוע היתה לפתור ולפרסם עוד יום של Advent Of Code, אבל מפה לשם את כל זמן הכתיבה בזבזתי על שאילתה מסובכת מדי לבסיס הנתונים שבסוף גם היא לא עבדה, ולכן במקום אני רוצה לשתף שלוש נקודות אליהן כדאי לשים לב כשהולכים מכות עם שאילתות (ובעצם עם פריימוורק באופן כללי)-

1. לפעמים זה שווה את המאמץ. יש שאילתות SQL שאחרי שמצליחים לכתוב אותן מבינים משהו חדש על SQL. כן יש דבר כזה Window Functions ואם צריך להשקיע עכשיו שעתיים בללמוד איך הן עובדות זה ממש שווה את ההשקעה.

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

3. לפעמים שאילתות מסובכות הן רמז לבעייה במבנה הטבלאות.

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