एक अच्छा डेलphi वर्कफ़्लो छोटा होता है। प्रोजेक्ट फ़ोल्डर खोलें, एक बदलाव के लिए कहें, डिफ़ पढ़ें और अपना बिल्ड कमांड चलाएं। Arraydeck वास्तविक टूल्स के साथ उस लूप का पालन करता है, इसलिए हर कदम चैट में एक कार्ड छोड़ता है जिसे आप विस्तार से देख और जांच सकते हैं, पहली खोज से लेकर आखिरी एग्जिट कोड तक। सारांश के पीछे कुछ छिपा नहीं है। यदि कोई कदम गलत लगता है, तो आप उस लूप को वहीं रोक सकते हैं, बदलाव को अस्वीकार कर सकते हैं और अनुरोध को फिर से कह सकते हैं, और फ़ाइलें उस कदम से पहले जैसी ही रहती हैं। ये चारों चरण एक छोटी यूनिट और कई फॉर्म वाले प्रोजेक्ट दोनों पर काम करते हैं। नए उपयोगकर्ता और अनुभवी मेंटेनर दोनों एक रीड-ओनली खोज से शुरुआत कर सकते हैं, क्योंकि इससे कोई फ़ाइल नहीं बदलती और यह दिखाती है कि प्रोजेक्ट कैसे व्यवस्थित है।
अपनी .dpr और .pas फ़ाइलों वाले फ़ोल्डर को चैट के वर्किंग फ़ोल्डर के रूप में चुनें। फ़ाइल टूल्स उसी फ़ोल्डर के भीतर काम करते हैं, इसलिए उसी प्रोजेक्ट को चुनें जिसे आप बदलना चाहते हैं, न कि एक पैरेंट फ़ोल्डर जिसमें असंबंधित कार्य हों। एक पैरेंट फ़ोल्डर जिसमें कई प्रोजेक्ट हों, पहली खोज को पढ़ने में कठिनाई पैदा करता है और गलत यूनिट संपादित करने का जोखिम बढ़ाता है।
एक कार्य को सादे शब्दों में लिखें, जैसे किसी प्रोसीजर का नाम और क्या बदलाव चाहिए, और इसे भेजने से पहले Auto-run, Ask first या Plan only चुनें। छोटे कार्यों से छोटे डिफ़ आते हैं जो पढ़ने में आसान होते हैं। जब यूनिट का पता हो तो उसका नाम बताएं; एजेंट glob से उसे ढूंढ सकता है, लेकिन एक नामित यूनिट पहली खोज को संकीर्ण बनाती है।
edit_file कार्ड को विस्तार से देखें, हर जोड़ी गई और हटाई गई लाइन को पढ़ें, फिर बदलाव को स्वीकार या अस्वीकार करें। यदि आपने Plan only का उपयोग किया है, तो पहले योजना पढ़ें और उसे कदम-दर-कदम पूरा करने के लिए Ask first पर स्विच करें। बहुत लंबा डिफ़ इस बात का संकेत है कि कार्य बहुत बड़ा था, इसलिए उसे अस्वीकार करें और अनुरोध को दो छोटे हिस्सों में बांटें।
Shell को अपना बिल्ड कमांड और टेस्ट कमांड चलाएं, और कार्ड पर असली एग्जिट कोड पढ़ें। पास होने वाला बिल्ड एक अच्छा संकेत है, लेकिन केवल आपके टेस्ट यह बता सकते हैं कि व्यवहार अभी भी सही है या नहीं। टेस्ट से पहले बिल्ड चलाएं, और दोनों कार्ड्स को खुला रखें ताकि कोई विफलता एक बदलाव तक सीमित हो।
.6 प्रविष्टियांGreeter.pasसहेजा गयाGreeter.pasपढ़ा गयाbuild.batएग्जिट 0unit Greeter;
interface
function Greet(const Name: string): string;
implementation
function Greet(const Name: string): string;
begin
if Name = '' then
Result := 'Hello, guest'
else
Result := 'Hello, ' + Name;
end;
end.Greet एक नाम लेता है और एक अभिवादन लौटाता है। जब नाम खाली होता है, तो यह Hello, guest उत्तर देता है, अन्यथा यह नाम को टेक्स्ट से जोड़ता है, और Result फ़ंक्शन के लौटाए गए मान को धारण करता है। इंटरफ़ेस सेक्शन फ़ंक्शन की घोषणा करता है, और इम्प्लीमेंटेशन सेक्शन उसका कोड रखता है, जो हर यूनिट की व्यवस्था है।
नए उपयोगकर्ता जो डेलphi सीख रहे हैं, अक्सर पूछते हैं कि एक मान डिस्क पर कहाँ जाता है। Arraydeck से पूछें कि सेटिंग कहाँ लिखी गई है। एजेंट सेटिंग के नाम के लिए grep चलाता है, फिर read_file मatching यूनिट खोलता है और उत्तर फ़ाइल नामों और लाइनों के साथ चैट में आता है। कुछ नहीं बदलता। यूनिट को अपने एडिटर में खोलें और पुष्टि करें कि प्रोसीजर वही है जिसका आप मतलब था, और एडिट के अनुरोध करने से पहले फ़ाइल का नाम नोट करें। यह रीड-ओनली खोज उन किसी भी प्रोजेक्ट पर एक अच्छा पहला अनुरोध है जिसे आपने स्वयं नहीं लिखा है। किसी भी एडिट के अनुरोध करने से पहले फ़ाइल और लाइन नोट करें, क्योंकि एक सटीक फ़ाइल नाम और लाइन नंबर अगले अनुरोध को छोटा बनाता है और अगला डिफ़ आसान बनाता है कि कोई भी व्यक्ति जो आपके बाद आपके प्रोजेक्ट को पढ़ता है।
एक सुरक्षित हैंडलर के लिए कहें: ऑब्जेक्ट बनाने वाली प्रोसीजर खोजें और सुनिश्चित करें कि उसे रिलीज किया जाए। एजेंट grep से खोज करता है, यूनिट पढ़ता है और edit_file के साथ बदलाव का प्रस्ताव रखता है, कोड को try ... finally ... Free में लपेटता है। Ask first में डिफ़ दिखाई देता है और कुछ नहीं लिखा जाता जब तक कि आप इसे स्वीकार न करें। फिर Shell अपना बिल्ड कमांड चलाता है, और कार्ड असली एग्जिट कोड दिखाता है। अपने टेस्ट भी चलाएं। पास होने वाला बिल्ड केवल सिंटैक्स को साबित करता है, न कि यह कि ऑब्जेक्ट हर पाथ में फ्री किया गया है, इसलिए डिफ़ को धीरे-धीरे पढ़ें। डिफ़ स्वीकार करने के बाद टेस्ट फिर से चलाएं, और पुरानी यूनिट की प्रतिलिपि को अपने बैकअप या वर्जन कंट्रोल में रखें जब तक कि यह सुनिश्चित न हो जाए कि हैंडलर हर शाखा में हर ऑब्जेक्ट को फ्री करता है।
यहाँ बताया गया है कि डेलphi ऐप्स को छोटे कदमों में आधुनिक कैसे बनाएं: एक अस्पष्ट प्रोसीजर का नाम बदलें, एक बार में एक नाम। एजेंट से पूछें कि इसे हर यूनिट में बदलें। यह grep का उपयोग करके हर जगह सूचीबद्ध करता है जहां नाम होता है, फिर edit_file हर फ़ाइल को बदलता है, और डिफ़ हर लाइन को दिखाते हैं जो चलती है। एक बार बदलें। सभी डिफ़ को एक साथ समीक्षा करें, क्योंकि स्ट्रिंग या कमेंट के अंदर एक मिलता-जुलता शब्द हमेशा एक कॉल नहीं होता, फिर प्रोजेक्ट को बिल्ड करें और टेस्ट चलाएं आखिरी फ़ाइल स्वीकार करने से पहले। अगली प्रोसीजर के लिए नाम बदलें केवल तभी दोहराएं जब बिल्ड और टेस्ट पास हो जाएं, ताकि कोई भी गलती हमेशा एक छोटे डिफ़ में बैठे और कई यूनिट्स में असंबंधित बदलावों की लंबी सूची के अंदर छिपे नहीं।
पैसाइन त्रिकोण तर्क एक छोटी यूनिट में समझाया गया एक उचित अभ्यास अनुरोध बनाता है। एजेंट से पूछें कि लूप को पढ़ें और लाइन-दर-लाइन वर्णन करें कि हर पास में हर वेरिएबल क्या धारण करता है। यह read_file कॉल करता है, फिर बिना कुछ लिखे चैट में उत्तर देता है, इसलिए Plan only पर्याप्त है। यूनिट को अपने बिल्ड कमांड के माध्यम से स्वयं चलाकर और 3 या 4 पंक्तियों के लिए कागज पर लूप को फॉलो करके व्याख्या की जांच करें। यदि एजेंट और प्रोग्राम असहमत हैं, तो प्रोग्राम पर भरोसा करें और सटीक लाइन उद्धृत करके सवाल फिर से पूछें। यदि पहला उत्तर मददगार रहा है तो दूसरे लूप के लिए भी वही करें, और जब पैराग्राफ लंबा लगे तो छोटी व्याख्या के लिए पूछें, क्योंकि आप हमेशा उस लाइन पर अधिक विवरण का अनुरोध कर सकते हैं जो आपको भ्रमित करती है।
