ניתוח טעויות אופייניות של מתכנתים מתחילים: חלק 1

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

1. פחד מלבקש עזרה מעמיתים מנוסים יותר

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

2. אל תנסו לחפש מידע בעצמכם

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

3. העתק-הדבק עיוור

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

4. לזרוק את הפתרון הלא נכון

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

5. פחד לשאול שאלות על המשימה הנוכחית

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

6. מצפה ליותר מדי מראש הצוות

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

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

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

7. פחד מסקירות קוד

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

8. נטייה לפתרונות מופרכים

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

9. המצאת האופניים

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

10. אל תכתוב מבחנים

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

11. הערות מוגזמות

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

Cat cat = new Cat(); // cat Object

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

12. שם רע

לעתים קרובות, מתחילים מזייפים שמות של מחלקות, משתנים, שיטות וכו'. למשל, כאשר הם יוצרים מחלקה ששמה אינו מתאר כלל את מטרתה. או שנוצר משתנה עם שם קצר, משהו כמו x , וכאשר נוצרים שני משתנים נוספים בשם n ו- y , קשה מאוד לזכור מה x עושה . במקרים כאלה, אתה צריך לחשוב היטב על הקוד וללמוד את הפונקציונליות הזו תחת מיקרוסקופ (אולי באמצעות ניפוי באגים) כדי פשוט להבין מה קורה שם. כאן בא לעזרתנו השם הנכון בקוד שהזכרתי למעלה. שמות נכונים משפרים את קריאות הקוד, ובהתאמה חוסכים זמן בהיכרות, מכיוון שהרבה יותר קל להשתמש בשיטה שבה השם מתאר בערך את הפונקציונליות שלו. בקוד הכל מורכב משמות (משתנים, מתודות, מחלקות, אובייקטי קבצים וכו'), נקודה זו הופכת חשובה מאוד בעת יצירת קוד נכון ונקי. כדאי לזכור שהשם צריך להעביר את המשמעות: מדוע, למשל, המשתנה קיים, מה הוא עושה ואיך משתמשים בו. ואציין שוב ושוב שההערה הטובה ביותר לתיאור משתנה היא שמו הנכון. למחקר מעמיק יותר של הערות ושם נכון, אני ממליץ לך לקרוא את הקלאסיקה הנצחית: "קוד נקי. יצירה, ניתוח ועיבוד מחדש", רוברט מרטין . בהערה זו, החלק הראשון של מאמר זה (הרהורים) הגיע לסיומו. המשך יבוא…