טעויות של מפתחים צעירים

7 טעויות נפוצות של מפתחים צעירים – ואיך להימנע מהן

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

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

טעות #1 – לא לשאול מספיק שאלות

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

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

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

טעות #2 – להמציא את הגלגל

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

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

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

טעות #3 – לכתוב יותר מדי קוד בבת אחת

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

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

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

טעות #4 – לא להעתיק מאחרים

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

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

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

var sum = 0;
for (var i = 0; i < array.length; i++) {
    sum += array[i];
}

לעומת זאת, חיפוש פשוט בגוגל יראה שניתן לממש גם בשורה אחת:

var sum = array.reduce((a, b) => a + b, 0);

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

טעות #5 – להעתיק קוד בלי להבין אותו

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

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

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

טעות #6 – לעצור כשזה עובד

רבות דובר על definition of done, או במילים אחרות: "מתי מחליטים שמשהו גמור?". מפתחים צעירים נוטים להכריז "משימה הושלמה" מיד כאשר הקוד שלהם רץ בהצלחה בפעם הראשונה, ומדלגים על אחד השלבים החשובים ביותר בכתיבת קוד – בקרת האיכות.

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

  • האם מפתחים אחרים יבינו את הקוד שלי?
  • האם אני אבין את הקוד של עצמי בעוד מספר חודשים / ימים / שעות?
  • האם מחקתי חלקים מיותרים / זמניים / הערות?
  • האם טיפלתי בכל מקרי הקצה? האם הקוד שלי חסון (robust)?
  • האם הקוד מכיל הנחות סמויות? אם כן – האם הן מתועדות?
  • האם דרך המימוש היא סבירה מבחינת יעילות?
  • האם הבדיקות האוטומטיות מכסות מספיק מהקוד?

אם התשובה לאחת השאלות הללו היא שלילית, קחו את הזמן לשפר את הקוד, מבטיח שזה ישתלם.

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

טעות #7 – לפחד מבאגים

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

עצרו!

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

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

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

6 תגובות בנושא “7 טעויות נפוצות של מפתחים צעירים – ואיך להימנע מהן”

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים