Code and Fix Model

תמלול ההרצאה: Code and Fix Model

הטקסט המלא של הדקות הראשונות בהרצאה «Code and Fix Model» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

1. 00:07

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

2. 00:24

   lesson objectives, מטרות השיעור, introduction, איזשהו מבוא כזה קצר למודל, the code and fix model, נדבר על המודל עצמו, ו-advantages and disadvantages of the model, נדבר על היתרונות והחסרונות של המודל code and fix, הקדמה The code-and-fix model is usually the one that project teams fail into by

3. 00:52

   default. It requires some idea of what the product requirements are. אוקיי, אז ה-code-and-fix זה איזשהו מודל שהוא הרבה פעמים מיושם כברירת מחדל על ידי פרויקטים או בחברות שונות, או שהרבה פעמים רוצים ליישם מודל אחר יותר חכם אבל משום מה בסופו של דבר מתכנסים למודל הזה.

4. 01:22

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

5. 01:44

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

6. 02:01

   The Code and Fixed Model זה איזשהו מבנה גרפי של המודל. כאשר יש לנו, מתחילים מפה, יש לנו Product Specification Usually Informal, יש איזשהו ספק ככה לאו דווקא פורמלי יותר משיחות פסדרון, שיחות טלפון, לאו דווקא מסמכים באמת מסודרים.

7. 02:22

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

8. 02:56

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

9. 03:22

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

10. 03:41

    Get a rough idea of what you need אז כדי לבוא ולעשות את הפרויקט הזה צריך איזושהי הבנה מה בגדול לפחות מה בגדול צריך אם לא בפרוטרוט זאת אומרת דרישות אם לא דרישות בגובה 100,000 רגל כאילו מספיקות.

11. 04:06

    מספיק שמישהו יבוא ויגיד אני רוצה תוכנה לניהול יהלומים שבה יהיה איזשהו אובייקט שהוא זה שבוא נגדיר יהלומים חדשים הוא לא יגיד לי איזה שדות הוא רוצה הוא לא יגיד לי איך הוא רוצה שזה יתנהג הוא רק יגיד לי זרוק לי את האובייקטים שהוא רוצה make a simple design אז יש לנו איזשהו רעיון

12. 04:27

    כללי או מספר דרישות ככה כלליות אנחנו יכולים לעשות אפיון כללי מאוד ראשוני proceeds into a long repeating cycle of coding testing and fixing bugs ואז אחרי שיש לנו את האפיון הראשוני אנחנו באים ומתחילים לכתוב אותו גורמים לכתוב אותו מעבירים אותו לבדיקות הבדיקות מוצאים באגים,

13. 04:49

    מתקנים, התיקון דורש כתיבת קוד או שינוי קוד, מעבירים עוד הפעם לבדיקות וככה עד שמגיעים לנקודת זמן שיותר לא מתקנים ובסוף release the product.

14. 05:02

    אלה השלבים בגדול של המודל. Very little time for planning and documenting. מעט מאוד זמן שוב עדיין לתכנון ולדוקומנטציה כי יש לנו איזשהו דרישות ככה בגדול, ואנחנו לא נתחיל לבזבז זמן עליהם למסמכים ולתכנון יותר מדי.

15. 05:33

    A project team can show results immediately by creating a prototype. ואז יש לנו, למעשה יש לנו איזשהו סל של דרישות ככה מאוד גדול, או לאו דווקא שיורדים איתו לפרוטרוט, אבל עם זה אפשר ליצור איזשהו אף טיפוס של תוכנה,