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