כך תגיעו לשלב של כתיבת קוד ברצף ובלי הסחות דעת

על תיכנות אופטימיסטי כבר שמעתם? הנה כמה טיפים שיעזרו לכם להגיע לשם

מקור: Pixabay

מאת אסף שלי 

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

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

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

שלושה שלבים בפיתוח

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

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

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

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

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

אז איך עושים את זה?

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

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

כמה טיפים

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

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

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

לסיכום

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

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

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

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

Avatar

כתב אורח

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

הגב

10 תגובות על "כך תגיעו לשלב של כתיבת קוד ברצף ובלי הסחות דעת"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
ASD
Guest

בקיצור, תעבדו מהבית וזהו.

יצחק כהן
Guest
ב”ה קודם כל תודה על הכתבה, ממש לעניין אם רוצים רצף עבודה אז א. לא לעבוד ב Open space, ואם כבר עובדים כי אין ברירה אז רק עם אוזניות אטומות (סליחה על החברותיות), ומסך שמסתיר את כולם גם בצדדים ב. חלק מהדברים באמת הובאו כאן, אבל שלב ההכנה, להיכן הולכים הוא חשוב ביותר כדי שתיהיה תמונה ברורה ומטרה ברורה מאוד, במקרים שהתמונה לא מספיק ברורה אפשר להתחיל מנקודה קטנה ומשם בד”כ הריכוז ילך ותחזק ג. אם אתם אוהבים אתרי חדשות חברים בפייסבוק וכו’, קבעו להם זמן רק בסוף היום כי בדרך כלל זה גורם להסחות במחשבה ופוגע מאוד בביצועי העובדים,… Read more »
Arnon Axelrod
Member
תודה אסף על הכתבה. אני בהחלט מסכים אם מה שרשמת לגבי שלב ההכנות לכתיבת הקוד, אבל חולק עליך בהרבה דברים אחרים, בעיקר בתפישה שלך לגבי אג’ייל. 1. קודם כל, העבודה בספרינטים היא ספציפית לסקראם, ולא כללית לאג’ייל. ב-Kanban לדוגמא אין ספרינטים והמטרה היא לצמצם את הזמן מתחילת העבודה על משימה (User Story) כלשהי ועד לסיומה, וכן למקסם את ההספק. הרבה חברות היום משחררות גרסאות לפרודקשן מספר פעמים ביום! 2. המפתח, ובעצם כל הצוות, לא אמור “לקבל” את הדרישות, אלא *להבין את הצורך העסקי* ולמצוא את הפתרון המהיר ביותר לבעיה כדי לקבל עליו פידבק ואז להמשיך ולשפר משם. אם “מעיפים משימות… Read more »
ויק
Guest

יש לך e מיותרת ב development :)… איזה כיף להתקטנן

גב בו
Guest

אני עובד ככה שנים (15-20 שנה)
רק שהרצף הפסימיסטי אצלי לוקח 90% מהזמן
הערכת הזמנים המקורית עם באפר X3
אז יוצא שאני מגרבץ או בווינט או בסידורים 95% מהזמן
וב-5% נותן תפוקה שמתכנת ממוצע נותן ב-250%
ובמבחן התוצאה תמיד הדברים עובדים כי כבר בתחילה אני ממפה את הכשלים ופורם אותם אחד אחד

מתכנת
Guest

איזה שטויות

Eytan
Guest

הבנתי שאין לך מושג על מה אתה מדבר כשכתבת ״להעביר לצוות DevOps”

גדעון
Guest

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

Dog lee
Guest

רק רגע כבר חוזרים למסמכים של 50 עמודים שמסבירים בדיוק מה שצריך וגם את מה שלא

Asaf Shelly
Guest

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

wpDiscuz

תגיות לכתבה: