http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/intro.html :

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/testing/ :

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/testing/motivation.html :

למה אנו מעוניינים לכתוב בדיקות אוטומטיות?

1. כדי למנוע באגים. על-ידי כתיבת בדיקות לפני כתיבת הקוד העיקרי אנו מוודאים שהוא מתנהג
בהתאם למה שהן מתארות.

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

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/testing/demo/ :

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

דרך אחת לכתוב תסריט בסיסי שבודק אותה, היא כך.

הוא יזרק חריגה אם ביצוע חיבור של 2+2 נכשל, ויצא בהצלחה אם הכל בסדר.

הכל בסדר, אז הבה נכתוב בדיקה נוספת.

הפעם זה נכשל.

בעקבות זאת, אנו צריכים לתקן את הקוד העיקרי של התוכנית.

והתסריט המתאים מצליח.


http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/testing/demo/test-more.html :

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

השגרה ‪is()‬ משווה את התוצאה שהתקבלה לתוצאה שאנו מצפים לה (באמצעות eq). יש גם
את ‪ok()‬ שרק בודקת את אמיתות הערך, ‪is_deeply()‬ שמבצעת השוואה עמוקה
של מבני נתונים מקוננים, ושגרות אחרות.

ייתכן שגם שמתם לב להערות הסולמית-TEST. אלו הן הערות צד של ‎Test::Count שמאפשרות
לנו לעקוב אחרי מספר הצהרות הבדיקה שהגדרנו ולעדכן אותו בראש הקובץ.

הפלט יהיה:

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/testing/types.html :

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

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

שימוש בפרל כדי לבדוק קוד של שפות תכנות אחרות:

ניתן לעשות בה שימוש:

ראו את הדרכים השונות כדי להריץ תוכניות שורות פקודה ואת יכולות הסוקטים והרישות שלה.

לבדיקת ממשק משתמש גרפי, ראו את Win32-GuiTest ו-X11-GUITest

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/testing/mocking.html :

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/version-control/ :

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

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/version-control/motivation.html :

היתרונות של שימוש במערכת ניהול גרסאות:

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

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

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

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/version-control/mercurial-demo.html :

הדגמה.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/accessors/ :

שיטות גישה ("נגשים"? אקססורים) - הן דרך לבצע אבסטרקציה לגישה לשדות
של עצמים, מאחורי קריאות לשיטות/מתודות. לדוגמה, אנו יכולים לקרוא
ל- ‪$person->age()‬ כדי לקרוא את גילו של ‪$person‬ ול-‪$person->age(21)‬
או ‪$person->set_age(21)‬ כדי לשנות את ערך הגיל שלהם ל-21.

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/accessors/example.html :

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/accessors/motivation.html :

מוטיבציה: אז מדוע כדאי שנשתמש באקססורים במקום שנעשה גישה ישירה
ל-‪$person->{'age'}‬ לשדה של העצם?

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

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

3. הממשק החיצוני שמסופק על-ידי שיטות/מתודות נקי יותר וקל יותר לתחזוקה
של תאימות לאחור מאשר גישה ישירה לשדות של העצם.

4. ייתכנו גם סיבות אחרות, כמו מיקבול יותר טוב, התמדה (persistence) וכו.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/accessors/cpan-modules.html :

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

1. המודול Class-Accessor - אחד הראשונים ועדיין פופולרי. כתוב בפרל טהורה ואין לו תלויות חיצוניות.

2. המודול Class-XSAccessor - כתוב חלקית בסי וב-XS והוא מהיר מאוד. השיטות
שהוא מייצר יותר מהירות מכתיבת אקססורים ביד כפי שהראנו.

3. מערכת האובייקטים Moose ־ מקיפה מאוד ומספקת דברים רבים מלבד אקססורים.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/new-features/ :

תכונות שימושיות בגרסאות מאוחרות יותר של פרל.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/new-features/use-base.html :

זוהי דרך להגדיר את המחלקות מהן יורשים (במקום ‪@ISA‬). ב-Moose עושים שימוש
ב-extends ֹויש גם את "use parent".

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/new-features/lexical-filehandles.html :

ידיות קובץ לקסיקליות.

רצוי להשתמש במשתנים לקסיקליים (שמצהירים עליהם באמצעות my) בתור ידיות של קבצים
או מדריכים (directories), משום שהטווח (scope) אחריו הם נסגרים הוא קטן יותר.

המחלקות של IO::Handle - מספקות אבסטרקציות לקסיקליות ומונחות עצמים לידיות של
קלט/פלט.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/local-keyword/ :

המילית local - עובדת רק על משתנים של מרחבי שמות (או packages בשמן הפרלאי) ומתנהגת
על ידי טיווח דינמי (dynamic scoping).

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/local-keyword/use-and-abuse.html :

בד"כ רצוי שלא להשתמש בה, אבל ייתכן שתתקלו בה.
ראו את הקישורים.


http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/pod-documentation/ :

שימוש ב-POD עבור תיעוד

פוד (POD) הוא קיצור ל-"Plain Old Documentation" והינו שפה קלילה לכתיבת תיעוד
עבור תוכניות פרל, מודולי פרל, ופרל עצמה.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/pod-documentation/demo.html :

הדגמה של פוד.

כיצד לכתוב: חלקי טקסט של פוד מתחילים בהוראת פוד יחידה, בשורה חדשה
 וממשיכים עד להוראה ‪"=cut"‬ שהיא גם בשורה משלה. מספר הוראות פוד:

כותרות. ככל שמספר ההוראה קטן יותר כך היא ראשית יותר.

טקסט רגיל בא בפסקאות ללא סימונים מיוחדים.

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

קודים של עיצוב:

‪I<text>‬ - לטקסט בגופן נטוי

‪B<text>‬ - לטקסט מעובה.

‪C<text>‬ - לטקסט בגופן בגודל קבוע.

‪L<text>‬ - לקישורים.

‪E<lt>, E<gt>, etc. are escapes.‬

רשימות בפוד - ‪=over 4‬ ואחר-כך ‪=back‬ לחזרה: כוכביות/בולטים, מספרים, ורשימות
של הגדרה.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/pod-documentation/pod-testing.html :

המודול Test-Pod מאפשר לבדוק את תקינות התחביר של POD.

המודול Test-Pod-Coverage מנסה לבדוק שכל ממשק המשתמש הפומבי מתועד באמצעות פוד.

בד"כ Module-Starter ומודולים דומים יחוללו תסריטי בדיקה שלהם כחלק מהשלד של
ההפצה תואמת ה-CPAN שלכם.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/pod-documentation/literate-programming.html :

”תכנות משכיל“

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/pod-documentation/extensions.html :

הרחבות לפוד.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/module-build-and-starter/ :

מבוא ל-Module-Build ו-Module-Starter.

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

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/module-build-and-starter/invocation.html :

כיצד להריץ את Module-Starter. ניתן לכתוב ‪--help‬‪‬ כדי לקבל עזרה. להלן הרצה לדוגמה.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/module-build-and-starter/commands.html :

הדבר הראשון שצריך לעשות הוא להיכנס למדריך ש-Module-Starter יצר ולהריץ perl Build.PL.

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

עכשיו הבה נריץ ‪./Build‬ ו-‪./Build test‬ .

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

אחרי שהרצנו ‪./Build‬, נריץ ‪./Build test‬ שמריץ את הבדיקות האוטומטיות
ש-Module-Starter חולל עבורנו. כפי שניתן לראות השורה אומרת שכל הבדיקות
עברו בהצלחה. במקרה שהן לא, אנו צריכים לתקן, או את הקוד, או את הבדיקות (בהתאם
למה מהם שאינו נכון).

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/module-build-and-starter/coding.html :

הוספת קוד בעל משמעות:

אם נסתכל בקוד של הקבצים של ‪lib/…*.pm‬ נראה שבפועל אין שם שום דבר. אז עכשיו
הגיע הזמן להוסיף קוד בעל משמעות למודולים. קודם לכן נוסיף בדיקות. נוסיף
את קובץ הבדיקה הזה.

כעת עלינו להוסיף אותו לקובץ MANIFEST כדי שיכלל באריזה של המודול. אחרי
שעשינו את זה, נריץ את ‪./Build test‬ כדי לראות את הבדיקות נכשלות:

כעת עלינו לתקן את הבדיקות. נפתח את הקובץ ונכתוב את זה:

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

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

ה"כתבו בדיקות חדשות", "גרמו להן לעבור", "שפצו את הקוד", הם המחזור של הפיתוח והתחזוקה,
וכלים של פרל כמו Module-Build מקלים על המלאכה.

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/module-build-and-starter/boilerplate.html :

להיפטר מהתמליל החוזר.

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

למזלנו הוא גם מחולל תסריט ב-‪t/boilerplate.t‬ שבודק להימצאות התמליל החוזר
ומדווח על כך. אולם, הבדיקות מסומנות כ-TODO מה שגורם לרסן הבדיקות להתעלם מהכשלון
שלהן בד"כ. כדי להסיר סטאטוס זה פתחו את ‪t/boilerplate.t‬ בעורך הטקסט שלכם
והסירו או בטלו את השורה הבאה בהערה.

לאחר שביצענו את זה, אנו מקבלים כשלונות של הבדיקות כאשר אנו מריצים
את ‪./Build test‬

http://www.shlomifish.org/lecture/Perl/Newbies/lecture5/conclusion/ :

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

1. המסה שלי ”מה הופך תוכנה לאיכותית?“.

2. המאמר ”איכות תוכנה“ בוויקיפדיה.