אל תסכים לפתח משהו שאתה לא מבין

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

הנקודה שאני רוצה להבהיר היא שאיכות הקוד (והתוצר הסופי) קשורה קשר הדוק למידת המודעות של האנשים שמעצבים וכותבים את הקוד למה שהם עושים.

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

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

רמה ראשונה של הבנה: למה זה לא עובד?

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

הסכימה הסטנדרטית נראית כך:

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

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

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

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

רמה שנייה של הבנה: למה זה עובד?

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

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

ואז אתה עובר לתרחיש ב' אתה חוזר על התרחיש בניסיון לעורר שגיאה, אבל - הפתעה! - עכשיו הכל עובד כמו שצריך. כדי לאשר את הניחוש שלך, אתה מבטל את השינויים שביצעת במהלך העבודה על באג A, ובאג B חוזר. תיקון הבאגים שלך פתר את שתי הבעיות. בַּר מַזָל!

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

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

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

רמה שלישית של הבנה: למה זה עובד?

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

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

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

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

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

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

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

רמה רביעית של הבנה: ???

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

מקור: www.habr.com