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

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

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

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

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

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

3. כתיבת מבחנים לפונקציונליות

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

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

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

5. סקירת קוד

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

6. ניתוח קוד

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

7. Refactoring של קוד

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

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

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

9. השתתפות בעצרות שונות

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

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

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