WEBVTT

00:00:00.000 --> 00:00:07.680
מוכנים למד מינוס עשרה ימים של Microsoft 365, Copilot, בינה מלאכותית, Azure, והאנשים שמעצבים את עתיד העבודה.

00:00:07.880 --> 00:00:12.340
בינואר הקרוב, M365Con חוזר, ואנחנו הולכים בגדול.

00:00:12.520 --> 00:00:18.580
הצטרפו אלינו למפגשים חיים, הדגמות מהעולם האמיתי, וידע פרקטי עם VPS ומומחים בתעשייה מכל העולם.

00:00:18.800 --> 00:00:21.880
בלי מצגות גנריות, בלי מילים חלולות ללא הפסקה.

00:00:22.040 --> 00:00:29.300
אנחנו מתמודדים עם האתגרים האמיתיים, Copilot Studio, סוכני AI, Fabric, הבטחה, משילות ואוטומציה.

00:00:29.300 --> 00:00:35.060
בין אם אתם אנשי איט, מפתחים או מובילים עסקיים, יש מפגשים שתוכננו במיוחד עבורכם.

00:00:35.480 --> 00:00:40.340
עם עשרה ימים מלאים, תוכלו לחקור טכנולוגיות רבות ולהתחבר לקהילה גלובלית.

00:00:40.780 --> 00:00:44.700
צפו בשידור חי וקחו תובנות פרקטיות בחזרה לארגון שלכם.

00:00:44.980 --> 00:00:49.260
ינואר 2027, עשרה ימים, קהילת Microsoft 1.

00:00:49.500 --> 00:00:50.920
ההרשמה פתוחה עכשיו.

00:00:51.460 --> 00:00:56.200
כנסו להם 365Con.net והבטיחו את מקומכם עוד היום.

00:00:56.200 --> 00:00:59.040
זה M365Con.net.

00:00:59.300 --> 00:01:05.160
הצטרפו עכשיו ב-M365Con.net ונתראה בשידור חי בינואר.

00:01:05.260 --> 00:01:11.840
אם פתחתם אי פעם פרויקט ומיד הרגשתם המומים מרשת של קבצים, הפניות ובגים שמחכים לרוב לכם, אתם לא לבד.

00:01:12.000 --> 00:01:15.320
רוב המפתחים עובדים בצורה תגובתית, מתקנים כאן, מנפים בגים שם.

00:01:15.460 --> 00:01:20.300
מצב הסוכן, Agent Mode של GitHub Copilot, נועד להחזיק הקשר רחב יותר ולתאם שינויים בין קבצים.

00:01:20.300 --> 00:01:25.140
בסרטון הזה נדגים איך זרימת העבודה הזו נראית בתוך פרויקט נקודה נט ו-Azure אמיתי.

00:01:25.300 --> 00:01:28.680
נעבור על פרויקט חי ונראה את המצב לפני ואחרי השינויים של הסוכן.

00:01:28.820 --> 00:01:36.340
תראו איך לייצר קוד מרובי קבצים עם פחות מאמץ, לפתור שגיאות בין קיבציות מהר יותר, ואפילו להשתמש במפרט בשפה פשוטה כדי לבנות תשתית פיצ'רים.

00:01:36.500 --> 00:01:41.420
ולפני שנגיע לשם, בואו נתחיל עם המחיר הנסתר של נולעת ניפוי הבגים שרבים מאיתנו חיים בה בכל יום.

00:01:41.420 --> 00:01:43.740
המחיר הנסתר של ניפוי בגים טלי על טלי.

00:01:43.900 --> 00:01:46.380
אתם מתיישבים לתקן שגיאה שנראית פשוטה למדי.

00:01:46.500 --> 00:01:50.580
האפליקציה לא עוברת הידור, בילד, והקונסול מסמן שורה בקובץ הפרויקט הראשי שלכם.

00:01:50.740 --> 00:01:56.180
אתם משנים את המתודה מרנדרים מחדש, וחושבים שפתרתם את זה עד שהודעה דומה מופיעה שוב בצורה מעט שונה.

00:01:56.340 --> 00:01:59.680
חצי שעה נוספת חולפת לפני שאתם מזהים את הבעיה האמיתית.

00:01:59.840 --> 00:02:02.240
תלות חסרה שמוכבט בתיקיית פרויקט אחרת.

00:02:02.240 --> 00:02:07.480
עד שההפניה מתוקנת ואתם פורסים מחדש, רוב אחר הצהריים שלכם התמוסס לתוך עבודה תלעים.

00:02:07.600 --> 00:02:09.940
עבודת הפיאצ'רים שתכננתם נדחת למחר.

00:02:10.100 --> 00:02:12.280
הדפוס הזה כל כך נפוץ שהוא מרגיש נורמלי.

00:02:12.440 --> 00:02:15.880
על פני השטח אתם מתקדמים כי כל בג שאתם מחסלים מרגיש כמו ניצחון.

00:02:16.060 --> 00:02:17.560
בפועל אתם רצים במעגלים.

00:02:17.760 --> 00:02:21.120
הלולאה היא כתיבת קוד, הידור, שגיאה, תיקון וחוזר חלילה.

00:02:21.120 --> 00:02:23.840
שעות נעלמות ברדיפה אחרי שרשרת של סיבה ותוצאה.

00:02:24.020 --> 00:02:26.740
והתוצאה הסופית היא התקדמות תגובתית במקום שיפורים משמעותיים.

00:02:26.900 --> 00:02:29.740
כמה מכם איבדו אחר צהריים שלם על הלולאה המדויקת הזו.

00:02:29.880 --> 00:02:32.580
כתבו תגובה של שורה אחת, הקרא את התגובות המובילות.

00:02:32.740 --> 00:02:37.580
מה שהופך את המעגל הזה למטיש הוא שהכלים סביבנו ממשיכים להתקדם, בעוד הדפוס נשאר כשהיה.

00:02:37.720 --> 00:02:41.820
פורחי קוד מוסיפים פיצ'רים חדשים, תשתית מתפתחת ואינטגרציות מעמיקות.

00:02:41.820 --> 00:02:44.100
אבל ניפוי שגיאות עדיין דורש גישה תגובתית.

00:02:44.300 --> 00:02:46.760
זה כמו לנסות לעצור אש גדולה עם דלי מים.

00:02:46.940 --> 00:02:52.840
כל התפרצות מטופלת ברגע האמת, אבל התנאים שגרמו לה נשארים, מה שמבטיח כמעט בוודאות את הדליקה הבאה.

00:02:52.940 --> 00:02:55.660
ואם כל מעבר בין תבים, העלות הנסתרת עולה.

00:02:55.800 --> 00:02:59.800
אתה עובר ממחלקת שירות לקובץ הגדרות, ואז קופץ לגרף תלויות.

00:02:59.980 --> 00:03:04.480
כל מעבר מוציא אותך המחות המחשבה שהחזקת ומעלץ אותך לבצע איפוס מנטלי.

00:03:04.480 --> 00:03:09.620
אלו לא רק השניות שמושקעות במעבר בין חלונות, זה המס המנטלי של שחזור ההקשר שוב ושוב.

00:03:09.800 --> 00:03:13.160
במהלך יום עבודה, האיפוסים הקטנים האלה מצטברים למה שהוא כבד.

00:03:13.300 --> 00:03:16.900
עבור מפתחים בודדים, העייפות מתבטאת בתסכול ובזמן מבוסבז.

00:03:17.020 --> 00:03:20.260
עבור צוותים שעובדים על פרויקטים ארגוניים, ההשפעה מוכפלת.

00:03:20.420 --> 00:03:26.700
לופים של ניפוי שגיאות מוציאים את הספרינט מהמסלול, מעקבים השקת פיצ'רים ויוצרים צבר עבודה שגדל מהר יותר משהו מצטמצם.

00:03:26.700 --> 00:03:31.220
העמקת החוב הטכני היא רק תופעת לוואי נוספת של שעות שעבדו בחיבוי שריפות.

00:03:31.320 --> 00:03:35.880
צוותים רבים מדווחים שחלק גדול מזמן הפיתוח שלהם נשאב לניפוי שגיאות תגובתי.

00:03:36.040 --> 00:03:37.560
זה לא החלק המלהיב בהנדסה.

00:03:37.700 --> 00:03:41.620
אף אחד לא מתכנן מפת דרכים סביב רדיפה אחרי אותה היא התאמת תלויות חמש פעמים.

00:03:41.800 --> 00:03:44.840
ובכל זאת, לשם הולך רוחב הפס שבוע אחרי שבוע.

00:03:44.840 --> 00:03:51.580
כשתיקון שגיאות הופך להגדרה של התקדמות, בניית פיצ'רים חדשים הופכת למשנית והארכיטקטורה סובלת בשקט ברקע.

00:03:51.700 --> 00:03:58.380
האמת הלא נוחה היא שניפוי שגיאות תלעים לא רק מעט את הדברים, ומחזק תרבות של תגובה במקום של תכנון.

00:03:58.560 --> 00:04:01.740
אתה מבלה את הזמן בחיבוי להוות, לא בבניית מערכות.

00:04:01.980 --> 00:04:07.740
זה אולי שומר על המוצר חי בטווח הקצר, אבל זה מגביל את היכולת של הצוות להתרחב ואת הביטחון בהפצת גרסאות.

00:04:07.740 --> 00:04:12.940
אז בואו נעצור על הדימוי הזה קיבוי שריפות, לרוץ לנקודת האש, לשפוך מים, להמשיך הלאה.

00:04:13.040 --> 00:04:15.700
הבעיה היא לא שמפתחים לא טובים בזה, הם טובים.

00:04:15.880 --> 00:04:18.300
הבעיה היא שהלהוות לעולם לא באמת מפסיקות.

00:04:18.500 --> 00:04:25.240
הן פשוט זזות, מתפרצות בקבצים חדשים, פרויקטים חדשים, הגדרות חדשות, ומשאירות את כולם במצב תגובה במקום במצב יצירה.

00:04:25.400 --> 00:04:28.880
זה מעלה את השאלה, מה קורה אם המעגל הזה לא תלוי רק בך?

00:04:28.880 --> 00:04:36.500
מה אם החלקים החוזרים על עצמם, הלופ של מעקב, מעבר ותיקון, היו יכולים להתנהל אחרת בזמן שאתה נשאר ממוקד בבנייה?

00:04:36.600 --> 00:04:40.980
כי בעוד שהלחץ של כיבוי שריפות ברור, יש נקודת לחץ נוספת שעוד לא נגענו בה.

00:04:41.120 --> 00:04:44.800
העומס האמיתי מגיע כשהפרויקט שלך הוא לא רק קובץ אחד או מודול אחד.

00:04:45.000 --> 00:04:48.540
זה קורה כשהתיקון שאתה צריך מסתרע על פני מספר שכבות בבת אחת.

00:04:48.540 --> 00:04:54.500
תאר לעצמך שאתה מתיישב לפתוח פתרון שבו הלוגיקה מפוזרת בין פרויקטים, שירותים וספריות שונים.

00:04:54.700 --> 00:05:00.420
החלק שאתה צריך נמצא בשלושה מקומות בו זמנית, והניסיון לעשות סדר בראש הוא מאבק בפני עצמו.

00:05:00.580 --> 00:05:04.120
קאוס של קבצים מרובים מול בקרת הקשר מבוססת בינה מלאכותית.

00:05:04.280 --> 00:05:08.320
כשפרויקטים מסתרעים על פני מספר שכבות, האתגר האמיתי הוא לא כתיבת הקוד.

00:05:08.480 --> 00:05:10.760
האתגר הוא להחזיק את כל החלקים הנעים יחד.

00:05:10.760 --> 00:05:16.060
כאן המתח בין קאוס של קבצים מרובים לבקרת הקשר מבוססת בינה מלאכותית בא לידי ביטוי בצורה הברורה ביותר.

00:05:16.160 --> 00:05:19.120
כך פתרון נט, גדול עם טרייסר פרויקטים או יותר.

00:05:19.320 --> 00:05:22.540
כל פיצ'ר חדש נוגע בדרך כלל בשכבות שונות בבת אחת.

00:05:22.720 --> 00:05:27.540
ביקר במקום אחד, שירות במקום אחר, וקבוצת קבצי הגדרה שחיים במקום אחר.

00:05:27.680 --> 00:05:31.980
לפני שאתה כותב שורה אחת, אתה מבלה זמן במעקב אחר הפניות ובדיקת תלויות,

00:05:31.980 --> 00:05:35.540
בתקווה ששינוי קטן לא יגרום לתקלות בלתי צפויות בהמשך השרשרת.

00:05:35.660 --> 00:05:37.620
סגנון העבודה הזה הוא לא יוצא דופן.

00:05:37.820 --> 00:05:42.560
זה נורמלי באפליקציות ארגוניות, במיוחד ברגע ששירותי Azure ואינטגרציות נכנסים לתמונה.

00:05:42.700 --> 00:05:45.020
המבנה של המערכות האלה אינו שטוח.

00:05:45.220 --> 00:05:50.100
ממשקים, מיפויים של הזרקת תלויות, D, והפניות בין פרויקטים, כולם משחקים תפקיד.

00:05:50.240 --> 00:05:53.980
עם Azure בתמונה, חלק מהתלויות חורגות לחלוטין מתיקיית הפתרון,

00:05:53.980 --> 00:05:58.480
אפליקציות פונקציה, כישורי Service Bus, הגדרות משאבים וחיבורי יחסון.

00:05:58.640 --> 00:06:03.820
אתה מתאם בין קוד בסביבת הפיתוח שלך, קבצי הגדרה בדיסק ושירותים המוגדרים בענן.

00:06:04.040 --> 00:06:06.440
לאף אחד מהם לא אכפת שאתה רוצה פחות קליקים.

00:06:06.580 --> 00:06:10.320
בכל פעם שאתה מחליף הקשר, אתה שורף אנרגיה בשחזור התמונה הגדולה.

00:06:10.440 --> 00:06:13.220
רובנו מנסים ללהטת עם ההקשר הזה בזיכרון העבודה שלנו.

00:06:13.380 --> 00:06:16.760
בהתחלה זה מנוהל, אבל ככל שהפרויקט גדל, טעויות מחליקות פנימה.

00:06:16.760 --> 00:06:19.940
אתה מוסיף מתודה חדשה בשירות, אבל שוכח את הרישום שלה בדי.

00:06:20.040 --> 00:06:23.820
אתה כותב פונקציית Azure ורק מאוחר יותר מבין שהקישור מעולם לא נוסף לאוסט,

00:06:23.940 --> 00:06:25.080
JSON או לתבנית הפריסה.

00:06:25.200 --> 00:06:28.760
שום דבר לא מטריע בפניך עד זמן הריצה, כשאתה כבר עושה דיבגינג במקום לבנות.

00:06:28.880 --> 00:06:30.380
הקוד עצמו הוא לא החלק הקשה.

00:06:30.540 --> 00:06:32.500
החלק הקשה הוא התאום בין הקבצים.

00:06:32.500 --> 00:06:38.860
כולם מכירים את התחושה של קפיצה בין תבים, מבקר לשירות, למודל, לגבצי הגדרה ובחזרה,

00:06:38.860 --> 00:06:41.680
רק כדי לשכוח למה בכלל פיתחת את הקובץ.

00:06:41.860 --> 00:06:44.780
זו הפרעה קטנה שחוזרת על עצמה עשרות פעמים ביום.

00:06:44.980 --> 00:06:48.640
האינטרקציות האלה מצטברות ויוצרות חיכוך שמעכב התקדמות אמיתית.

00:06:48.800 --> 00:06:51.580
התוצאה היא אספקה איטית יותר, לא בגלל שהכתיבה איטית,

00:06:51.760 --> 00:06:54.240
אלא בגלל שהשמירה על הכל מסונקרן גוזלת את הריכוז.

00:06:54.240 --> 00:06:57.160
התקורה הזו גדלה בפרויקטים שמתמקדים בענן.

00:06:57.280 --> 00:07:00.180
Azure דוחפת הגדרות מפתח למקומות מרובים,

00:07:00.400 --> 00:07:02.980
קבצי הגדרות מקומיים, משתני סביבה,

00:07:02.980 --> 00:07:06.180
תבניות ARM או בייספ וצינורות C, CD.

00:07:06.400 --> 00:07:08.100
מה שנראה כמו בקשת תכונה אחת,

00:07:08.300 --> 00:07:10.880
מתפרס לעיתים קרובות על פני ארבע שכבות של הפשטה.

00:07:11.020 --> 00:07:12.760
המורכבות הזו אינה אופציונלית.

00:07:12.900 --> 00:07:15.120
היא תבועה בדרך שבה המערכת האקולוגית פועלת.

00:07:15.260 --> 00:07:18.440
כעת, כאן נכנס מצב סוכן, Agent Mode, כמהפך פוטנציאלי.

00:07:18.440 --> 00:07:20.220
במקום להשאיר את כל הארגון הזה לך,

00:07:20.420 --> 00:07:23.060
הוא מתוכנן להחזיק הקשר רחב יותר על פני קבצים מרובים.

00:07:23.240 --> 00:07:25.780
זה אומר שכאשר אתה מבקש שינוי בשכבה אחת,

00:07:25.780 --> 00:07:27.060
הוא לא מתעלם מהאחרות.

00:07:27.260 --> 00:07:29.520
בהדגמה, עצור פונקציית אז'ול חדשה

00:07:29.520 --> 00:07:32.420
והראה כיצד הסוכן עוזר על ידי יצירת גוף המתודה,

00:07:32.700 --> 00:07:34.860
הפקת הגדרות הביינדינג ועדכון האוס,

00:07:35.160 --> 00:07:37.720
ג'ייסן, ואפילו מציע את רישום הדי הנכון.

00:07:37.940 --> 00:07:41.260
זהו בדרך כלל תהליך רב שלוי המפוזר על פני קבצים שונים.

00:07:41.260 --> 00:07:43.760
סוכן יכול לייעל זאת לזרימת עבודה אחת.

00:07:43.920 --> 00:07:46.160
זה לא עניין של החלפת שיקול הדעת שלך,

00:07:46.360 --> 00:07:48.040
אלא הסרת עבודת הניהול החזרתית,

00:07:48.040 --> 00:07:50.360
כדי שתוכל להתמקד בבחירות עצביות אמיתיות.

00:07:50.560 --> 00:07:54.120
בני אדם יכולים לשמור מתווה גס בראשם או סרטוט על לוח מחי.

00:07:54.220 --> 00:07:56.940
בינה מלאכותית יכולה לעקוב אחר הפרטים קובץ אחר קובץ

00:07:56.940 --> 00:07:58.240
מבלי לאבד את החוט המקשר.

00:07:58.420 --> 00:08:00.500
מה שמרגיש כעומס קוגניטיבי עצום עבורנו

00:08:00.500 --> 00:08:02.160
הוא רק הקשר בסיסי עבור הסוכן.

00:08:02.160 --> 00:08:05.000
ההבדל בפועל הוא מעבר מלהטות בין כרטיסיות שבורות

00:08:05.000 --> 00:08:06.980
לשינויים מתוזמרים שנשארים מסונקרנים.

00:08:07.140 --> 00:08:08.300
אציג גם את בקשת המזוג,

00:08:08.300 --> 00:08:10.960
או את הדיף שיצר הסוכן במהלך ההדגמה

00:08:10.960 --> 00:08:12.880
כדי שתוכל לראות בדיוק אילו עריכות בוצעו.

00:08:12.980 --> 00:08:14.080
הנהירות הזו חשובה.

00:08:14.240 --> 00:08:16.100
יש לך השליטה מלאה לזכור ולאשר

00:08:16.100 --> 00:08:19.000
בזמן שעבודת העדכון של קבצים מרובים מתבצעת עבורך.

00:08:19.140 --> 00:08:21.460
אז במקום להעביר אחר הצהריים בחיבור קטעים,

00:08:21.460 --> 00:08:23.240
אתה מכוון את השינוי פעם אחת

00:08:23.240 --> 00:08:26.300
מאשר את העדכונים שנוצרו ועובר לעיצוב ברמה גבוהה יותר.

00:08:26.480 --> 00:08:29.300
ההקלה היא לא רק בחיסכון בקליקים או הקשות,

00:08:29.620 --> 00:08:31.560
אלא במיקוד בפתרון בעיות אמיתיות

00:08:31.560 --> 00:08:34.040
במקום בשחזור הקשר בין טרייסר קבצים.

00:08:34.260 --> 00:08:36.540
יתרון זה ניכר ביותר כשדברים משתבשים,

00:08:36.780 --> 00:08:38.480
כי גם אם ניהול הקשר חזק יותר,

00:08:38.680 --> 00:08:39.580
מערכות קורסות,

00:08:39.800 --> 00:08:42.400
הגדרות זולגות והפניות לא תואמות חוזרות להופיע.

00:08:42.580 --> 00:08:44.060
וכאן מתחיל המבחן הבא

00:08:44.060 --> 00:08:47.060
כיצד מעטרים ופותרים שגיאות ברגע שהן צפות.

00:08:47.380 --> 00:08:49.360
מצייד שגיאות לתיקונים אוטונומיים.

00:08:49.540 --> 00:08:51.760
חשוב כמה פעמים נתקלת בהודעת שגיאה

00:08:51.760 --> 00:08:53.480
שמצביעה ישירות על קובץ בודד.

00:08:53.580 --> 00:08:55.040
אתה עוקב אחר ה-Stack Trace,

00:08:55.140 --> 00:08:55.860
למתודה שצוינה,

00:08:55.860 --> 00:08:58.120
מבצע התאמה קטנה ומריץ בנייה מחדש,

00:08:58.260 --> 00:08:58.600
Rebuild.

00:08:58.780 --> 00:09:00.400
זה מרגיש כמו הפתרון הברור,

00:09:00.600 --> 00:09:03.020
עד שאותה שגיאה מופיעה שוב בצורה מעט שונה.

00:09:03.220 --> 00:09:05.320
זה הרגע שבו אתה מבין שה-Stack Trace

00:09:05.320 --> 00:09:06.400
הראה רק את הסימפטום.

00:09:06.540 --> 00:09:08.400
הבעיה האמיתית נמצאת במקום אחר לגמרי,

00:09:08.620 --> 00:09:10.840
אולי במחלקה תומכת או מוסתרת בתוך קובץ הגדרות

00:09:10.840 --> 00:09:11.800
שלא פתחת כל השבוע.

00:09:11.940 --> 00:09:14.120
כל מפתח התמודד עם סוג כזה של התאיה.

00:09:14.120 --> 00:09:17.000
מה שנראה כמו הבעיה הוא לא בהכרח המקום שבו נמצא הפתרון.

00:09:17.000 --> 00:09:18.360
זה גוזל זמן במהירות.

00:09:18.520 --> 00:09:20.780
אתה משנה דבר אחד, בונה מחדש ומחכה.

00:09:20.860 --> 00:09:23.520
אז מקבלת את פניך שגיאה חדשה שמובילה לקובץ אחר,

00:09:23.680 --> 00:09:25.100
לעוד כבנון ועוד בנייה מחדש.

00:09:25.240 --> 00:09:28.380
הלולאה נראית פרודוקטיבית כי אתה זז, מקליד ומהדר,

00:09:28.660 --> 00:09:32.160
אבל מתחת לפני השטח זה יותר ניסוי ותאייה מאשר פתרון אמיתי.

00:09:32.320 --> 00:09:35.960
המעגל הזה יכול לבלוע שעות ולהשאיר עוד חים תיקונים שטחיים קטנים

00:09:35.960 --> 00:09:38.520
ללא התקדמות ממשית בפיצ'ר שהתחלת לעבוד עליו.

00:09:38.520 --> 00:09:40.760
המחיר האמיתי כאן הוא אובדן הזדמנויות.

00:09:41.000 --> 00:09:43.800
כשאתה לחוד בקצב של בנייה מחדש וניסיונות חוזרים,

00:09:44.020 --> 00:09:47.900
אתה לא פותר בעיות עסקיות או מפיץ את הפונקציונליות שהמשתמשים שלך מחכים לה.

00:09:48.020 --> 00:09:50.320
המומנטום הולך לניחושים במקום לתכנון.

00:09:50.520 --> 00:09:56.000
זה מרגיש פעיל ברגע, אבל השעות האלה לא מצטברות ליותר מאשר שמירה על המערכת שלא תקרוס.

00:09:56.160 --> 00:10:02.000
ברמת הצוות, התנועה השטחית הזו מעתה הכל ויוצרת פיגור בפי אצ'רים שנדחקים כל הזמן קדימה.

00:10:02.000 --> 00:10:04.940
כאן זרימת העבודה של סוכן מתחילה להיראות אחרת.

00:10:05.120 --> 00:10:08.300
הרעיון הוא לא לעצור בשורה האחת שדוח השגיאות מדגיש.

00:10:08.480 --> 00:10:13.720
במקום זאת, הוא מתוכנן להחזיק הקשר ברמת המערכת ושואל לא רק מה הקובץ הזה צריך לעשות,

00:10:14.000 --> 00:10:17.960
אלא איזו סדרה של שינויים נדרשת בחלקים המחוברים כדי להחזיר את העקביות.

00:10:18.180 --> 00:10:22.480
בפועל, זה אומר שאתה עשוי לראות אותו מציע עריכות שמתפרסות על פני מספר קבצים.

00:10:22.660 --> 00:10:25.620
למשל, תראה בדמו שכאשר שיטה דורשת שינויים,

00:10:25.620 --> 00:10:30.780
הוא יכול להציע עריכות תואמות בקבצי הגדרה או בתבניות פריסה במקום להשאיר אותך לחפש אותם.

00:10:30.940 --> 00:10:33.620
זו הקפיצה מהשלמה אוטומטית למה שהוא רחב יותר.

00:10:33.860 --> 00:10:36.740
השלמה אוטומטית מסיימת שורות, סוכן מתאם בין קבצים,

00:10:36.940 --> 00:10:40.800
והתאום הזה חשוב במיוחד כשהשגיאות לא נמצאות בצורה מסודרת במקום אחד.

00:10:40.940 --> 00:10:42.460
כך תרחיש נפוץ באז'ר.

00:10:42.660 --> 00:10:45.440
בנית האפליקציית פונקציה חדשה, אבל לאחר הפריסה,

00:10:45.640 --> 00:10:48.280
טריגר התור נכשל כי הקישור לא תואם לחתימת השיטה.

00:10:48.280 --> 00:10:53.900
בדרך כלל, אתה חופר ביומנים, מבין איזה קישור שגוי משנה את הג'סון של הפונקציה הידנית,

00:10:54.140 --> 00:10:57.480
ואולי אפילו משנה את תבנית התשתית שלך אם ערך לא תואם גם שם.

00:10:57.700 --> 00:11:01.580
כל שלב הוא מרדף נפרד, וכל תיקון מפעיל הרצת בדיקה נוספת.

00:11:01.740 --> 00:11:03.900
אם מצב סוכן, זרימת העבודה שונה.

00:11:04.060 --> 00:11:07.560
הוא יכול להציע את שינוי הקוד, לייצר את קישור הג'סון המתאים לפונקציה,

00:11:07.780 --> 00:11:10.520
ולהציף עריכות לסקריפטים של פריסה אם הם לא מסונקרנים.

00:11:10.520 --> 00:11:14.480
אתה סוקר, מאשר הוא מתקדם בלי לבזבז שעות על חיבור השקבות זו לזו,

00:11:14.600 --> 00:11:15.880
ואמון הוא המפתח כאן.

00:11:16.000 --> 00:11:18.760
אף אחד לא צריך להרגיש שהעריכות בלתי נראות קורות ברקע,

00:11:18.860 --> 00:11:20.640
לכן תהליך הסקירה חשוב כל כך.

00:11:20.820 --> 00:11:22.560
בדמו הזה, נעבור על זה יחד.

00:11:22.720 --> 00:11:24.680
הסוכן מציע את השינויים המתואמים.

00:11:24.860 --> 00:11:27.400
נפתח את הדיף כדי לבדוק בדיוק מה נוצר,

00:11:27.620 --> 00:11:29.120
נריץ את בדיקות היחידה שלנו,

00:11:29.380 --> 00:11:30.600
נעמת את הביילד מקומית,

00:11:30.800 --> 00:11:33.100
ורק אז נחליט אם לקבל או לדחות את השינויים.

00:11:33.100 --> 00:11:37.080
לולעת אימות זו משאירה אותך בשליטה מלאה תוך חסרת העבודה השחורה.

00:11:37.220 --> 00:11:39.780
חשוב להדגיש, סוכנים יכולים לעזור לנו המהר יותר,

00:11:40.040 --> 00:11:41.980
אך הם אינם מחליפים פרקטיקות הנדסיות טובות.

00:11:42.160 --> 00:11:43.980
עליך עדיין להתייחס לסקירת קוד ולאה,

00:11:44.060 --> 00:11:45.820
כשומרי סף שאינם נתונים למסע ומתן.

00:11:45.980 --> 00:11:48.440
תן לאהי לצמצם את הזמן שאתה מבלה בבלשות,

00:11:48.680 --> 00:11:51.400
אך שמור על בדיקות אוטומטיות וסקירה אנושית קרשת ביטחון.

00:11:51.540 --> 00:11:53.320
איזון זה פותר את בעיית האמון,

00:11:53.320 --> 00:11:56.000
ומבטיח ששיפור המהירות לא יערער את היציבות.

00:11:56.100 --> 00:11:57.680
הבדל המהירות אינו תיאורטי.

00:11:57.800 --> 00:12:01.560
במקום שבו מרדף אחרי שגיאות ותיקונים ידניים עלולים לגזול חצי יום,

00:12:01.760 --> 00:12:03.640
הצעות מתואמות יכולות לצמצם זאת לדקות.

00:12:03.760 --> 00:12:07.220
והזמן שהתפנה חוזר לעבודה שבאמת תרצה להשקיע באנרגיה.

00:12:07.340 --> 00:12:09.360
הפיאצ'רים שהמשתמשים שלך מבחינים בהם,

00:12:09.400 --> 00:12:11.700
והחלטות הארכיטקטורה שמשפרות את בסיס הקוד שלך.

00:12:11.840 --> 00:12:13.500
במקום לחבות שריפות בזמן ריצה,

00:12:13.500 --> 00:12:15.200
אתה יכול לתכנן בביטחון מראש.

00:12:15.320 --> 00:12:18.500
כך לולעת הניפוי, דיבאגינג, כבר לא חייבת להגדיר את היום שלך.

00:12:18.620 --> 00:12:20.980
אם סוכן שמציע עדכונים רוחביים בין קבצים,

00:12:21.220 --> 00:12:23.840
אתה עובר מחיפוש אקראי לקצב של סקירה ואישור.

00:12:24.000 --> 00:12:26.200
אתה מפסיק להסתובב במעגלים בין שגיאות,

00:12:26.260 --> 00:12:30.160
ומתחיל להתייחס לניפוי כשלב מובנה וכמעט אוטומטי בזרימת העבודה שלך.

00:12:30.340 --> 00:12:33.460
שינוי זה מפנה מקום קוגניטיבי ושעות ביומן לבניית פיץ'רים,

00:12:33.460 --> 00:12:34.720
ולא רק לתיקון פגמים.

00:12:34.880 --> 00:12:37.920
וברגע שתיקון שגיאות הופך לפחות מרדף אחרי סימפטומים,

00:12:38.160 --> 00:12:39.720
זה פותח דלת למה שהוא גדול יותר.

00:12:39.900 --> 00:12:42.780
איך תוכל להתחיל פיץ'רים שלמים באותה דרך מובנית?

00:12:42.920 --> 00:12:46.560
תאר לעצמך שאותה זרימת עבודה שמציעה תיקונים מתואמים

00:12:46.560 --> 00:12:50.380
יכולה גם לקחת מפרט בשפה פשוטה ולעצב סביבו מבנה עובד.

00:12:50.580 --> 00:12:53.280
זה המקום שבו מתחיל השלב הבא של הפיתוח.

00:12:53.280 --> 00:12:55.800
פיתוח מונחה מפרט ללא התקורה הנלווית.

00:12:55.800 --> 00:13:00.840
אחד השינויים המעניינים ביותר קורה כשאתה מפסיק לחשוב רק במונחים של קבצים ומתודות,

00:13:01.060 --> 00:13:02.800
ומתחיל למסגר עבודה בשפה פשוטה.

00:13:02.920 --> 00:13:06.040
כאן נכנס לתמונה פיתוח מונחה מפרט ללא התקורה הנלווית.

00:13:06.200 --> 00:13:08.500
תאר לעצמך כתיבת בקשת פיצ'ר פשוטה.

00:13:08.640 --> 00:13:11.520
הוסף זרימת עבודה של דוחות שמייצרת סיכומים חודשיים,

00:13:11.800 --> 00:13:14.280
שומרת אותם והופכת אותם לזמינים דרך דף ניהול.

00:13:14.280 --> 00:13:16.620
במקום רק לקבל כמה קטעי קוד מבודדים,

00:13:16.620 --> 00:13:20.040
אתה מקבל מבנה עובד שכבר ממופה ברחבי האפליקציה שלך.

00:13:20.160 --> 00:13:24.500
קונטרולרים מוגדרים, מודלים נוצרו, שירותים נרשמו והגדרות חוברו.

00:13:24.620 --> 00:13:28.680
המעבר הזה מתיאור כוונה לראיית שלד קונקרטי מופיע בפרויקט שלך

00:13:28.680 --> 00:13:32.100
הוא המקום שבו גישה זו סוף סוף מרגישה מעשית ולא תיאורטית.

00:13:32.220 --> 00:13:35.760
בהגדרות מסורתיות, לפיתוח מונחה מפרט יש מוניטים כבד.

00:13:35.760 --> 00:13:39.020
בארגונים גדולים זה בדרך כלל אומר מסמכי דרישות ארוכים,

00:13:39.020 --> 00:13:42.060
דפי עיצוב מרובי עמודים ותרשימים נוקשים שמעטים את כולם.

00:13:42.240 --> 00:13:45.100
הם הגיוניים בתעשיות מוסדרות או בצוותים מבוזרים גלובלית,

00:13:45.340 --> 00:13:47.640
אך עבור כידוד יומיומי, רוב המפתחים מדלגים עליהם.

00:13:47.760 --> 00:13:52.160
כתיבה ותחזוקה של מפרטים מפורטים מוסיפה עלות שאף אחד לא רוצה להשקיע בזמן או סבלנות.

00:13:52.300 --> 00:13:54.440
זו עבודה נוספת שנערמת על פיתוח פיצ'רים,

00:13:54.440 --> 00:13:58.060
וככל שהדדלנים מתקרבים, המאמצים האלו בדרך כלל מוקרבים.

00:13:58.060 --> 00:14:01.320
האירוניה ברורה, מפתחים דווקא אוהבים לחשוב בקווים כלליים.

00:14:01.520 --> 00:14:04.000
לדעת את המבנה מראש זה דבר שמעניק ביטחון.

00:14:04.160 --> 00:14:06.540
הבעיה היא לא הכוונה, אלא התחזוקה השוטפת.

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

00:14:10.740 --> 00:14:15.000
זו הסיבה שחלק גדול מהעבודה בפועל נוטה לעלתור במקום לתכנון מלא,

00:14:15.340 --> 00:14:17.600
גם במקומות שתומכים רשמית בתכנון מעמי.

00:14:17.700 --> 00:14:20.340
זרימת עבודה מבוססת סוכן מציעה חלופה.

00:14:20.340 --> 00:14:26.060
במקום לדרוש מסמך עיצוב מלוטש, היא יכולה לתרגם מפרט בשפה פשוטה לשלד שניתן לשכלל.

00:14:26.240 --> 00:14:29.140
לא צריך דיאגרמות UML או מיפוי ממשקים ידני,

00:14:29.140 --> 00:14:34.780
אפשר פשוט לבקש ליצור מודול דוחות עם נקודת קצה חדשה של API לקשר להיחסון,

00:14:35.020 --> 00:14:40.680
ולהבטח עם גישה מבוססת תפקידים, והמערכת מייצרת בסיס בכל הקבצים בפתרון הנט שלך.

00:14:40.920 --> 00:14:45.620
בהדגמה, אקרי מפרט בשפה פשוטה, ואז הראה את הקבצים שהסוכן הפיק,

00:14:45.820 --> 00:14:48.000
בקרים, מודלים ורישום שירותים,

00:14:48.000 --> 00:14:50.900
ואצביע על המקומות שעדיין דרשו ליטוש ידני.

00:14:51.180 --> 00:14:53.440
כך תוכלו לשפוט את האיכות בעצמכם.

00:14:53.640 --> 00:14:56.200
זה יוצר דרך אמצע בין שני מצבי פיתוח.

00:14:56.200 --> 00:14:59.800
בצד אחד יש קוד מבוסס תחושה, וייב קודינג, מהיר וחופשי,

00:15:00.000 --> 00:15:01.500
אך שברירי למערכות ארוכות טווח.

00:15:01.680 --> 00:15:05.520
בצד השני יש תכנון מונחה מפרט אמין, אך איתי באופן מייגע.

00:15:05.780 --> 00:15:08.400
בעזרת סוכן, אתם מתארים את הרעיון במילים טבעיות,

00:15:08.400 --> 00:15:14.500
השלד מופיע, ואתם יכולים לבצע איתרציות מהירות כמעט כמו בקוד מבוסס תחושה תוך שמירה על היתרון של מבנה מאורגן.

00:15:14.620 --> 00:15:16.120
ניקח שוב את תהליך הדוחות.

00:15:16.340 --> 00:15:20.020
בדרך כלל, הייתם צריכים ליצור את המודל, לבנות את שירות הנתונים,

00:15:20.340 --> 00:15:23.520
לחבר את הבקר, להגדיר הבטחה ולחבר הכל בסטארצ'ו.

00:15:23.620 --> 00:15:26.940
זה אומר לקפוץ בין קבצים מרובים ולקוות שהעקביות נשמרת.

00:15:27.160 --> 00:15:29.800
בגישה הזו, השלד נוחת במקומו בבת אחת.

00:15:29.800 --> 00:15:34.220
החיסכון האמיתי מגיע פחות מהקלדת פחות שורות ויותר ממניעת טעויות בין קבצים,

00:15:34.460 --> 00:15:37.000
כמו לשכוח לרשום שירות חדש אחרי שכבר בנית אותו.

00:15:37.140 --> 00:15:39.200
כמובן, תמיד עולה שאלת הסגנון.

00:15:39.360 --> 00:15:42.120
האם ה-AI יכפה תבניות קוד או ידרוס מוסכמות?

00:15:42.320 --> 00:15:46.360
בפועל, סוכנים לרוב משקפים את דפוסי הפרויקט הקיימים בהצעות שלהם.

00:15:46.520 --> 00:15:48.360
בהדגמה תראו את שני הצדדים.

00:15:48.560 --> 00:15:51.760
מקומות שבהם הוא התאים בדיוק למבנה הבקרים של האנשים שלנו,

00:15:51.760 --> 00:15:54.260
ומקומות שבהם הניחושים שלא יצאו מהקשרם.

00:15:54.420 --> 00:15:55.520
השילוב הזה חשוב.

00:15:55.700 --> 00:15:58.280
תדעו למה אפשר לסמוך ומה עדיין צריך להתאים.

00:15:58.460 --> 00:16:00.280
התוצאה הסופית היא לא קוד גנרי.

00:16:00.500 --> 00:16:02.340
זה עדיין מרגיש כמו הפרויקט שלכם,

00:16:02.520 --> 00:16:04.000
רק עם פחות עבודת שלד ידני.

00:16:04.220 --> 00:16:08.820
אתם שומרים על המהירות ועדיין מסתמכים על בסיס שתוכלו לשכלל לצמיחה עתידית.

00:16:09.020 --> 00:16:12.980
במקום שעבודת מפרט תהיה מוגבלת לארכיטקטים עם סבלנות לתרשימים,

00:16:12.980 --> 00:16:17.340
היא הופכת לכלי עבור כל מפתח שרוצה להתנסות במהירות מבלי להקריב סדר.

00:16:17.840 --> 00:16:20.100
וכשזה הופך לחלק מהעבודה היומיומית,

00:16:20.300 --> 00:16:24.820
המפרט מפסיק להרגיש כמו צעד רשמי וכבד והופך לסוג של קיצור דרך כליל.

00:16:25.000 --> 00:16:27.740
אתם מתארים את הכוונה, המערכת מניחה את התשתית,

00:16:27.960 --> 00:16:29.540
ואתם מתמקדים בעיצוב הפרטים.

00:16:29.720 --> 00:16:32.700
ההשפעה הגדולה יותר לא נובעת רק מהקוד שאתם מייצרים,

00:16:33.000 --> 00:16:35.220
אלא ממה שחיסכון בזמן אומר שבוע אחר שבוע.

00:16:35.220 --> 00:16:38.220
יותר שעות לפיצ'רים, פחות עבודה שחורה בהגדרות.

00:16:42.980 --> 00:16:45.320
באמת נותנים במונחים של פרודוקטיביות.

00:16:45.640 --> 00:16:47.040
התמורה לפרודוקטיביות.

00:16:47.260 --> 00:16:50.440
השאלה האמיתית היא לא אם חוסכים כמה דקות פה ושם,

00:16:50.720 --> 00:16:54.460
אלא איך אותם שינויים קטנים מצטברים לשעות משמעותיות במהלך שבוע.

00:16:54.880 --> 00:16:56.460
זוהי התמורה לפרודוקטיביות.

00:16:56.640 --> 00:16:59.960
השגת זמן שבדך כלל חומק מבלי מסים דרך החלפת הקשרים,

00:17:00.240 --> 00:17:02.220
סבבי הידור חוזרים ותיקונים ידניים.

00:17:02.380 --> 00:17:05.520
רוב המפתחים מקבלים את העובדן הקטן הזה כחלק מהעבודה.

00:17:05.520 --> 00:17:07.420
עשר דקות כאן במרדף אחרי ערך הגדרה,

00:17:07.420 --> 00:17:12.020
עוד 15 דקות בהרצה מחדש אחרי הפנייה שנשכחה או קפיצה בין קבצים כדי לבדוק חיבורים.

00:17:12.140 --> 00:17:14.000
בפני עצמם הם מרגישים זניחים,

00:17:14.200 --> 00:17:18.300
אבל כשמחברים אותם לאורך ספרינט מלא הם מעצבים את כמות הערך האמיתי שנמסר.

00:17:18.440 --> 00:17:22.160
מה שנראה כמו תנועה שגרתית מסתיר עיכוב אמיתי בלוחות הזמנים של המסירה.

00:17:22.280 --> 00:17:25.160
המשקל הנסתר לא נמצא בזמני הידור או במהירות ההקלדה.

00:17:25.280 --> 00:17:27.880
הוא נמצא בקצב העצור סע שנכפה על הריכוז שלכם.

00:17:27.880 --> 00:17:31.280
בכל פעם שאתם עוברים מקובץ אחד לאחר, המוח שלכם עובר איפוס.

00:17:31.420 --> 00:17:32.620
לאיפוס הזה יש מחיר.

00:17:32.800 --> 00:17:35.820
העברת תיקונים חזרתיים לסוכן מקילה על הנטל הזה.

00:17:36.000 --> 00:17:37.660
במקום לשחזר הקשר כל הזמן,

00:17:37.920 --> 00:17:41.780
אתם משקיעים את המיקוד היכן שזה חשוב בפתרון בעיות תכנון גדולות יותר.

00:17:41.980 --> 00:17:46.720
צוותים רבים לא עוקבים אחרי העלויות המיקרו האלו כי הן לא מופיעות בחרטיסי ג'ירה או בהיסטוריית ג'י.

00:17:46.820 --> 00:17:48.780
עבודה שלא מובילה לשום מקום לא מתועדת,

00:17:48.920 --> 00:17:50.220
אבל היא עדיין צורכת אנרגיה.

00:17:50.220 --> 00:17:53.760
וככל שבסיסי הקוד בדלים, החיכוך הזה לא רק גדל באופן לינארי.

00:17:53.840 --> 00:17:56.260
יותר שכבות אומרות יותר תלויות להחזיק בזיכרון,

00:17:56.320 --> 00:17:59.820
ויותר הזדמנויות לאבד זמן רק באישור המבנה לפני שניתן להתקדם.

00:17:59.960 --> 00:18:03.600
עבודה עם סוכנים משנה את המתמטיקה על ידי טיפול ישיר בבזבוזים האלה.

00:18:03.700 --> 00:18:05.400
הם לא רק ממלאים מתודות מהר יותר.

00:18:05.600 --> 00:18:09.800
הם מצמצמים את מעגלי החיפוש, התיקון וההרצה מחדש שאוכלים את שעות אחר הצהריים.

00:18:09.800 --> 00:18:14.100
צוותים שמשתמשים בסוכנים מדווחים על זמן קצר יותר לשחרור חסימות במקרים רבים.

00:18:14.240 --> 00:18:18.540
בסרטון הזה נדגים משימה אחת של לפני ואחרי, כדי שתוכלו לשפוט את ההשפעה.

00:18:18.660 --> 00:18:21.640
אני אתעד את הזמן שלוקח ליישם את אותו פיצ'ר באז'ר ידנית,

00:18:21.740 --> 00:18:25.700
ולאחר מכן עם הסוכן, כדי שתוכלו לראות את העלייה בפרודוקטיביות במונחים מוחשיים.

00:18:25.880 --> 00:18:29.080
מנקודת מבט עסקית, הערך בא לידי ביטוי במהירות הפרויקט.

00:18:29.180 --> 00:18:32.040
מחזורים מהירים יותר אינם קשורים רק לסביעות רצון המפתחים.

00:18:39.800 --> 00:18:44.740
זרימת עבודה חלקה מאפשרת לצוותים להתקדם נקי, במקום לחזור לעבודה שבורה מהספינט הקודם.

00:18:44.880 --> 00:18:48.940
העקביות הזו מתבטאת בפחות, קיבוי שריפות ובמסירה חזקה יותר לאורך זמן.

00:18:49.120 --> 00:18:50.500
ישנו גם הגורם האנושי.

00:18:50.660 --> 00:18:53.480
יום שעובד על מרדף אחרי שגיאות מותיר כל מהנדס מוטש.

00:18:53.640 --> 00:18:57.920
ברגע שאתה עייף, תכנון נקי הופך לקשה יותר, פרטים מתפספסים וטעויות מחלכלות פנימה.

00:18:57.920 --> 00:19:02.360
על ידי העברת תיקונים מכניים לסוכן, מפתחים נשארים מרוכזים לפרקי זמן ארוכים יותר.

00:19:02.540 --> 00:19:06.120
המיקוד הנוסף הזה מחדד גם את הפרודוקטיביות וגם את האיכות.

00:19:06.180 --> 00:19:11.100
כשאתה לא שחוק מחיקוך חוזר ונשנה, אתה חופשי לחשוב רחב ולתכנן בצורה יעילה יותר.

00:19:11.320 --> 00:19:12.920
ההבדל בפועל נראה כך.

00:19:13.100 --> 00:19:18.680
פונקציית Azure חדשה עם קישורים ואינטגרציות שירות מרובות עלולה להימשך יומיים שלמים ללא עזרה.

00:19:18.680 --> 00:19:23.940
בין הגדרות, בדיקות וחזרה לאחור בגלל הפניות לא תואמות, המשימה נמרחת.

00:19:24.020 --> 00:19:27.400
עם סוכן שעוזר, אותה פונקציה יכולה להיווצר בחצי יום.

00:19:27.620 --> 00:19:32.360
לא כמעגלים פינות, אלא כהגדרות בין קבצים ותזמור מתבצעים נכון מהפעם הראשונה.

00:19:32.520 --> 00:19:35.960
ציר הזמן מתקצר על ידי ביטול התחלות שווא ומאמץ מיותר.

00:19:36.120 --> 00:19:38.120
חלק מהמפתחים מעלים דאגה מוצדקת.

00:19:38.300 --> 00:19:41.480
האם הסתמכות על בינה מלאכותית לטיפול בתחזוקה פוגעת בקישורים שלך?

00:19:41.480 --> 00:19:44.280
נקודת המבט הזו לרוב מפספסת את מה שבאמת משתנה.

00:19:44.380 --> 00:19:47.120
פריקה של הגדרות חזרתיות לא מחלישה את המומחיות שלך,

00:19:47.320 --> 00:19:50.160
היא משמרת אותה לעיצוב והארכיטקטורה שבהם לשיקול דעת יש ערך.

00:19:50.340 --> 00:19:53.480
במציאות, אתה מקבל מקום לתרגל פתרון בעיות ברמה גבוהה,

00:19:53.540 --> 00:19:55.380
במקום לבזבז אנרגיה על תיקוני דרך.

00:19:55.560 --> 00:19:58.900
אם תנסו זאת, הגיבו בחמה שעות הצלחתם לחסוך בספרינג.

00:19:58.900 --> 00:20:01.160
השלב תגובות מעניינות בסרטונים הבאים.

00:20:01.320 --> 00:20:04.800
לשמוע איך צוותים אחרים חווים את השינוי נותן לכולם תמונה טובה יותר

00:20:11.480 --> 00:20:14.660
שלכם והשתמשו בקוד ריביו כדי לתקף שינויים שנוצרו על ידי סוכן.

00:20:14.840 --> 00:20:16.940
שמחו על כך שעבודת התחזוקה מצטמצמת,

00:20:17.080 --> 00:20:18.500
אך שימרו על אותן הגנות במקומן.

00:20:18.640 --> 00:20:21.360
ההבדל במהירות משתלם רק אם האיכות נשמרת יציבה.

00:20:21.520 --> 00:20:26.180
בדיקות חזקות וסקירת פי-אר חכמה מגנות על צינור השחרור שלכם מפני אוטומציה שבירה.

00:20:26.180 --> 00:20:28.480
הרווח הוא פחות בייצור שורות קוד מהר,

00:20:28.700 --> 00:20:31.540
ויותר בפינוי מרחב ליצירת פתרונות חזקים יותר,

00:20:31.540 --> 00:20:33.140
עם פחות עייפות ופחות.