משימות טיפוסיות של מפתח Java בפרויקט

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

1. תכנון פתרונות חדשים

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

2. כתיבת פונקציונליות חדשה

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

3. כתיבת מבחנים

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

4. איתור ותיקון באגים

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

5. סקירת קוד

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

6. ניתוח קוד

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

7. Refactoring קוד

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

8. כתיבת תיעוד

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

9. מפגשים שונים

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

10. ביצוע/העברת ראיונות

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