WEBVTT

00:00:00.370 --> 00:00:07.110
क्या आप Microsoft 365 Co-Pilot AI Azure और काम के भविशे को आकार देने वाले लोगों के दस दिनों के लिए तैयार हैं?

00:00:07.890 --> 00:00:11.870
इस जन्वरी M365 कौन वापस आ गया है और हम इसे और बड़ा बना रहे हैं?

00:00:11.870 --> 00:00:18.130
दुनिया भर के MVP और उद्धियो विशे शर्ग्यों से लाइव सत्रों वास्तिविक दुनिया के डेमो और व्याभारिक ज्यान के लिए हमसे जुड़े हैं?

00:00:18.830 --> 00:00:21.250
कोई समान स्राइड ने, कोई अंतहीन शब्द जाल ने हैं?

00:00:21.250 --> 00:00:23.510
हम वास्तिक चुनाथियों से निपट रहे हैं

00:00:23.510 --> 00:00:28.770
को पाइलर्ट स्टुडियो, AI, एजेंट, फैब्रिक, सुरक्षा, गवर्नेंस और आटोमेशन

00:00:28.770 --> 00:00:35.150
चाहे आप IT पेशेवर हों, डेवलपपर हों या बिजनेस लीडर, आपके लिए डिजाइन किये गए सत्र उपलब्ध हैं

00:00:35.150 --> 00:00:40.030
दस पूरे दिनों के साथ, आप कई तकनीगों का पता लगा सकते हैं

00:00:40.030 --> 00:00:44.370
लाइव देखें और व्यावरिक जनकारी अपने सिमिठन में वापस ले जाएं

00:00:44.370 --> 00:00:48.850
जनवरी दोहजार साइस, दस दिन, एक Microsoft समुदाय ही है

00:00:48.850 --> 00:00:50.570
पंजी करण अब खुला है

00:00:50.570 --> 00:00:55.410
m365.net पे जाएं और आज ही अपना स्थान सुरक्षित करें

00:00:55.410 --> 00:00:58.590
वो है m365.net

00:00:58.590 --> 00:01:03.430
अभी m365.net पे जुड़ें और हम आपको जनवरी में

00:01:03.430 --> 00:01:04.450
लाइव देखेंगे

00:01:04.450 --> 00:01:10.450
यदि आपने कभी कोई सॉलुशन खोला है और तुरंत फाइलों संदर्भो और बग्स के जाल से घबरा गया है

00:01:10.450 --> 00:01:11.350
तो आप अकेले नहीं है

00:01:11.350 --> 00:01:14.150
अधिकांच developers पतियाशी रूप से काम करते हैं

00:01:14.150 --> 00:01:14.930
यहां patching वहाँ debugging

00:01:14.930 --> 00:01:17.390
GitHub Co-Pilot का Agent Mode गया पक संदर्भ रखने

00:01:17.390 --> 00:01:19.670
और फाइलों के बीच परिवर्तनों को समनवित करने का लक्षे रखता है

00:01:19.670 --> 00:01:21.510
इस वीडियो में हम दिखाएंगे कि

00:01:21.510 --> 00:01:23.790
एक वास्तिविक podcast.net और Azure Project के अंदर

00:01:23.790 --> 00:01:25.090
वो workflow कैसा देखता है

00:01:25.090 --> 00:01:28.310
हम एक live solution देखेंगे और agent बदलाव के पहले और बाद का production करेंगे

00:01:28.310 --> 00:01:29.930
आप देखेंगे कि come overhead के साथ

00:01:29.930 --> 00:01:31.450
multi-file code कैसे generate करें

00:01:31.450 --> 00:01:32.870
cross file थूटियों को तेजी से हल करें

00:01:32.870 --> 00:01:34.570
और यहां तक की features के फोल्ड करने के लिए

00:01:34.570 --> 00:01:36.130
साधारन भाशा विनदेश का उप्योग करें

00:01:36.130 --> 00:01:37.650
और वहां पहुंचने से पहले

00:01:37.650 --> 00:01:39.570
iOS Dibging Loop की छिपी होई लागत से शुरू करें

00:01:39.570 --> 00:01:41.630
जिसमें हम में से बहुत से लोग हर दिन रहते हैं

00:01:41.630 --> 00:01:43.370
पैचवक Dibging की छिपी होई लागत

00:01:43.370 --> 00:01:45.350
अब एक ऐसी तुर्टी को ठीक करने के लिए बैठते हैं

00:01:45.350 --> 00:01:46.510
जो काफी सार लगती है

00:01:46.510 --> 00:01:47.590
अप्लिकेशन बिड़न ही होता है

00:01:47.590 --> 00:01:49.890
और कंसोल आपकी मुखे प्रोजेक्ट फाइल में एक पंक्ती को फ्लैक करता है

00:01:49.890 --> 00:01:51.570
आप विधी में बदलाव करते हैं

00:01:51.570 --> 00:01:52.970
और सोचते हैं कि आपने इसे हल कर लिया है

00:01:52.970 --> 00:01:55.330
जब तक कि बही संदेश लड़ा अलग रूप में फिर से दिखाई ने दे

00:01:55.330 --> 00:01:59.270
असली समस्या का पता लगाने से पहले आधा गुंटा और निकल जाता है

00:01:59.270 --> 00:02:02.110
एक लापता निर्भरता जो किसी अन्या प्रोजेक्ट फोल्डर में छिपी हुई है

00:02:02.110 --> 00:02:05.030
जब तक संदर्व सही किया जाता है और आप पुना पर नियोजित करते हैं

00:02:05.030 --> 00:02:07.110
आपकी दुपहर का अधिकान समय पैच वर्क में घुल चुका होता है

00:02:07.110 --> 00:02:09.890
आपके दुआरा नियोजित फीचर वर्क कल के लिए टाल दिया जाता है

00:02:09.890 --> 00:02:11.930
ये पैटर्न इतना समान है कि समान लगता है

00:02:11.930 --> 00:02:15.570
सतर पर आप आगे बढ़ रहे हैं क्योंकि आपके दुआरा ठीक या प्रतिक बगी जीत जैसा लगता है

00:02:15.570 --> 00:02:17.390
विवहार में आप गोल-गोल घुम रहे

00:02:17.390 --> 00:02:20.250
लूप है कोड, कमपाइल, ठुटी, फिक्स, दोहराएं

00:02:20.250 --> 00:02:23.490
घंटो कारण और प्रभाव के पीछे भागनी में गायब हो जाते हैं

00:02:23.490 --> 00:02:26.510
और शुद्ध परणाम सार्थक, सुधार के बजाए प्रतिकरियाशील प्रगती है

00:02:26.510 --> 00:02:28.730
यह सेटिक लूप के लिए एक दुपहल खोदी है

00:02:28.730 --> 00:02:31.750
एक लाइन का कमेंट छोड़े में शीर्श रिप्लाई पढ़ूँगा

00:02:31.750 --> 00:02:36.130
यह चकर इसलिए ठकाओ है क्योंकि हमारे आस पास के उपकरण आगे बढ़ रहे हैं

00:02:36.130 --> 00:02:37.630
लेकिन तरीका नहीं

00:02:37.630 --> 00:02:39.110
एडिटर्स में नए फीचर जुड़ते हैं

00:02:39.110 --> 00:02:41.550
फ्रेमवर्क विकसित होते हैं और इंटेग्रेशन गहरे होते हैं

00:02:41.550 --> 00:02:43.390
लेकिन टिबगिंग अभी भी प्रतिकरियात्मक है

00:02:43.390 --> 00:02:46.370
यह एक बढ़ती हुई आग को बाल्टी बार पानी से रोकने जैसा है

00:02:46.370 --> 00:02:49.190
हर भड़कती आग को तरण संभाल लिया जाता है

00:02:49.190 --> 00:02:50.430
लेकिन इसकी जड़े बनी रहती हैं

00:02:50.430 --> 00:02:52.090
जो अगली आग की गारंटी देती हैं

00:02:52.090 --> 00:02:52.770
जो अगली आगी है

00:02:52.770 --> 00:02:55.230
और हर टेर्स्विच के साथ थिपी विलागत बढ़ती जाती है

00:02:55.230 --> 00:02:57.550
आप एक सर्विस क्लास से कॉन्फिगरेशन फाइल में जाते हैं

00:02:57.550 --> 00:03:00.270
फिर सीधे डिपेंडेंसी ग्राफ पर कूत पड़ते हैं

00:03:00.270 --> 00:03:02.430
हर बदलाव आपको तरक्यूस कड़ी से बाहर निकाल देता है

00:03:02.430 --> 00:03:03.930
जिससे मानसिक रिसेट करना पड़ता है

00:03:03.930 --> 00:03:06.230
ये सिर्फ विंडो बदलने में लगा समय नहीं है

00:03:06.230 --> 00:03:09.090
ये बारब संदर्ब कुफिर से बनाने का मानसिक बोज है

00:03:09.090 --> 00:03:13.190
दिन भर में वे छोटे री से टिक अठा होकर भारी हो जाते हैं

00:03:13.190 --> 00:03:16.250
अलगार डिब्लोपर्स के लिए ठकाने राशा और समय की बरबादी की रूप में दिखती है

00:03:16.250 --> 00:03:19.970
एंटरप्राइस प्रोजेक्ट्स पर काम करने वाले टीमों के लिए प्रभाव और भी बड़ जाते है

00:03:19.970 --> 00:03:23.990
डिबिगिंग लूप स्प्रिंट लक्षियों को पटरी से उतारते हैं फीचर्स की लाँचिंग में

00:03:23.990 --> 00:03:26.590
देरी करते हैं और बैक हॉक को बढ़ाते हैं

00:03:26.590 --> 00:03:30.590
तकनीक की रिंग का मजबूत होना आग बुझाने में बरबाद हुए घंटों का एक और दुश्प्रभाव है

00:03:30.590 --> 00:03:35.530
कई टीमें बताती हैं कि उनके विकास का एक बड़ा हिस्सा प्रतिक्रियात्मक डिबगिंग में खर्च हो जाता है

00:03:35.530 --> 00:03:37.270
ये इंजलिंग का रुमाजचक हिस्सा नहीं है

00:03:37.270 --> 00:03:41.250
कोई भी पांच बार एक ही डिप्रिंडनसी में इस मैच का पीछा करने के लिए रोडमैप नहीं बनाता

00:03:41.250 --> 00:03:43.830
फिर भी हर हफते समय यहीं खर्च हो जाता है

00:03:43.830 --> 00:03:48.130
जब तुर्टियो को ठीक करना ही प्रगती बन जाता है तो नए फीचर्स बनाना गौन हो जाता है

00:03:48.130 --> 00:03:49.990
और आर्किटेक्चर चुपचाप सफर करता है

00:03:49.990 --> 00:03:54.910
कड़वा सच यह है कि पैच वर्क डेबिगिंग न केवल चीजों को धीमा करती है

00:03:54.910 --> 00:03:58.230
यह डिजाइन के बजाए प्रतिक्रिया की संस्कृति को बढ़ावा देती है

00:03:58.230 --> 00:04:01.430
आप सिस्टम बनाने के बजाए आग बुझाने में समय बिता रहे है

00:04:01.430 --> 00:04:04.270
यह अलपकालिक रूप से प्रोड़क्ट को जीवित रख सकता है

00:04:04.270 --> 00:04:07.550
लेकिन यह टीम की शमता और विश्वास के साथ शिप करने की गती को सीमित करता है

00:04:07.550 --> 00:04:09.810
तो चलिए उस छवी आग बुझाने पर रुखते है

00:04:09.810 --> 00:04:12.270
होट स्पोट पर दोड़ें पानी डालें आगे बढ़ें

00:04:12.270 --> 00:04:14.570
समस्य यह नहीं कि डेवलपर्स इसमें अच्छी नहीं है

00:04:14.570 --> 00:04:15.370
वे है

00:04:15.370 --> 00:04:18.050
समस्य यह है कि आग कभी वास्ता में नहीं रुखते

00:04:18.050 --> 00:04:20.290
वे बस घूमती रहती है नई फाईलों

00:04:20.290 --> 00:04:21.430
नए प्रोजेक्स में भड़ती है

00:04:21.430 --> 00:04:24.110
सबको निर्मान के बजाए प्रतिक्रिया मोड में रखती है

00:04:24.110 --> 00:04:26.390
यह सवाल उठाता है क्या होगा

00:04:26.390 --> 00:04:28.350
अगर यह चक्र केवल आप पर निर्भन न हो

00:04:28.350 --> 00:04:33.110
क्या होगा अगर ट्रेसिंग, स्विचिंग और पैचिंग के दोहराओ वाले हिस्सों को अलग तरह से मैनेज किया जा सके

00:04:33.110 --> 00:04:35.270
जबकि आप निर्मान पर केंद्रित रहें

00:04:35.270 --> 00:04:38.610
क्योंकि भले ही आग बुझाने का तनाव इस पश्ट है

00:04:38.610 --> 00:04:40.630
लेकिन एक और दबाव बिंदू है जिसे हमने अभी तक नहीं चुआ है

00:04:40.630 --> 00:04:44.550
असली मुश्किलता बाती है जब आपका प्रोजेक्स सिर्फ एक फाइले एक मड्यूल तक सीमित नहीं रहत

00:04:44.550 --> 00:04:47.650
जब आपको जिस बदलाओ की जरूरत है वो एक साथ कही लेयर्स में फैला हो

00:04:47.650 --> 00:04:50.970
कल्पना करें कि आप एक ऐसे solution पर काम करने बैठते हैं जहां

00:04:50.970 --> 00:04:54.010
लॉजिक अलग-अलग projects, services और libraries में बिखरा हुआ है

00:04:54.010 --> 00:04:57.250
जिस हिस्से कि आपको ज़रूरत है वो तीन जगों पर मुझूद है

00:04:57.250 --> 00:04:59.750
और इसे अपने दिमाग में सही रखना ही एक बड़ी चुनौती है

00:04:59.750 --> 00:05:03.530
Multifile अविवस्था बना AI संदर्भ नियंत्रन

00:05:03.530 --> 00:05:07.870
जब projects कई layers में फैले हो तो असली चुनौती code लिखना नहीं होती

00:05:07.870 --> 00:05:10.450
इन सभी चलते वे हिसों को एक साथ जोड़ कर रखना है

00:05:10.450 --> 00:05:15.550
यहीं पर Multifile अविवस्था और AI संदर्भ नियंत्रन के बीच का तनाव सबसे इस पर श्रूप से दिखता है

00:05:15.550 --> 00:05:18.950
एक बड़े .NET solution का उधारन है जिसमें एक दरजन से अधिक projects हो

00:05:18.950 --> 00:05:21.810
कोई भी नया feature आमतार पे एक साथ अलग-अलग लिए इसको प्रभावित करता है

00:05:21.810 --> 00:05:27.070
एक जगा controller, दूसरी जगा service और configuration फाइलों का एक set जो कहीं और मौजूद है

00:05:27.070 --> 00:05:31.930
एक भी line लिखने से पहले आप संदर्भों को खोजने और निर्भरताओं की जाच करने में समय बिताते हैं

00:05:31.930 --> 00:05:35.350
यह उमीद करते हुई कि एक छोटा सा बदलाओ आगे जाकर किसी बड़ी खराबी का कारण न बढ़े

00:05:35.350 --> 00:05:37.130
यह workflow को यह अपवाद नी

00:05:37.130 --> 00:05:41.930
Enterprise application में यह सामाने हैं खासकर जब Azure services और integrations में शामिल हो जाते हैं

00:05:41.930 --> 00:05:44.430
इन systems का structure फ्रैट नहीं होता है

00:05:44.430 --> 00:05:50.050
Interface, Dependency, Injection Mapping और Cross Project संदर यह सब इसमें भूमी का निभाते हैं

00:05:50.050 --> 00:05:53.530
Azure के जुडने से कुछ निरुभरता है solution folder से पूरी तरह बाहर हो जाती हैं

00:05:53.530 --> 00:05:57.970
जैसे function apps, service bus bindings, resource settings और storage connections

00:05:57.970 --> 00:06:04.190
आप अपने ID में code, disk पर config fellow और cloud में परिभाशी services के बीच तालमिल बिठा रहे होते हैं

00:06:04.190 --> 00:06:06.530
यह मैंसे किसी को इस बात की परवानी है कि आप कम क्लिक करना चाते हैं

00:06:06.530 --> 00:06:10.530
हर बार जब आप संदर बदलते हैं तो आप पूरी तस्वीर को दुबारा बनाने में अपनी उर्जा खर्च करते हैं

00:06:10.530 --> 00:06:13.190
हम ऐसे ज़्यादा तर लोग उसंदर अपको अपनी working memory में समालने के गुशिश करते हैं

00:06:13.190 --> 00:06:16.670
शुरुबात में यह प्रबंध नहीं होता है लेकिन जैसे ऐसे project बढ़ता है गलतिया होने लगती है

00:06:16.670 --> 00:06:19.870
आप service में एक नया method तो जोड देते हैं लेकिन उसका DIR station भूल जाते हैं

00:06:19.870 --> 00:06:24.850
आप एक Azure function को code करते हैं और बाद में बता चलता है कि binding कभी host और JSON या deployment template में जोड़ी ही नहीं गई थी

00:06:24.850 --> 00:06:28.370
runtime तक आपको कोई alert नहीं मिलता जब आप उछ नया मनाने के बज़ाए डिविंग में लगे हो

00:06:28.370 --> 00:06:30.230
code लिखना खुद में कठी निस्सा नहीं

00:06:30.230 --> 00:06:31.730
कठी निस्सा cross file coordination है

00:06:31.730 --> 00:06:34.210
हर कोई tabs के बीच भटकने की उस भावना को जानता है

00:06:34.210 --> 00:06:39.290
controller से service में, फिर model में, फिर configuration फाइलों में और फिर वापस केवल ये भूलने के लिए

00:06:39.290 --> 00:06:41.450
कि आपने वो file खोली ही क्यों थी

00:06:41.450 --> 00:06:44.410
ये एक छोटा व्यवधान है जो दिन में दर जनोबार दोहराया जाता है

00:06:44.410 --> 00:06:48.390
ये interaction जमाओ कर एक घर्षन पैदा करता है तो वास्तविक प्रगति को धीमा कर देता है

00:06:48.390 --> 00:06:53.670
परणामस सुरूप delivery धीमी हो जाते है इसलिए नहीं कि coding धीमी है बलकि इसलिए क्योंकि सब कुछ सिंग में ध्यान बटक जाता है

00:06:53.670 --> 00:06:56.350
ये overhead cloud first projects में और बढ़ जाता है

00:06:56.350 --> 00:07:00.210
Azure और प्रमुक सेटिंग्स को कई जगों पर रखता है जैसे

00:07:00.210 --> 00:07:05.690
local config file या bicep templates और CI by CD pipelines

00:07:05.690 --> 00:07:10.410
जो एक साधरन फीचर अनोज जैसा दिखता है वक्सर एर्ट्रेक्शन की चार परतों में फैला होता है

00:07:10.410 --> 00:07:12.550
जा तिलता वेकल्पिक नहीं है

00:07:12.550 --> 00:07:14.730
ecosystem के काम करने के तरीके में ये शामिल है

00:07:14.730 --> 00:07:17.670
अब यहाँ agent mode एक संभावित बदलाव की रूप में आता है

00:07:17.670 --> 00:07:19.270
इस सब कुछ आप पर छोड़ने के बजाए

00:07:19.270 --> 00:07:22.330
इसे कई file में व्यापक संदर context बनाए रखने के लिए design किया गया है

00:07:22.330 --> 00:07:25.490
इसके मतलब है कि जब आप एक परत में बदलाव के लिए कहते हैं

00:07:25.490 --> 00:07:26.550
तो ये दूसरों को अंदेखा नहीं करता है

00:07:26.550 --> 00:07:29.350
demo में मैं एक नया Azure function बनाऊंगा

00:07:29.350 --> 00:07:31.410
और दिखाऊंगा कि agent कैसे method body बनाकर

00:07:31.410 --> 00:07:34.150
binding config तयार करके और host को update करके मदद करता है

00:07:34.150 --> 00:07:37.770
जेसन और यहां तकी सही day registration का सुझाओ भी देता है

00:07:37.770 --> 00:07:40.970
या आम तोर पर एक बहुत चर्णी प्रक्रिया है जो अलगलग फाइलों में बिख्री होती है

00:07:40.970 --> 00:07:43.250
एक agent इसे एक ही प्रवा में सुवस्तित कर सकता है

00:07:43.250 --> 00:07:45.550
या आपके निर्णे को बदलने के बारे में नहीं है

00:07:45.550 --> 00:07:47.450
बलकि दोहराओ वाले कामों को हटाने के बारे में है

00:07:47.450 --> 00:07:49.890
ताकि आप वास्तिविक डिजाइन विकल्पों पर ध्यान के अंद्रत कर सके हैं

00:07:49.890 --> 00:07:52.730
इंसान एक मोटा खाका अपने दिमाग में रख सकते हैं

00:07:52.730 --> 00:07:54.690
या वाइड बोर्ड पर बना सकते हैं

00:07:54.690 --> 00:07:56.610
एक AI हर फाइल की बारिकों को ट्रैक कर सकता है

00:07:56.610 --> 00:07:57.590
और विशे से भटकता नहीं है

00:07:57.590 --> 00:08:00.170
जो हमारे लिए भारी संगयनात्मक भार जैसा लगता है

00:08:00.170 --> 00:08:01.810
वो एजेंट के लिए के वल आधारभूत संदर वे

00:08:01.810 --> 00:08:04.430
व्याभारी कंतर ये है कि हम बिखरेवे टैप के वीच

00:08:04.430 --> 00:08:06.330
उलजने के बजाए औरकस्टेटर बदलावों की और बढ़ते हैं

00:08:06.330 --> 00:08:07.430
जो सिंक में रहते हैं

00:08:07.430 --> 00:08:08.930
में डेमो के दोरान एजेंट तवारा बनाए गए

00:08:08.930 --> 00:08:11.090
पुल रिक्वेस्ट या डिफ को भी दिखाऊंगा ताकि आप देख सकें कि

00:08:11.090 --> 00:08:11.970
क्या बदलाव किये गए है

00:08:11.970 --> 00:08:13.970
वो स्पष्टता मायने लगते हैं

00:08:13.970 --> 00:08:16.570
आपके पास समिक्षा करने और उसे मंजूरी देने का पूरा नियंतरन होता है

00:08:16.570 --> 00:08:19.010
जबकि कई फाइलों को अपडेट करने का महनत भरा काम आपके लिए हो जाता है

00:08:19.010 --> 00:08:20.990
तो एक दोपहे टुकणों को जोड़ने में बिताने के बजाए

00:08:20.990 --> 00:08:22.690
आप एक बाब बदलाव का निर्देश देते हैं

00:08:22.690 --> 00:08:24.230
जनरेट की अपडेट्स की पुष्टी करते हैं

00:08:24.230 --> 00:08:26.370
और उचिस तरह डिजाइन पर आगे बढ़ते हैं

00:08:26.370 --> 00:08:28.270
राहत सिर्फ क्लेक या की स्ट्रोक बचाने में नहीं है

00:08:28.270 --> 00:08:30.250
बलकि दरजन भर फाइले कैसे जुड़ी हैं

00:08:30.250 --> 00:08:33.430
ये खोजने के बजाए वास्तिविक समस्याओं को सुलजाने पर ध्यान केंद्रत करने में है

00:08:33.430 --> 00:08:36.470
ये लाब तब सबसे स्पर्ष्ट होता है जब चीज़े तूटती हैं

00:08:36.470 --> 00:08:38.730
क्योंकि बहतर संदर्व हैंडलिंग के बावजूद सिस्टम विफल होते हैं

00:08:38.730 --> 00:08:43.950
और यहीं से अगली परिक्षा शुरू होती है

00:08:43.950 --> 00:08:46.670
सामने आने वाली तुरुटियों को कैसे खोजा और हल किया जाए

00:08:46.670 --> 00:08:49.330
तुरुटियों की खोज से लेकर स्वायत सुधारा तक

00:08:49.330 --> 00:08:52.050
सोचे कि आप कितनी बार किसी ऐसे error message का सामना करते हैं

00:08:52.050 --> 00:08:53.350
जो सीधे एक file की और इशारा करता है

00:08:53.350 --> 00:08:55.750
आप stacktrist का पालन करके उस method तक जाते हैं

00:08:55.750 --> 00:08:58.550
एक छोटा सा बदलाव करते हैं और rebuild दबाते हैं

00:08:58.550 --> 00:09:00.450
ये एक इसपष्ट समाधान लगता है जब तक कि

00:09:00.450 --> 00:09:02.990
वही तुरुटि फिर से थोड़े अलग रूप में सामने ना आ जाए

00:09:02.990 --> 00:09:05.890
तब ही आपको एसास होता है कि stacktrist ने के वह लक्षन दिखाया था

00:09:05.890 --> 00:09:07.550
असली समस्या कहीं और शेपी होती है

00:09:07.550 --> 00:09:09.790
शायद किसी supporting class में या किसी ऐसी config file के अंदर

00:09:09.790 --> 00:09:11.070
जिसे आपने पुरे हफ्टे नहीं खोला

00:09:11.070 --> 00:09:12.030
जिसे आपने पुरे हफ्टे ने

00:09:12.030 --> 00:09:14.190
हर developer ने इस तरह के भटकाओ का सामना किया है

00:09:14.190 --> 00:09:15.330
जो समस्या दिखती है

00:09:15.330 --> 00:09:16.650
समाधान असल में वहाँ नहीं होता

00:09:16.650 --> 00:09:18.150
इसमें बहुत समय बरबाद होता है

00:09:18.150 --> 00:09:19.950
आप एक चीज़ बदलते हैं, rebuild करते हैं इंदवार

00:09:19.950 --> 00:09:21.790
फिर एक नए तूटी सामने आती है

00:09:21.790 --> 00:09:24.290
जो आपको दूसरी फाइल, दूसरे बदला और एक और rebuild के और ले जाती है

00:09:24.290 --> 00:09:26.050
ये लूप उत्पादक लगता है

00:09:26.050 --> 00:09:28.490
क्योंकि आप काम कर रहे हैं, type कर रहे हैं, recompile कर रहे हैं

00:09:28.490 --> 00:09:30.350
लेकिन वास्तों में ये समाधान के बज़ाए

00:09:30.350 --> 00:09:31.870
केवल trial और error है

00:09:31.870 --> 00:09:33.810
ये चक्कर घंटों बरबाद कर सकता है

00:09:33.810 --> 00:09:35.730
जिसे आपको किवल मामली सुधार मिलते हैं

00:09:35.730 --> 00:09:38.370
लेकिन जिस feature पर आप काम कर रहे थे, उस पर प्रिवास्तविक प्रगती नहीं होती

00:09:38.370 --> 00:09:40.170
असली कीमत अफसर की होती है

00:09:40.170 --> 00:09:42.930
जब आप rebuild और error try के जाल में फसे होते हैं

00:09:42.930 --> 00:09:44.630
तो आप न तो व्यावसाइक समस्या है सुझा रहे होते हैं

00:09:44.630 --> 00:09:45.950
और नहीं वो कारेक्शमता दे रहे होते हैं

00:09:45.950 --> 00:09:48.030
जिसका आपके उप्योपरत इंतिजार कर रहे हैं

00:09:48.030 --> 00:09:50.110
अपकी गति डिजाइन के बजाए अंदाजों में खर्च हो जाती है

00:09:50.110 --> 00:09:51.690
उस पल में ये सक्री लगता है

00:09:51.690 --> 00:09:55.270
लेकिन ये घंटे सिस्टम को तूटने से बचाने के अलावा कुछ खास नहीं करते

00:09:55.270 --> 00:09:58.510
पूरी टीम में ये सते काम सब कुछ धीमा कर देता है

00:09:58.510 --> 00:10:01.330
और उन फीचर्स का बैक लॉग बना देता है जो लादातार आगे खिसकते रहते है

00:10:01.330 --> 00:10:04.510
यहीं से एजेंट वर्कफ्लो कुछ अलग दिखने लगता है

00:10:04.510 --> 00:10:08.130
विचार के लो उसे क्लाइन पर रुखने का नहीं है जिस टैक्रस हाइलाइट करता है

00:10:08.130 --> 00:10:10.930
इसके बजाए इसे सिस्टम इस तरह ये संदर्ब को ध्यान में रखने के लिए

00:10:10.930 --> 00:10:14.810
डिजाइन किया गया है जो ये पूछता है कि न, क्यों इस फाइल को क्या करना चाहिए

00:10:14.810 --> 00:10:17.750
बलकि निरंतता बहाल करने के लिए जुड़े हुए हिस्सों में क्या बदलाव ज़रूरी

00:10:17.750 --> 00:10:21.170
ब्याभारिक रूप से इसका मतलब है कि आप इसे ऐसी एडिटिंग का प्रस्ताव देते हैं सकते हैं

00:10:21.170 --> 00:10:22.110
जो कई फाइलों में फैली होती है

00:10:22.110 --> 00:10:25.990
उधारन के लिए आप डेमो में देखेंगे कि जब किसी मेथड में बदलाव की जुरूरत होती है

00:10:25.990 --> 00:10:28.810
तो यह समद्ध कॉन्फिग्रेशन या डिप्लाइमें टैप्रेट में भी सुछाओ दे सकता है

00:10:28.810 --> 00:10:30.470
ताकि आपको ने ढूंडाना पड़े

00:10:30.470 --> 00:10:33.030
यह अटो कम्प्लीट से कुछ व्यापक होनी के और कदम है

00:10:33.030 --> 00:10:35.550
अटो कम्प्लीट लाइने पूरी करता है

00:10:35.550 --> 00:10:37.070
एजेंट फाइलों के बीच समन्वे करता है

00:10:37.070 --> 00:10:38.950
और यह समन्वे तब सबसे जादा माहिने रखता है

00:10:38.950 --> 00:10:40.310
जब तो ट्रोटियां के वाल एक जगा नहीं होती

00:10:40.310 --> 00:10:42.210
एज़र एज़र का एक समान्य धारने

00:10:42.210 --> 00:10:43.930
आपने एक नया फंक्शन अप बना है

00:10:43.930 --> 00:10:45.070
लेकिन डिप्लॉय होने के बाद

00:10:45.070 --> 00:10:45.970
क्यों ट्रिगर विफल हो जाता है

00:10:45.970 --> 00:10:47.750
क्योंकि बाइंडिंग मैथर सिगनेचर से मिल नहीं खाती

00:10:47.750 --> 00:10:50.350
सामान्य तोर पर आप लॉग्स में खंगालते हैं

00:10:50.350 --> 00:10:51.830
पता लगाते हैं कि कौन सी बाइंडिंग गलत है

00:10:51.830 --> 00:10:53.910
फंक्शन जेसन को हाथ से ठीक करते हैं

00:10:53.910 --> 00:10:55.310
शायद अपना इंफ्रस्ट्रक्शर टेंप्रेट भी बदलते हैं

00:10:55.310 --> 00:10:56.370
यदि भाँ भी कोई वैल्यू बदलते हैं

00:10:56.370 --> 00:10:57.330
यदि भाँ भी कोई वैल्यू बे मेरे

00:10:57.330 --> 00:10:59.070
हर कदम एक अलग दौड है

00:10:59.070 --> 00:11:01.150
और हर सुधार के बाद एक और टेस्टरन ज़रूरी हो जाता है

00:11:01.150 --> 00:11:03.730
एजेंट मोड के साथ वर्कफ्लो अलग होता है

00:11:03.730 --> 00:11:05.570
ये कोड बदलाव का प्रस्ताव दे सकता है

00:11:05.570 --> 00:11:07.530
उचित फंक्शन जेसन बाइंडिंग जैनरेट कर सकता है

00:11:07.530 --> 00:11:09.310
और यदि डिप्लाइमेंट स्क्रिप्स में कोई गड़बढ है

00:11:09.310 --> 00:11:10.270
तो उने भी ठीक कर सकता है

00:11:10.270 --> 00:11:12.170
आप समिक्षा करते हैं, पुष्टी करते हैं

00:11:12.170 --> 00:11:14.690
और हर परत को जोड़ने में घंटों बरबाद की बिना आगे बढ़ते हैं

00:11:14.690 --> 00:11:15.850
और भरोसा यहां सबसे महत्कुल

00:11:15.850 --> 00:11:18.970
किसी को भी ऐसा नहीं लगना चाहिए कि बैक्ग्राउंड में अद्रिश बदलाओ हो रहे हैं

00:11:18.970 --> 00:11:20.190
इसलिए रिव्यू फ्लो माइने रखता है

00:11:20.190 --> 00:11:22.110
इस डेमो में हम इसे साथ मिलकर देखेंगे

00:11:22.110 --> 00:11:24.250
एजेंट समन्मित बदलाओं का सुझाओ देता है

00:11:24.250 --> 00:11:27.110
हम डिफ खोल कर यह जाचेंगे कि उसने क्या जनरेट किया है

00:11:27.110 --> 00:11:28.210
अपने यूनिट टेस्ट चलाएंगे

00:11:28.210 --> 00:11:30.070
अस्थाने अस्तर पर बिल्ड को वैलिडेट करेंगे

00:11:30.070 --> 00:11:31.950
और तभी तैय करेंगे कि बदलाओं को स्विकार करना है

00:11:31.950 --> 00:11:32.590
या स्विकार

00:11:32.590 --> 00:11:35.230
वो वैलिडेशन लूप आपको पूरा नियंतरन देता है

00:11:35.230 --> 00:11:36.830
और साथ ही मैनत वाले काम को कम करता है

00:11:36.830 --> 00:11:39.690
यह जोड देना जरूरी है कि एजेंट्स तेजी से काम करने में

00:11:39.690 --> 00:11:41.970
मदद कर सकते हैं लेकिन अच्छी इंजिनेरिंग पर्थाओं का स्थान नहीं ले सकते हैं

00:11:41.970 --> 00:11:45.230
आपको अभी भी कोड रिव्यूज और C.I. को अनिवारी गेट कीपर के रूप में ही देखना चाहिए

00:11:45.230 --> 00:11:48.070
AI को जासुसी वाले काम में लगने वाले समय को कम करने दे

00:11:48.070 --> 00:11:50.870
लेकिन आटोमेटिड चेक और मानवी समीशा को सुरक्षा जाल बनाये रखें

00:11:50.870 --> 00:11:53.290
वो संतुरन भरोसे की समस्या को हल करता है

00:11:53.290 --> 00:11:55.710
और सुनिश्चित करता है कि गती का लाबिस्तिरता को नुकसन में पहुचा

00:11:55.710 --> 00:11:57.530
गती का ये अंतरकालपनिक नहीं है

00:11:57.530 --> 00:12:00.570
जहां गलतियों को ढोड़ने और मैनुल पैचिंग में आधा दिन लग सकता है

00:12:00.570 --> 00:12:05.510
और बचाया गया समय उस काम में वापस लगता है

00:12:05.510 --> 00:12:07.270
जिस पर आप वास्तों में उर्जा खर्च करना चाते है

00:12:07.270 --> 00:12:10.070
वे फीचर जो आपके यूजर्स को दिखते हैं वे आर्किटेक्चर समधी फैसले

00:12:10.070 --> 00:12:11.150
जो आपके कोड़ बिस को बहतर बना

00:12:11.150 --> 00:12:13.430
और उन टाइम पर समस्याओं को सुझाने के बजाए

00:12:13.430 --> 00:12:15.030
आप आत्मिश्वास के साथ पहले से डिजाइन कर सकते

00:12:15.030 --> 00:12:17.710
इसलिए डिमगिंग लूप को आपके पूरे दिन को परिभाशिकता नहीं है

00:12:17.710 --> 00:12:20.690
एक एजेंट द्वारा क्रॉस फाइल अपडेट सुझाय जाने के साथ

00:12:20.690 --> 00:12:23.950
आप बिखरे वे सर्च के बजाए रिव्यू और अप्रूफ के रिदम पर आ जाते हैं

00:12:23.950 --> 00:12:25.910
आप गलतियों के बीच गोल-गोल घुमना बंद कर देते हैं

00:12:25.910 --> 00:12:27.850
और डेबगिंग को अपने वर्कफ्लो में एक सनरचे लगभग

00:12:27.850 --> 00:12:30.630
सुचालिच चरन के रूप में मानना शुरू करते हैं

00:12:30.630 --> 00:12:36.150
भबदलाव मानसिक जगा और समय को फीचर्स बनाने के लिए मुक्त करता है और एक बार जब गलतियों को ठीक करना

00:12:36.150 --> 00:12:39.730
कि अब लक्षणों का पीच्छा करने के बज़ए कुछ और बन जाता है तो ये कुछ बड़े के दरवाजे खोल देते हैं

00:12:39.730 --> 00:12:42.910
कि आप कैसे पूरे फीचर्स को इसी तरह की सरचे तरीके से शुरू कर सकते हैं

00:12:42.910 --> 00:12:46.370
कलप ना करें कि यदि वही वर्कफ्लो जो समनने सुधारों का प्रस्ताव देता है

00:12:46.370 --> 00:12:50.190
वो एक सररभाषा स्पेसिविगेशन ले सके और उसके चार और एक कारशी संदर्चन तयार कर सके

00:12:50.190 --> 00:12:52.650
यहीं से विकास का अगला चरण शुरू होता है

00:12:52.650 --> 00:12:57.550
सबसे दिल्चस बदलाऊं में से एक तब आता है

00:12:57.550 --> 00:12:59.910
जब आपके वर फाइलों और मैथड्स के संदर में सोचना बंद कर देते हैं

00:12:59.910 --> 00:13:01.810
और काम को सरभाषा में त्याब करना शुरू करते हैं

00:13:03.210 --> 00:13:05.710
यहीं पर बिना ओवर्हेट वाला स्पेक संदर्चन विकास कामाता है

00:13:05.710 --> 00:13:35.710
एक साधानन फीचर रिक्वेस्ट टेखने के कलप न कर, एक रिपोर्टिंग वर्कफ्लो जोड़ें, जो मासिक सरानश तियार करें, उन्हें स्टोर करें, और उन्हें एक एड्मिन पेज के माध्यम से उपलब्द कराएं, और उन्हें एक एड्मिन पेज के वलकुछ अलेक्�

00:13:35.710 --> 00:14:05.710
बड़े संगठनों में, इसका मतलब आम तौर पर लंबया वशकता दस्तावेज, कई पर्णों की डिजाइन शीट और कठोर आरेक होते हैं, जो सभी की गती को धीमा कर देते हैं, वेवविन्य में तुद्ध्योगों या वैश्विक स्तर पर वित्रिच टीमों में समझ में

00:14:05.710 --> 00:14:35.710
में हैं, एक बड़ जब स्पेसिरिकेशन वास्तर विक्ता से अलग होने लगता है, तो उसका रखरखाव बोज़ बन जाता है, यही कारण है कि वास्तर वे काम का अदेकांश हिस्सा पूर डिजाइन के बज़ाए तातकालिक समधान की और जुख जाता है, उन जब भी जो �

00:14:35.710 --> 00:15:05.710
एकसिस के साथ, सुरक्षित करें और सिस्टम आपके .NET समधान में फाइलों के पार एक बेसलाइन उत्पन करता है, डेमो में मैं एक सरल भाशा का स्पेसिफिकेशन जोर से पढ़ूँगा, फिर एजेंट द्वारा बनाएगी फाइले, कंट्रोलर्स, मॉडल्स और सर्विस

00:15:05.710 --> 00:15:35.710
एजेंट समर्थन के साथ, आप प्राकरतिक शब्दों में विचार को रिखांकित करते हैं, धाचा सामने आता है, और आप विवस्ते सनरशना का लाब बनाये रखते हुए वाइप कोडिंग की तरह ही तेजी से आगे बढ़ सकते हैं, उस रिपोर्टिंग वर्फलो को फिर

00:15:35.710 --> 00:16:05.710
से रेजिस्टर करना भूल जाना, बेशक, शैली का सवाल हमेशा बना रहता है, क्या ये बोईलर टेट को थोपेगा या परंप्राओं को अंदेखा करेगा, व्याभाली क्रूप से एजेंट अक्सर अपने सुझावों में मौझूदा प्रजेक्ट पैटिन को दर्शाते है

00:16:05.710 --> 00:16:35.710
पर भरोसा कर सकते हैं, जिसे भविष्य के विकास के लिए बहतर बनाया जा सकता है, इस स्पैसिफिकेशन का काम के वर डाइग्राम बनाने का धहर रखने वाले आल्किटेक्स तक सीमित रहने के बजाए, ये किसी भी ऐसे डेवलोपर के लिए एक उपकर्ण बन जाता है, �

00:16:35.710 --> 00:17:11.240
अधिक घंटे, सेटप में कम महनत, ये हमें सीधे उस सवाल पर लाता है, जिसकी हर डेवलोपर सबसे जादा परवा करता है, उत्पादक्ता के मामले में ये बदलाव वास्ताव में क्या माइने रखते हैं, उत्पादक्ता का लाब, असली सवाल ये नहीं है कि क्या आप य

00:17:11.240 --> 00:17:41.240
अकेलिए देखने पर ये मामली लगती हैं, लेकिन पूरे स्प्रिंट में जोडने पर ये तैय करते हैं कि कि इतना वास्तविक मूल डिलिवर किया जाता है, जो दिंचरिया जैसा दिखता है, वो डिलिवरी टाइम रिवर वास्तविक दभाव चिपाया रहते हैं, छिपा ह

00:17:41.240 --> 00:18:11.240
जो काम कहीं नहीं पहुंचता वो लॉब नहीं होता, क्योंकि वो उर्जा तो खर्च करता ही है, जैसे जैसे कोड़ बेस बढ़ते हैं, ये घर्षन केबल रैखी ग्रूप से नहीं बढ़ता है, अधीर परतों का मतलब है, याद रखने के लिए अधीर बढ़ता हैं, और काम �

00:18:11.240 --> 00:18:41.240
में कई मामलों में अनब्लॉक होने में कम समय लगने की रिपोर्ट करते हैं, इस वीडियो में हम एक पहले और बात का टास्क प्रदर्शित करेंगे ताकि आप प्रभाव का अंदाज़ा लगा सके हैं, मैं मैं मैनुल लूप से और फिर एजेंट के साथ एक ही एज़ूर फ

00:18:41.240 --> 00:19:12.520
फ्रिंट के अधूरे काम पर लोटने के बजाए आगे बढ़ने में मदद करता है, इन रंतरता समय के साथ समस्याओं को सुलजाने के बजाए बहतर डिलेवरी में बदल जाती है, गलतियों को ढूडने में पूरा दिन खराब होने से कोई भी इंजिनर ठक जाता है, धकान ह

00:19:12.520 --> 00:19:42.520
कई बाइंडिंग्स और सर्विस इंटिगरेशन वाला एक नया अजूर फंक्शन बिना मदद के दो दिन तक खिंच सकता है, कौन्फिगरेशन, टेस्टिंग और गलत रेफरेंस को ठीक करने के बीच काम बहुत लंबा हो जाता है, एक एजिन की मदद से वही फंक्शन आध

00:19:42.520 --> 00:20:12.520
को नहीं देख पाता है, जो वास्तव में हो रहा है, धौराव वाले काम को सौंपने से आपकी विश्य शक्यता कम नहीं होती है, बल्कि ये डिजाइन और आर्किटेक्ट्चर के लिए बच जाती है, जहां निरने लेने का महत्व है, वास्तव में आप छोटी गलतियों पर

00:20:12.520 --> 00:20:33.340
किये के बदलावों को सतेवित करने के लिए कोड रिव्यू को भरुसा रखें कि विस्त काम कम हो गया है, लेकिन सुरक्षा की वहीनियम लागू रखें, गती का अंतर तबी फायदे मन्द है, जब गुनवत्ता इस्तिर बनी रहे, मजबूर टेस्ट और स्मार्ट पियार र