इकाई 2 / 12

स्क्रिप्टिंग और स्वत: पूर्ण

लाभ:

  • इनलाइन पूर्णता के साथ कार्य प्रकार को सही करने के लिए चैट मोड को मैप करने की क्षमता
  • शक्तिशाली उत्पादन संकेत लिखने की क्षमता जिसमें इनपुट/आउटपुट अनुबंध, किनारे के मामले और शैली की बाधाएं शामिल हैं
  • विलय से पहले उत्पन्न कोड और किसी भी नई प्रस्तावित निर्भरता को मान्य करने की क्षमता

एआई के साथ एक डेवलपर का संपर्क का पहला बिंदु अक्सर स्वत: पूर्ण होता है - एक सुविधा जो आपके टाइप करते ही अगली पंक्ति का सुझाव देती है - या चैट विंडो में "उस फ़ंक्शन को टाइप करें" कहती है। वे दोनों एक ही इंजन का उपयोग करते हैं लेकिन अलग-अलग अनुशासन की आवश्यकता होती है। इस इकाई में, हम कोड पीढ़ी को यादृच्छिक "इसे लिखें" से एक इंजीनियरिंग चरण में बदलते हैं जिसका आउटपुट पूर्वानुमानित और सत्यापन योग्य होता है।

लक्ष्य एआई को एक ऐसे उपकरण से बदलना है जो आपकी टाइपिंग मशीन को गति देता है और इसे एक ऐसे प्रशिक्षु में बदल देना है जो आपके द्वारा निर्धारित बाधाओं के भीतर काम करता है। एक अच्छी तरह से निर्देशित प्रशिक्षु समय बचाता है; एक दिशाहीन प्रशिक्षु गंदगी पैदा करता है जिसे आपको बाद में साफ़ करना पड़ता है।

दो उपयोग मोड: इनलाइन समापन और चैट

जैसे ही आप अपने संपादक में टाइप करते हैं, इनलाइन पूर्णता चलन में आ जाती है; आप एक फ़ंक्शन हस्ताक्षर या एक टिप्पणी पंक्ति टाइप करते हैं और यह बाकी का सुझाव देता है। यह गति के लिए बहुत अच्छा है, लेकिन इसका एक संकीर्ण संदर्भ है: यह केवल तत्काल क्षेत्र में कोड देखता है। इसीलिए यह सबसे अच्छा काम करता है जब आप किसी टिप्पणी में अपना इरादा स्पष्ट रूप से लिखते हैं। उदाहरण के लिए, //उपयोगकर्ता ईमेल मान्य करें, अमान्य टिप्पणी होने पर ValidationError फेंकें, नीचे दिए गए सुझाव में उल्लेखनीय सुधार करता है।

चैट मोड बड़े और संरचित कार्यों के लिए है: "इस क्लास में पेजिनेशन जोड़ें", "उस सेवा का इंटरफ़ेस निकालें"। यहां आपके पास भूमिका, संदर्भ और प्रारूप देने की सुविधा है। सामान्य नियम है: छोटे और प्रवाहपूर्ण कार्यों को पूरा करना, उन कार्यों के लिए बातचीत जिनमें सोच और संरचना की आवश्यकता होती है।

युक्ति: "टैब" के साथ पूर्णता सुझाव को आंख मूंदकर स्वीकार न करें। एक सेकंड के लिए सुझाई गई पंक्ति पढ़ें; गलत वैरिएबल नाम या उलटी स्थिति आमतौर पर यहीं से लीक होती है।

इरादे को कोड में अनुवाद करने के चरण

  1. अनुबंध को परिभाषित करें. फ़ंक्शन का इनपुट, आउटपुट और त्रुटि व्यवहार क्या है? जैसे "ईमेल प्राप्त करें, यदि मान्य है तो सामान्य करें, यदि अमान्य है तो त्रुटि डालें"।
  2. बाधाएं बताएं. बाह्य निर्भरता का प्रयोग न करें? एक विशिष्ट शैली मार्गदर्शिका? क्या कोई प्रदर्शन सीमा है?
  3. एक उदाहरण दीजिए. एक इनपुट-आउटपुट जोड़ी ("ali@x.com → वैध, ali@ → त्रुटि") मॉडल के इरादे की समझ को भविष्यवाणी से सटीकता की ओर ले जाती है।
  4. छोटे-छोटे टुकड़े माँगें। एक कार्य, एक जिम्मेदारी. फिर अगले पर आगे बढ़ें।
  5. जनरेट किया गया कोड पढ़ें और चलाएँ. संकलन + त्वरित मैन्युअल प्रयास सबसे सस्ता आश्वासन कदम है।

तीन मिनी मामले

केस 1 - टिप्पणी-संचालित उत्पादन सटीकता बढ़ाता है। एक डेवलपर ने सबसे पहले एक खाली बॉडी के साथ डेट पार्सिंग फ़ंक्शन का अनुरोध किया और 3 राउंड में सही परिणाम प्राप्त किया। दूसरे प्रयास में, जब मैंने फ़ंक्शन को 4-लाइन टिप्पणी (स्वीकृत प्रारूप, समय क्षेत्र नियम, त्रुटि स्थिति) के साथ परिभाषित किया और इसका अनुरोध किया, तो वह कोड आया जो पहले दौर में काम करता था। वही मॉडल, वही दिन; अंतर केवल इरादे की स्पष्टता का था।

केस 2 - किसी संस्करण को निर्दिष्ट न करना महंगा है। एक टीम को Node.js के लिए निर्मित कोड में fs.promises की जगह लेगेसी कॉलबैक-आधारित API के साथ संघर्ष करना पड़ा। जब लाइन "नोड 20, ईएसएम, एसिंक/प्रतीक्षा का उपयोग करें" को प्रॉम्प्ट में जोड़ा गया, तो उत्पादन ने पहली बार परियोजना का अनुसरण किया; सुधार पर खर्च किए गए 12 मिनट का औसत रीसेट कर दिया गया।

केस 3 - बॉयलरप्लेट कोड में वास्तविक लाभ। एक माइक्रोसर्विस को 6 नए डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट - एक साधारण डेटा क्लास जो परतों के बीच डेटा ले जाता है) और उनके सत्यापन नियमों की आवश्यकता होती है। एआई द्वारा उत्पादित और समीक्षा किए जाने पर जो लगभग 90 मिनट का मैन्युअल काम हुआ करता था उसे घटाकर 35 मिनट कर दिया गया; चूंकि कोड दोहराव अधिक है और पैटर्न स्पष्ट है, एआई ने यहां अपने सबसे कुशल क्षेत्र में काम किया है।

चार प्रतिलिपि योग्य टेम्पलेट

अनुबंध-आधारित फ़ंक्शन निर्माण:

भूमिका: आप एक मेहनती {{भाषा}} डेवलपर हैं। कार्य अनुबंध:- नाम: {{नाम}}- इनपुट: {{प्रकार और उनका अर्थ}}- आउटपुट: {{प्रकार और अर्थ}}- त्रुटि स्थिति: {{क्या फेंका जाता है/कब लौटाया जाता है}}बाधाएं: {{कोई बाहरी निर्भरता/शैली/प्रदर्शन नहीं}}उदाहरण:- {{इनपुट_1}} -> {{आउटपुट_1}}- {{एंट्री_2}} -> {{त्रुटि_2}}पहले हस्ताक्षर + संक्षिप्त योजना दें, फिर कोड। लेखन परीक्षण, बस कार्य करें।

मौजूदा शैली से मेल खाने के लिए (कोड आधार के अनुसार अनुकूलित करें):

नीचे हमारे प्रोजेक्ट से एक उदाहरण फ़ंक्शन है; यहां नामकरण, त्रुटि प्रबंधन और टिप्पणी शैली सीखें। समान शैली के साथ {{new_task}} के लिए एक फ़ंक्शन लिखें। उदाहरण: {{current_code}}

कंकाल से भरने तक (स्टब → कार्यान्वयन):

टिप्पणियों में TODO के अनुसार नीचे फ़ंक्शन स्केलेटन भरें। हस्ताक्षर और रिटर्न प्रकार बदलें. ऐसा सहायक फ़ंक्शन न बनाएं जो अस्तित्व में न हो; यदि आवश्यक हो, तो मुझे बताएं "इस सहायक की आवश्यकता है"। {{skelet_kod}}

वैकल्पिक ऐप तुलना:

{{कार्य}} के लिए 2 अलग-अलग कार्यान्वयन दें: (ए) पठनीयता को प्राथमिकता देना, (बी) प्रदर्शन को प्राथमिकता देना। प्रत्येक के नीचे 1 वाक्य "कब बेहतर है" लिखें।

कमजोर संकेत/मजबूत संकेत

कमज़ोर: "मुझे एक ईमेल सत्यापन फ़ंक्शन लिखें।"
मजबूत: "टाइपस्क्रिप्ट 5, केवल मानक लाइब्रेरी। लिखें isValidEmail(इनपुट: स्ट्रिंग): बूलियन। रिक्त स्थान ट्रिम करें, इसे केस असंवेदनशील बनाएं, a@b.co मान्य है, a@, @b.co, खाली स्ट्रिंग अमान्य है। यदि आप रेगेक्स का उपयोग करने जा रहे हैं, तो अत्यधिक जटिल न हों; टिप्पणियों की 2 पंक्तियाँ जोड़ें।"

शक्तिशाली संस्करण; भाषा, संस्करण, हस्ताक्षर, किनारे के मामले और एक शैली बाधा लौटाता है। इस प्रकार, जेनरेट किया गया कोड काम करता है और आपके प्रोजेक्ट में फिट बैठता है।

दृष्टिकोण

कब उपयोग करें

ध्यान दें

इनलाइन पूर्णता

प्रवाह में छोटे आवेषण

बिना पढ़े सुझाव स्वीकार न करें

चैट में अनुबंध आधारित उत्पादन

नया फ़ंक्शन/वर्ग

उदाहरण और किनारे का मामला दीजिए

शैली नमूने द्वारा उत्पादन

मौजूदा कोड में जोड़ा जा रहा है

वर्तमान नमूना कोड चुनें

कंकाल भराई

हस्ताक्षर निश्चित, मुख्य भाग खाली

हस्ताक्षर बदलना

कोड दोहराव और निर्भरता जाल

एआई अक्सर अपने काम को आसान बनाने के लिए एक नई लाइब्रेरी की सिफारिश करता है। कभी-कभी यह सटीक होता है, कभी-कभी यह आपके प्रोजेक्ट में अनावश्यक निर्भरता जोड़ता है या ऐसे पैकेज का सुझाव देता है जो मौजूद नहीं है (एक मतिभ्रम)। नियम: आप प्रत्येक नई निर्भरता की पुष्टि करते हैं। यह सत्यापित किए बिना इसे प्रोजेक्ट में न जोड़ें कि पैकेज वास्तव में मौजूद है, बनाए रखा गया है और उसके पास उचित लाइसेंस है। अधिकांश समय परियोजना में पहले से मौजूद एक सहायक नए पैकेज से बेहतर होता है।

सावधानी: एआई द्वारा सुझाई गई आयात लाइनों की समीक्षा करें। एक गैर-मौजूद पैकेज नाम (जो "टाइपो-स्क्वैटिंग" नामक नकली पैकेज जैसा भी हो सकता है) दोनों संकलन को तोड़ता है और सुरक्षा जोखिम पैदा करता है।

सामान्य गलतियाँ

  • मॉडल द्वारा हस्ताक्षर निर्धारित होना। यदि आप इनपुट/आउटपुट प्रकारों को ठीक नहीं करते हैं, तो प्रत्येक उत्पादन के साथ एक अलग हस्ताक्षर आता है और एकीकरण मुश्किल हो जाता है।
  • किनारे के मामलों का जिक्र नहीं। खाली इनपुट, शून्य, नकारात्मक संख्या, बहुत बड़ा मान - यदि आप इन्हें निर्दिष्ट नहीं करते हैं, तो मॉडल किनारों को छोड़कर "खुशहाल पथ" लिखता है।
  • सुझाव का परीक्षण किये बिना उसे संयोजित करना। जो कोड काम करता प्रतीत होता है उसका मतलब यह नहीं है कि वह काम करता है।
  • अनावश्यक निर्भरता स्वीकार करना। एक-लाइनर के लिए पूरी लाइब्रेरी जोड़ने से तकनीकी ऋण बनता है।
  • शैली असंगति. प्रोजेक्ट के बाकी हिस्सों से भिन्न नामकरण और त्रुटि प्रबंधन कोड आधार को ख़राब बना देता है।

संक्षेप में

जब आप इरादे को स्पष्ट अनुबंध में बदलते हैं तो कोड जनरेशन शक्तिशाली होता है। छोटे, इन-स्ट्रीम कार्यों और वार्तालाप में संरचना स्थापित करने वाले कार्यों के लिए इनलाइन पूर्णता का उपयोग करें। आप इनपुट/आउटपुट प्रकार, एज केस, संस्करण और शैली निर्दिष्ट करते हैं; मॉडल का एक उदाहरण दीजिए; प्रत्येक नई निर्भरता को सत्यापित करें; और उत्पादित प्रत्येक टुकड़े को चलाएं और पढ़ें। एआई फॉर्मूलाबद्ध, दोहराव वाले कोड में सबसे अच्छा काम करता है - इसे आपके द्वारा निर्धारित सीमा के भीतर वहीं चलाएं।

आवेदन कार्य

अपने प्रोजेक्ट से एक वास्तविक छोटा फ़ंक्शन चुनें जिसे आपको लिखना है। पहले इसे "कॉन्ट्रैक्ट-आधारित फ़ंक्शन जेनरेशन" टेम्पलेट के साथ एआई पर प्रिंट करें, जिसमें इनपुट/आउटपुट प्रकार, दो किनारे के मामले और एक स्टाइल बाधा दी गई हो। जेनरेट किए गए कोड को संकलित करें और इसे दो अलग-अलग इनपुट के साथ आज़माएं। फिर उसी फ़ंक्शन को दोबारा पूछें, इस बार बिना किसी संदर्भ के "मुझे यह लिखें", और दो आउटपुट की लाइन दर लाइन तुलना करें: कौन से किनारे के मामले छूट गए थे, कितने सुधार की आवश्यकता थी?

चेकलिस्ट

  • [ ] मुझे पता है कि इनलाइन पूर्णता के साथ चैट मोड का उपयोग कहां करना है।
  • [ ] मैं फ़ंक्शन जेनरेशन में इनपुट/आउटपुट कॉन्ट्रैक्ट और एज केस निर्धारित करता हूं।
  • [ ] मैंने प्रॉम्प्ट में भाषा और संस्करण की जानकारी जोड़ने की आदत बना ली है।
  • [ ] मैं प्रत्येक उत्पादित टुकड़े को असेंबल करने से पहले संकलित और परीक्षण करता हूं।
  • [ ] मैं एआई द्वारा प्रस्तावित प्रत्येक नई निर्भरता की उसके अस्तित्व और आवश्यकता की पुष्टि करके पुष्टि करता हूं।
  • [ ] मैं जांचता हूं कि जेनरेट किया गया कोड प्रोजेक्ट की शैली से मेल खाता है।