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

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

בלי לעשות סצינה, בלי להגיד לילד ש"אתה רואה זה מסוכן אז אסור ללכת על הגדר",

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

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

1. גלגלי עזר

2. לא בשבילי

3. יותר מהר מאופניים

4. הודעות קומיט מוצלחות ומוצלחות פחות

5. 8 שאלות שכדאי לברר לפני שמתחילים לעבוד כמתכנתי Front End

חוץ מפוסטים הספקתי להעלות לכאן גם 3 קורסים מלאים (פייתון מתקדם, גיט ו JavaScript ES6), והתחלתי להעביר וובינרים בממוצע פעם בשבוע, ויש לנו כבר 29 שעות של תוכן מוקלט מהוובינרים האלה על מגוון נושאים טכנולוגיים.

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

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

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

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

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

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

״אני חייב סולם חדש נשבר לי החווק השלישי אתמול״

״המרחק בין חווקי הסולם לא יעלה על 30 סנטימטרים.״

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

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

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

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

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

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

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

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

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

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

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

וכדי להחליט על ההזזה עצמה כדאי לזכור את מטרת הבדיקות:

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

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

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

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

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

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

git config alias.log "log --oneline"

וגיט התעלם באלגנטיות.

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

$ git config log.abbrevCommit false
$ git config format.pretty oneline

פתרה את הבעיה ומציגה יומן שנראה כך:

$ git log

5982b5b (HEAD -> master, dev) created a readme file
4945c9c fixed jade template
7b1978d add debug message
943e263 initial commit

מורגן הוא מודול תיעוד הבקשות של אקספרס והוא נמצא בכל פרויקט אקספרס שתיצרו עם Express Generator. תוכלו לזהות אותו לפי השורה הבאה בקובץ app.js.

app.use(morgan('dev'));

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

אני מקווה שאתם מכירים את ההמלצה לחלק את השינויים שלכם לקומיטים לפי נושאים, כך שכל קומיט יתאים ל Issue במערכת ניהול ה Issues שלכם. אבל מה עושים אם שכחתם את עצמכם בהתלהבות של הקידוד והתעוררתם שעתיים אחרי עם 5 שינויים מ-5 נושאים שונים באותו קובץ?

אל תדאגו - אני יודע גיט.

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

# My Cool Project

This is a demo project

ועכשיו נוסיף לו שני בלוקים של טקסט שאמורים להיות מפוצלים ל-2 קומיטים שונים:

# My Cool Project

This is a demo project

# Installation
you need to download this app and install it if you want to use it

fixing first issue
fixing second issue
fixing third issue

במקום לעשות cut-and-paste עם קובץ נוסף אפשר פשוט להפעיל את git add במצב אינטרקטיבי:

$ git add --interactive -p

diff --git a/readme.txt b/readme.txt
index d3ef36a..a53fb88 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,3 +1,12 @@
 # My Cool Project

 This is a demo project
+
+# Installation
+you need to download this app and install it if you want to use it
+
+fixing first issue
+fixing second issue
+fixing third issue
+
+

Stage this hunk [y,n,q,a,d,e,?]? 

גיט מזהה את השינויים ושואל אולי מה לעשות. כרגע כל השינויים צמודים אחד לשני ומבחינת גיט זה נראה כמו שינוי יחיד. אני רוצה לקחת את הבלוק שמתחיל ב Installation ולשמור אותו בתור קומיט משלו ולכן אני לוחץ e כלומר edit (במצבים בהם הבלוקים לא היו רציפים גיט היה מבצע את הפיצול בצורה אוטומטית). בתגובה git יפתח את ה EDITOR המועדף עליי ויציג לי מסך עריכה שנראה כך:

# Manual hunk edit mode -- see bottom for a quick guide.
@@ -1,3 +1,12 @@
 # My Cool Project

 This is a demo project
+
+# Installation
+you need to download this app and install it if you want to use it
+
+fixing first issue
+fixing second issue
+fixing third issue
+
+
# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.

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

# Manual hunk edit mode -- see bottom for a quick guide.
@@ -1,3 +1,12 @@
 # My Cool Project

 This is a demo project
+
+# Installation
+you need to download this app and install it if you want to use it
+
# ---
# To remove '-' lines, make them ' ' lines (context).
# To remove '+' lines, delete them.
# Lines starting with # will be removed.
# 
# If the patch applies cleanly, the edited hunk will immediately be
# marked for staging.
# If it does not apply cleanly, you will be given an opportunity to
# edit again.  If all lines of the hunk are removed, then the edit is
# aborted and the hunk is left unchanged.

שמירה ויציאה ותראו את הסטטוס:

$ git status
On branch main
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   readme.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   readme.txt

הקובץ readme.txt מופיע גם בתור משהו שייכנס לקומיט הבא וגם בתור שינויים שלא ייכנסו לקומיט הבא. הפעלת diff תראה לנו את ההסבר:

$ git diff

diff --git a/readme.txt b/readme.txt
index 6076e63..a53fb88 100644
--- a/readme.txt
+++ b/readme.txt
@@ -5,3 +5,8 @@ This is a demo project
 # Installation
 you need to download this app and install it if you want to use it

+fixing first issue
+fixing second issue
+fixing third issue
+
+

בלוק הטקסט השני, שמסומן ב +, נמצא אצלי בתיקיית העבודה אבל לא ב Staging. לעומתו הבלוק שמעליו כן נמצא ב Staging area ולכן לא מופיע ב diff.

נפעיל קומיט כדי לשמור את השינוי:

$ git commit -m 'add installation instructions' 

ובסטטוס הבא נראה שהקובץ עדיין ב Modified אבל הפעם רק החלק השני שלו. עכשיו אפשר להמשיך ל add ו commit נוספים כדי להכניס את בלוק הטקסט השני:

$ git add .
$ git commit -m 'fixed more issues'

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

commit 3612ce51ab22876a6337b56050a1f16bff9ea9e9 (HEAD -> main)
Author: ynonp <ynonperek@gmail.com>
Date:   Sun Dec 23 14:49:12 2018 +0200

    fixed more issues

commit b4c25f7ac3cb7fdd3d8101750ff03cb2b3d7b5e1
Author: ynonp <ynonperek@gmail.com>
Date:   Sun Dec 23 14:47:38 2018 +0200

    add installation instructions

אוהבים גיט ורוצים ללמוד להשתמש בו טוב יותר? אני חושב שתהנו מקורס Git Hero שיש לנו כאן באתר שכולל מעל שש שעות של הסברים, דוגמאות וטיפים לשימוש חכם יותר ב Git. פרטים והרשמה בקישור https://www.tocode.co.il/bundles/git