RAD זו לא רק סביבה

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

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

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

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

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

אחד הדברים המדהימים של עולם הObject Pascal הוא, שחברה בשם Borland לקחה אותו לחיקה. החברה ידועה ביצירת כלים פורצי דרך בתחום התכנות (ותסלחו לי, אבל C++ Builder הרבה יותר טוב מ VC בצורה שמאוד קשה להשוות, ולמרות זאת העדר הולך אחרי VC…). ובתור החברה שפחות או יותר "המציאה" את תחום ה RAD, היא גם הוסיפה תכונות חדשות לשפת Object Pascal. אחת התכונות היא כמו שציינתי למעלה, האפשרות לתפוס במקום אחד, כל חריגה שמתרחשת אצלי בתוכנית. עכשיו במקום לעבור כל קובץ וקובץ (שיש לי שליטה עליו) ולבצע את הפעולות השונות אליו, יש לי רק מקום אחד שאני צריך להיות בו. כך שעכשיו אני כבר לא משכפל קוד, אלא עובד בשיטה של לכתוב פעם אחת ולהשתמש כל הזמן. אני גם גורם לכך שכל שינוי מדיניות בניהול חריגות תתבצע בצורה די מהירה ודי חלקה (יחסית לדרישות וכו') בלי לפספס שום דבר. גם אם מחר יגיע לי מפתח חדש "אשר לא ידע את יוסף" והוא אינו מבין/יודע או יישם מדיניות שכזו בעבר, עדיין הרבה יותר קל ופשוט עבורו להיכנס ולבצע את המשימה. למעשה כל הזמן פיתוח שלי התקצר כרגע, כי אני מתעסק רק עם מקום אחד לביצוע מדיניות, במקום לשנות את כל הפרוייקט. וכמו כן, פתאום אני מקבל שליטה על הצורה שקוד שאין לי באמת שליטה עליו יתנהג כאשר הוא בתוך התוכנית שלי.

אוקי, אז ניתן לנהל חריגות, אני שומע את ה"וואו" (בנימה משועממת), אבל זה לא הכול כמובן 🙂

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

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

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

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

לסיכום:

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

2 מחשבות על “RAD זו לא רק סביבה

  1. עודד

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

  2. ik_5

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

    ב. אוקי נכתוב שגרה, עכשיו נלך לכל מקום שיש חריגה ונשתמש בשגרה… אבל מה קורה אם פספסתי מקום, או שפתאום אני מגלה שהשגרה לא נותנת מענה לכל מקום שאני צריך ? האם אני צריך להתחיל להתסבך בגלל זה ?
    דבר שני, גם בג'אווה, רובי, פרל ואפילו פסקל אתה יכול לדעת מה הנקודה הספציפית בה התרחשה החריגה, ואתה יכול לכתוב קוד בצורה די פשוטה (לפחות בפסקל) שיטפל לך בחריגה ספציפית שנזרקה אליך במקום הזה, גם אם אתה לא מטפל בו באותה נקודה… יש דרך די פשוטה ללזהות מה המחלקה של החריגה ואז לבצע קוד מתאים (תכנות מונחה עצמים "רגיל"):
    if Exception is ECoreDump then …

    תזכור דבר אחד. כשיש לך פרוייקט של 1,000 שורות קוד יהיה אפשרי לעשות את מה שאתה מציע, כשיש לך פרוייקט של 10,000 שורות קוד, זה כבר יהיה יותר קשה, וב 100,000 שורות קוד אתה כבר לא תמצא את הידיים והרגליים כאשר אתה עושה את זה בגישה הזו. log4j בנוי לתת מענה של לוגים, אבל מה קורה שכל סוג של לוג דורש התנהגות אחרת ? אתה הולך לממש מחדש את log4j ?
    עוד דבר הוא, שלא תמיד אתה המפתח והמתחזק היחיד של הקוד, ואם יש לך צוות של יותר מ2 אנשים שעובדים במקביל, העבודה בשיטה הזו נעשת יותר מסובכת וקשה… ראיתי כבר "אה צריך רק לשנות XYZ פה וזה יעבוד גם פה" עם מתודות כאלו שאמורות להיקרא בכל נקודה בקוד שלך, ואז שברת את התמיכה בכל דבר אחר שכבר עבד… כאשר אתה מבדיל בין דברים, אבל במקום אחד, הרבה יותר קל לך לאכוף מדיניות, וכן לפתור בעיות, או להוסיף תכונות בעתיד.

להשאיר תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת /  לשנות )

תמונת גוגל

אתה מגיב באמצעות חשבון Google שלך. לצאת מהמערכת /  לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת /  לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת /  לשנות )

מתחבר ל-%s

This site uses Akismet to reduce spam. Learn how your comment data is processed.