ניתוח טעויות נפוצות שנעשו על ידי מתכנתים מתחילים, pt. 1

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

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

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

2. לא מנסה לחפש מידע בעצמך

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

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

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

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

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

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

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

6. הצבת ציפיות גבוהות באופן לא מציאותי להובלת הקבוצה

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

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

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

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

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

8. נטייה להחלטות עלומות

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

9. המצאת הגלגל מחדש

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

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

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

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

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

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

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

12. שם רע

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