טיפים קצרים וחדשות למתכנתים
אם רק החיים היו יותר פשוטים. באמת. כי חיים פשוטים מובילים לקוד פשוט, ולהיפך, כשהחיים מסתבכים הקוד מסתבך איתם. יש אנשים שיגידו לכם שאם רק תכתבו קוד פונקציונאלי, או קוד מונחה עצמים, או בשפה כזאת או אחרת, אז הקוד יהיה פשוט ויתמודד יפה עם שינויים.
הם טועים.
קוד מסתבך כי החיים מסתבכים כמו שנראה תכף בדוגמה מ Advent Of Code. אבל אל תדאגו יש גם נקודת אור בסוף הסיפור. וגם פייתון, כי צריך קצת הפסקה מכל הקלוז'ר.
זה יעבוד גם מחר בבוקר?
זה יעבוד גם אחרי שידרוג גירסה?
זה יעבוד גם אחרי Refactoring?
זה יעבוד גם עם נתונים של פרודקשן?
זה יעבוד גם כשנעבור למערכת הפעלה אחרת?
זה יעבוד גם עבור משתמשים מהודו?
זה יעבוד גם אחרי שנחזור מגיבוי?
זה יעבוד גם כשיהיה עומס על המערכת?
שום מערכת לא עובדת בכל המצבים. ככל שנקפיד להיות ברורים לגבי המגבלות של הקוד שלנו, כך יהיה יותר קל להשתמש בו (ולשבור אותו) במערכות אמיתיות.
הי חברים,
באיחור קל אני שמח להזמין אתכם להצטרף לאחד הוובינרים הקרובים שלנו. את הוובינרים אני מעביר כל יום חמישי בעשר בבוקר, והקלטות שלהם זמינות כאן באתר בדף הקלטות מוובינרים.
אני משתדל לבחור נושאים שקשורים לנושאי הקורסים ומרחיבים אותם. אם יש לכם רעיונות או חלומות על נושאים שהייתם רוצים ללמוד שלחו לי מייל ואנסה להוסיף אותם בחודשים הבאים. זאת הרשימה לשלושת החודשים הקרובים:
בהתמודדות עם אתגרים אנחנו שמים לב לשני רצונות מנוגדים ובעייתיים-
חלק מהזמן אנחנו מתעקשים לפתור הכל לבד, כאילו כדי להוכיח לעצמנו או לעולם שאנחנו יכולים.
חלק מהזמן אנחנו מיואשים לגמרי ורק רוצים להסתכל בפיתרון או שמישהו יסביר לנו מה עושים.
הבעיה בלפתור הכל לבד היא שכשאתם לא מצליחים זה יכול לייאש ולתקוע; ואם אתם מצליחים הכל זה אומר שלא בחרתם אתגרים קשים מספיק.
הבעיה בלהסתכל בפיתרונות של אחרים ולהעתיק היא שאתם לא מאמנים את השרירים הנכונים של פיתרון בעיות, ושרוב האתגרים בחיים האמיתיים לא דומים לשום דבר שכתוב בספר.
הפיתרון לאנשים שרוצים להשתפר וללמוד הוא להתרגל לחפש רמזים: לשאול איפה אפשר לקרוא יותר על XYZ, או לברר על איזה נושאים כדאי ללמוד כדי להתמודד טוב יותר עם הבעיה, או להסתכל על פיתרונות של בעיות דומות ולנסות להתאים אותם לאתגר שלנו, או כל חיפוש דומה.
רמז מאפשר לנו לשלב - גם ללמוד דברים חדשים, וגם ליישם אותם על האתגרים שעכשיו אנחנו מתמודדים איתם. שילוב כזה, לאורך זמן, מרחיב אופקים והופך אותנו לפותרי בעיות טובים יותר.
תרגילי Advent Of Code הם המקום המושלם להתאמן על שפת תכנות חדשה, ובמיוחד כזאת שיודעת להתמודד יפה עם נתונים ומניפולציות עליהם. קלוז'ר בהחלט מתאימה להגדרה. את יום 5 הצלחתי לפתור עם טריק פשוט אחד - ועוד קצת קוד מסביבו. הנה הסיפור המלא.
בגיטהאב אנחנו יכולים להסתכל בממשק הגרפי אחורה ולראות את כל הדיונים שהיו על Pull Request וגם מי אישר כל PR. אבל אם נחליט לקחת את הפרויקט החוצה מגיטהאב, או אם אנחנו עובדים בגיט משורת הפקודה, המידע הזה כבר לא זמין.
לא מזמן כתבתי כאן על מנגנון הפתקים בגיט. היום אני רוצה להראות דוגמה לשימוש בהם כדי שכל פעם שמישהו מאשר Pull Request השם שלו ייכתב בתוך הקומיט בתור Note, כך שנוכל להיזכר אחרי מכל מקום.
אחד השלבים המתסכלים בלימוד טכנולוגיה או שפה מגיע אחרי שאנחנו כבר מבינים את הבסיס, מצליחים לפתור תרגילים פשוטים ואפילו מצליחים להבין קוד שאנחנו רואים בפיתרון או תוכנית דוגמה.
אבל לא מצליחים לכתוב.
זה יכול להיות שאנחנו נתקעים ממש בהתחלה, פוחדים שנבחר את התבנית הלא נכונה או לא יודעים בדיוק איזו תבנית לבחור. חוששים שנעשה צעד שעוד שבוע נתחרט עליו, או הכי גרוע - מתחילים לכתוב והכל יוצא יותר מסובך בהרבה מכל דוגמה שראינו, עד לרמה שקשה להבין לאן נעלם כל הסיבוך הזה בתוכניות הדוגמה, ואם מישהו לא עשה עלינו איזה תרגיל.
אבל אין שום תרגיל.
הדרך היחידה ללמוד לכתוב היא לכתוב, ולכתוב כמה שיותר. לעבור את השלב הזה שדברים לא עובדים, ואז את השלב שהם מסובכים, ואז לאט לאט לשים לב לפיתרונות יותר פשוטים עד שדברים מתחילים להתחבר. המשך לימוד בקורס, המשך קריאה או אפילו שיעורים פרטיים לא יעזרו כאן. השרירים של הכתיבה צריכים להתרגל שגם הם צריכים לעבוד.
התחושה שאני לא יודע לכתוב היא הסימן הכי טוב לסיים את הקריאה ולהתחיל לעבוד.
בכתיבת מערכות תוכנה אנחנו יודעים (בדרך כלל) לאזן בין מהירות הפיתוח לביטחון. בקצה אחד של הסקאלה, מי שבונה קוצב לב צריך לעשות הכל כדי להגיע לאפס טעויות, ובקצה השני אם אתם בונים אתר משחקים אונליין אתם מוכנים לחיות עם העלאת גירסה שבה משחק מסוים לא עבד או עבד עם באג. תמיד אפשר להעלות גירסת תיקון.
את אותו הגיון אפשר לקחת גם לקריירה האישית או הלימודית שלנו-
האם אני מוכנה ללמוד טכנולוגיה גם אם היא בסוף לא תהיה "הדבר הגדול הבא"? או שהזמן שלי קצוב ואני צריכה אפס טעויות בבחירת נושאי הלימוד?
האם אני מוכנה להתפרץ בדיון גם אם אני לא בטוחה במה שיש לי להגיד, או שאני שואפת ל"אפס טעויות" ומוכנה לדבר פחות ובלבד שתמיד אגיד דברים שאני בטוחה בהם.
האם אני מוכנה להעביר הרצאה לצוות על נושא שאני לא מומחית בו, או שאני מעדיפה לא לקחת סיכונים ולכוון ל"אפס טעויות".
הטריק הוא שכמו במערכות, אי אפשר להחזיק במקל בשני הקצוות. אפס טעויות מכתיב התקדמות איטית יותר ומעט מאוד חדשנות. לרוב המתכנתים והמתכנתות שאני מכיר, מדיניות של אפס טעויות בקריירה לא שווה את המאמץ.
הדבר שאני הכי אוהב בעבודה עם לקוחות הוא כשמתקילים אותי בשאלה שלא חשבתי עליה לפני. כך היה כשעזרתי היום ללקוח עם גיט ובדרך למדתי על מתג סופר שימושי של rebase.
הכלי awk היה לאורך שנים ועודנו אחד הכלים המרכזיים לעיבוד טקסט בסביבת יוניקס. הוא פותח בשנות ה 70 בחברת Bell Labs על ידי שלושה מפתחים ששמותיהם נתנו לכלי את שמו: Alfred Aho, Peter Weinberger ו Brian Kernighan. הייחודיות של awk היא שמצד אחד הוא כולל אלמנטים מתקדמים משפות תכנות כמו משתנים, מערכים, מילונים ואפילו אפשרות להגדיר פונקציות; אבל מצד שני זה כלי סקריפטים שהשימוש בו מאוד ממוקד לפיענוח טקסטים.
היכרות עם awk תאפשר לנו להעלות את הרמה של הסקריפטים שאנחנו כותבים וגם לפתור בעיות הקשורות לטקסט במהירות ומשורת הפקודה.