ארכיון חודשי: אוקטובר 2018

עלילות vim בריבוי שפות

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

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

כמובן שהאדם הזה הוא אני.

כרגע פתרתי את הבעיה, אך בגישה שאינני אוהב אותה.

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

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

אני לא היחיד שעושה את זה. ישנן הפצות שונות של vim, כאשר אחת המפורסמות בהן היא Space-VIM.
היא בנויה להיות גנרית ובעלת יכולת התאמה אישית.

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

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

וכאן מתחילה הבעיה – יש איתו race condition מול תוספים שכן מותקנים אצלי וזו היתה הבעיה.
לגלות את הבעיה לא היה כזה פשוט, היות ויש אצלי למעלה מ140 תוספים שונים (חלקם מכוונים שפה או טכנולוגיה מסוימים) וחלקם כללים יותר, למשל ניהול פרויקטים ב vim, ושימוש בפקודות של vim לשם כך (כן יש גם את זה בvim).
או הוספת תמיכה ל Text Objects (בקרוב פוסטים בנושא) שונים, ובכך אני יכול לכוון את vim שיתמוך בפסקאות על ידי תחביר מסוים במקום הגדרת "טקסט" פשוטה, והרשימה עוד ארוכה.

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

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


כניסה לפרויקט קיים

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

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

התחלה

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

טעויות בכניסה לקוד/פרויקט קיים

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

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

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

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

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

הדרך שלי ללמוד

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

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

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

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

רכיבים קטנים

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

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

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

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

עבור מה השיטה לא מתאימה?

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

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

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

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

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