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

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

13. אי עמידה בהנחיות סגנון קידוד.

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

14. להתייאש מטעויות

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

15. אי יישום בטיחות חוט.

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

16. עבודה יתרה

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

17. הזנחת כישורי אנגלית

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

18. רדיפה אחר טכנולוגיה אופנתית

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

19. לימוד מספר טכנולוגיות ו/או שפות שונות בבת אחת

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

20. מטרות שנוסחו בצורה לא נכונה

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

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

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

21. תיאוריה ללא פרקטיקה

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

22. פרפקציוניזם מוגזם

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

23. אי חשיבה על אדריכלות

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

24. תסמונת המתחזה

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

25. לעתים רחוקות לבצע התחייבויות

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