REA बदल रहा है कि सॉफ़्टवेयर विकास कहाँ से शुरू हो सकता है

उपयोगकर्ता का सवाल निर्माण की इकाई बनता है

REA बाइनरी, JavaScript और Electron जैसे लक्ष्यों के विश्लेषण को MCP और कमांड लाइन से जोड़ता है। एजेंट फ़ंक्शन, संदर्भ और कोड की जगहों के आधार पर आगे जाँच या निर्माण करता है। आधिकारिक रिपॉज़िटरी यही भूमिका बताती है; पूरे ऐप का मूल स्रोत अपने आप वापस पाने का वादा नहीं करती।

सवाल का आकार मायने रखता है। “ऐसा ही पूरा ऐप बनाओ” के बजाय “फ़ाइल सहेजते समय क्या बचता है और दोबारा खोलने पर कैसे लौटता है” स्पष्ट जाँच तय करता है। इनपुट और नतीजे साफ़ हों तो अपेक्षित व्यवहार और नई रचना की तुलना हो सकती है। पसंद एक जाँचने योग्य शर्त बन जाती है।

नया कोड लिखना और अपरिचित प्रोग्राम समझना अलग कौशल रहे हैं। दोनों के बीच काम करने वाला एजेंट छोटी अनुकूलता सुविधा या निजी औज़ार बनाने की बाधा घटा सकता है। यह प्रकाशित कार्यप्रणाली से निकला अनुमान है, हर परियोजना की लागत घटने का मापा हुआ परिणाम नहीं।

छोटी सफलता को विश्वसनीय क्या बनाता है

REA का DX-Ball उदाहरण ध्वनि की बाएँ-दाएँ स्थिति निकालने वाले एक फ़ंक्शन को C में फिर बनाता है। रिकॉर्ड में 3,205 परिस्थितियों के नतीजे और दोबारा कंपाइल किए गए 63 बाइट मेल खाते हैं। ये प्रमाण उस फ़ंक्शन के हैं, पूरे गेम के तैयार होने के नहीं।

Notion Desktop 7.6.1 का उदाहरण कॉपी अनुरोध को preload और प्रक्रियाओं के बीच संदेशों से सिस्टम क्लिपबोर्ड तक खोजता है। प्रमाण पैकेज के कोड और निकाले गए मॉड्यूल के परीक्षण हैं। यह पूरे डेस्कटॉप सत्र का निरीक्षण या पूरी सेवा का पुनर्निर्माण नहीं है।

Touhou 4 में भी योगदान की सीमा स्पष्ट है। REA, DOS प्रोग्राम में गोलियों की दिशा की गणना जाँचता है। सँभाला गया C++ कोड और 2,139 कंपाइल किए गए बाइट का मिलान पहले से मौजूद पुनर्निर्माण परियोजना से आता है। REA उस संचित काम में जाँच का नया रास्ता जोड़ता है।

तीनों उदाहरण बताते हैं कि क्या मिला और किससे उसकी तुलना हुई। मुझे यह चमकदार प्रदर्शन से अधिक टिकाऊ उपलब्धि लगती है। दूसरा व्यक्ति उसी दायरे को फिर जाँच सके, तो एक बार की सफलता आगे के काम के लिए भरोसेमंद ज्ञान बनती है।

अपनी ज़रूरत का एक हिस्सा वापस पाने वाले लोग

9 अक्टूबर को Kintu gk ने Codex और REA से Sony हेडफ़ोन में हवा का शोर घटाने की सुविधा चालू करने वाला Android ऐप बनाने का अनुभव लिखा। अटके विश्लेषण में सार्वजनिक प्रोटोकॉल संदर्भ काम आए; सेटिंग डिवाइस से वापस पढ़कर जाँची गई। यह उनका विवरण है, इस लेख में स्वतंत्र रूप से दोहराया गया परीक्षण नहीं।

UPMI Lab की Princess Maker 2 परियोजना भी खास उपयोग से शुरू हुई। मूल गेम का संचालन बनाए रखते हुए दृश्य और नियंत्रण बदलकर iPad mini पर लगाने की कहानी अलग लेख में है। REA विश्लेषण के बाद चित्र बनाना और जोड़ना, ऐप संशोधन, बिल्ड, हस्ताक्षर और स्थापना Codex Work के कार्यक्षेत्र में हुए। उस अपनी परियोजना का संचालक UPMI Lab है।

दोनों अनुभवों में उद्देश्य किसी बड़ी कंपनी के पूरे उत्पाद को बदलना नहीं था। बार-बार किए जाने वाले काम को आसान करना या पुराने अनुभव को वर्तमान डिवाइस पर लाना था। ऐसी छोटी माँग व्यावसायिक योजना की प्राथमिकता न बने। निर्माण में उपयोगकर्ता की भागीदारी बढ़ने का अर्थ है इन्हीं ज़रूरतों को पूरा करने वाले लोग बढ़ना।

तेज़ विकास के साथ जाँच की ज़िम्मेदारी स्पष्ट होती है

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

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

स्थानीय विश्लेषण सभी डेटा के आवागमन का पूरा वर्णन नहीं है। REA के FAQ के अनुसार एजेंट को मिले नतीजों पर उसके मॉडल प्रदाता की डेटा नीति लागू होती है। संगठन को तय करना होगा कि लक्ष्य और नतीजों में कौन-सी जानकारी है। सुविधा समझना और मूल कोड या चित्र बाँटने का आधार स्थापित करना भी अलग काम हैं।

सॉफ़्टवेयर कंपनी का मूल्य अधिक ठोस होता है

इसे सॉफ़्टवेयर कंपनियों का अंत मानना जल्दबाज़ी होगी। उपयोगकर्ता सुविधाओं के साथ पुरानी फ़ाइलों की अनुकूलता, गड़बड़ी पर सहायता और सहकर्मियों से जुड़ाव भी खरीदता है। समान सुविधा जल्दी बन जाए, तब भी संचित काम को बिना नुकसान आगे ले जाने की ज़िम्मेदारी रहती है।

दूसरी ओर, किसी एक सुविधा की नकल करना कठिन होना शायद लंबे समय का लाभ न रहे। मुझे उपयोगी प्रतिक्रिया के रूप में प्रलेखित इंटरफ़ेस, भरोसेमंद निर्यात, स्वचालन और परीक्षण प्रमाण में निवेश दिखता है। ग्राहक अपना काम बढ़ा सके, तो उत्पाद को चुनते रहने का कारण भी अधिक स्पष्ट होता है।

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

अगली परियोजना अधिक सटीक ज़रूरत से शुरू होती है

पहले REA काम के लिए उपयोग का अधिकार रखने वाला एक लक्ष्य और एक कठिन व्यवहार चुनना व्यावहारिक है। मूल सुरक्षित रखें, छोटा नया रूप बनाएँ और दोनों को एक ही इनपुट से जाँचें। अंतर मिले तो जाँच पर लौटने के लिए प्रमाण और परीक्षण सामग्री साथ रखें। औज़ार बदल जाएँ तब भी अगला डेवलपर इस चक्र को जारी रख सकता है।

मैं REA का प्रभाव केवल दोबारा बनाए गए प्रोग्राम के आकार से नहीं आँकना चाहूँगा। बड़ा बदलाव यह है कि अधिक लोग अपनी समस्या को जाँच योग्य सवाल और उसके उत्तर को चलने वाले परिणाम में बदल सकें। सॉफ़्टवेयर विकास का अगला अध्याय तेज़ कोड लेखन और यह समझाने की क्षमता, कि कोड वांछित काम करता रहता है, दोनों मिलकर लिखेंगे।