मानव इतिहास के अधिकांश समय में, हमने कोड समीक्षा के माध्यम से कोड की गुणवत्ता का मूल्यांकन किया है: कोई व्यक्ति आपके लिखे कोड को पढ़ता है और सुनिश्चित करता है कि वह स्वच्छ, विचारपूर्ण, तेज़, समझने योग्य और अच्छी तरह से परीक्षित है। एजेंटों के लिए, यह दृष्टिकोण अच्छी तरह से काम नहीं करता; किसी के लिए भी पढ़ने के लिए बहुत अधिक कोड होता है। परिणामस्वरूप, हमारी अधिक से अधिक गुणवत्ता जाँचें एजेंट के आस-पास के हार्नेस, वातावरण और ऑपरेटिंग सिस्टम में होनी पड़ती हैं। मैं अभी भी कोड पढ़ता और समीक्षा करता हूँ, लेकिन मैं इस बात को लेकर बहुत सजग हूँ कि मैं कहाँ बाधाओं को जाँच के रूप में स्वीकार करने में सहज हूँ।
सॉफ़्टवेयर गुणवत्ता अब आपके एजेंटों के आस-पास निर्धारित की गई बाधाओं पर निर्भर करती है।
गुइलेर्मो की सूची इस बात की अच्छी परीक्षा है कि क्या आप कोड पढ़ना छोड़ने का जोखिम उठा सकते हैं। ध्यान दें कि हर "हाँ" वास्तव में इस बात का कथन है कि दाँव कितने कम हैं - कोई उपयोगकर्ता नहीं, फेंकने योग्य कोड, प्रोटोटाइप। जैसे ही दाँव बढ़ते हैं, किसी को कोड पढ़ना पड़ता है। अगर हर बदलाव पर आप नहीं पढ़ रहे हैं, तो बाधाओं को ही पढ़ना होगा।
बाधाएँ यह परिभाषित करती हैं कि सिस्टम को क्या करने की अनुमति है, एजेंट के प्रस्तावों पर परीक्षण और नियतिवादी (deterministic) बाधाएँ लगाकर। इन बाधाओं को स्थापित करने और बनाए रखने से ही हम ऐसे लूप बनाते हैं जो विश्वसनीय रूप से उच्च-गुणवत्ता वाला प्रोडक्शन सॉफ़्टवेयर देते हैं, तब भी जब एजेंट हर दिन सैकड़ों-हज़ारों या लाखों बदलाव कर रहे हों।
हम इन बाधाओं को क्वालिटी गेट (quality gates) कहते हैं, और ये कई रूप लेती हैं।
इनमें पारंपरिक यूनिट टेस्ट, प्रॉपर्टी टेस्ट और एक्सेप्टेंस टेस्ट शामिल हैं। इनमें म्यूटेशन टेस्टिंग भी शामिल है, जहाँ हम कोड के विभिन्न रूप बनाते हैं, उन्हें उन्हीं परीक्षणों पर चलाते हैं, और सुनिश्चित करते हैं कि लोग ऐसे बग नहीं डाल रहे हैं जिन्हें हम अनदेखा कर रहे हैं। ये कोड गुणवत्ता के मेट्रिक्स हैं, जैसे साइक्लोमैटिक कॉम्प्लेक्सिटी (cyclomatic complexity) और लाइन लंबाई, जो चीज़ों को पठनीय बनाए रखने में मदद करते हैं।
दो लोग इस बात पर असहमत हो सकते हैं कि कोड पढ़ा जाए या नहीं, फिर भी तंत्र पर सहमत हो सकते हैं। गुइलेर्मो इसे पढ़ता है। बॉब इसमें से कुछ भी नहीं पढ़ता। दोनों एक ही चुनौती का वर्णन कर रहे हैं - फर्क केवल इतना है कि क्या उसके अंदर कोई मानव है (मैं बॉब के अन्य विचारों का समर्थन नहीं करता)।
बाधाएँ इस बात में भी महत्वपूर्ण भूमिका निभाती हैं कि सिस्टम कौन से प्रस्तावों को कोड परिवर्तन के रूप में स्वीकार और लागू करेगा। जब तक कोई परिवर्तन प्रस्ताव एजेंट को चलाने वाले इंटरप्रेटर से एजेंट कंट्रोलर और प्रोडक्शन तक पहुँचता है, तब तक हम उस पर पर्याप्त जाँच कर चुके होते हैं ताकि आश्वस्त हो सकें कि इसे शिप करना सुरक्षित है और उसका प्रभाव एजेंट के दायरे के भीतर रहता है।
एक एजेंट कुछ भी प्रस्तावित कर सकता है। आपके द्वारा निर्धारित बाधाएँ तय करती हैं कि कोई प्रस्ताव आपके और आपकी टीम के लिए शिप करने योग्य है या नहीं - वह पर्याप्त सुरक्षित, सही, दायरे में और उपयोगी है या नहीं।
यह मॉडल बहुत कुछ देता है, लेकिन कई चीज़ों को छोड़ भी देता है, और उन कमियों के बारे में सोचना आज महत्वपूर्ण है। एक मुद्दा स्वायत्तता (autonomy) है; एजेंट अपने इरादों को अच्छी तरह लागू कर सकते हैं, लेकिन जानकारी की कमी होने या उनके प्रयास अस्पष्ट होने पर विफल हो सकते हैं। यह कार्य पर भी लागू होता है और इस पर भी कि हार्नेस, वातावरण और अन्य घटक उसे कैसे पैरामीटराइज़ करते हैं।
मनुष्यों के बेहतरीन कोड शिप करने में विफल होने के कई कारण वही हैं जो एजेंटों में हो सकते हैं: कमज़ोर वातावरण जो स्क्रिप्ट-संचालित दबाव में टिक नहीं पाते, गैर-नियतिवादी (nondeterministic) बिल्ड, गायब अनुमतियाँ और कमज़ोर परीक्षण। यह एक बेहतर वातावरण की आवश्यकता को प्रेरित करता है जो एजेंटों को विश्वसनीय फीडबैक दे, कम नुकसान वाले विफलता तरीकों की अनुमति दे, और क्रमिक रूप से सफलता बनाना आसान बनाए।
हम ऐसे वातावरण की तलाश में हैं जहाँ एजेंट वास्तविक काम कर सके, भरोसेमंद फीडबैक पा सके, और ज्यादा नुकसान किए बिना विफल हो सके।
दूसरा महत्वपूर्ण मुद्दा भरोसा है। हम सही होने की जाँच किए बिना आधुनिक एजेंट जितनी स्मार्ट और मजबूत चीज़ को भी आँख बंद करके अपना इरादा नहीं सौंप सकते। हम भरोसे से शुरुआत करते हैं, लेकिन उसे कठिनाई से अर्जित किया जाना चाहिए।
कुछ बाधाएँ काम शुरू होने से पहले उसे आकार देती हैं। अन्य एजेंट के काम करते समय फीडबैक देती हैं। बाकी तय करती हैं कि उसका आउटपुट प्रोडक्शन की सीमा पार कर सकता है या नहीं।
किसी सिस्टम के चारों ओर सत्यापन ढाँचा बनाने के कई तरीके हैं।
मेरे अनुभव में, केवल यूनिट टेस्ट पर निर्भर रहने के बजाय अपनी बाधाओं के लिए व्यापक लेकिन जानबूझकर चुनी गई जाँचों का समूह रखना मददगार होता है। विचार यह है कि प्रत्येक जाँच की एक अलग ज़िम्मेदारी होती है, जो टाइप सुरक्षा और प्रदर्शन से लेकर अंतिम चरण की सुरक्षा स्कैनिंग तक हो सकती है। लोग अपनी खुद की बाधाएँ भी परिभाषित कर सकते हैं, जिनमें आर्किटेक्चर नियम शामिल हैं जिन्हें ESLint जैसे लिंटिंग टूल लागू कर सकते हैं। ऐसे कई टूल में अंतर्निहित हुक होते हैं जिनका उपयोग चीज़ों के टूटने पर एजेंटों या मनुष्यों को शामिल करने के लिए किया जा सकता है।
फिलहाल, उपयोगी एजेंट आउटपुट और घटिया आउटपुट के बीच का अंतर काफी हद तक लूप को संचालित करने वाली टीम के कौशल पर निर्भर करता है।
AI हमें उच्च मात्रा में कोड निर्माण और गति देता है, लेकिन इसका मतलब यह भी हो सकता है कि मनुष्यों के लिए हर बदलाव की समीक्षा करना कठिन हो जाता है। आपको इसके बजाय इस बात पर जानबूझकर ध्यान देना होगा कि उनका ध्यान कहाँ जा रहा है। अगर आप किसी ऐसी प्रणाली में मानवीय जाँच डालते हैं जो अन्यथा मशीन की गति से चलती है, तो आश्चर्य न करें कि इससे उत्पादकता प्रभावित होती है। मानवीय ध्यान दुर्लभ और मूल्यवान है, इसलिए हमें इसे सक्रिय रूप से उन सबसे जटिल समस्याओं की ओर निर्देशित करना चाहिए जिनमें हमारे निर्णय की आवश्यकता होती है। आगे की प्रक्रिया में मनुष्यों को तभी शामिल किया जाना चाहिए जब बाधाओं के स्वचालित सुरक्षा उपाय (guardrails) विफल हो जाएँ।
भविष्य में मानव "कोड समीक्षा" बहुत अलग दिखेगी
सही होना एक महत्वपूर्ण आयाम है, लेकिन आप अन्य चीज़ों की भी परवाह कर सकते हैं, जैसे रखरखाव योग्यता, प्रदर्शन, सुरक्षा, दक्षता और समझने में आसानी। जिस तरह सही होना कई प्रकार के संकेतों में विभाजित होता है, उसी तरह बाकी गुणवत्ता भी। और जहाँ यह मायने रखता है कि हमारे पास कितनी बाधाएँ हैं, वहीं यह अधिक मायने रखता है कि क्या वे गुणवत्ता और उत्पादन तत्परता के हमारे स्तर को पूरा करने के लिए पर्याप्त चुनौतीपूर्ण हैं।
सॉफ़्टवेयर गुणवत्ता एक एकल मीट्रिक नहीं है। इसे आपके और आपकी टीम के लिए अलग-अलग महत्व वाले संकेतों के संग्रह के रूप में सोचें।
बैक-प्रेशर (back-pressure) को कई उपकरणों के माध्यम से लागू किया जा सकता है: कंपाइलर अमान्य कोड को अस्वीकार करते हैं, परीक्षण विफल होते हैं, सुरक्षा नीतियाँ खराब प्रथाओं को रोकती हैं, CI डिप्लॉय करने से इनकार करता है। आदर्श रूप में यह पूरे लूप में मौजूद होना चाहिए, न कि सभी काम के बिल्कुल अंत में एक अकेली समीक्षा के रूप में।
डेक्स होर्थी का उसी लूप का नक्शा, Why Software Factories Fail से। हरा बॉक्स उसका तर्क है कि फिलहाल मानवीय समीक्षा को लूप में वापस रहना चाहिए, न कि उसके द्वारा प्रतिस्थापित किया जाना चाहिए।
बाधाएँ और बैक-प्रेशर एजेंटों को खराब काम को समस्या बनने से पहले पकड़ने देते हैं
क्या होता है अगर हम बाधा लागू नहीं कर सकते क्योंकि बदलावों की मात्रा हमारे उपकरणों की क्षमता से अधिक है? हम अंततः एक कतार बनाते हैं और ऐसी सत्यापन प्रणाली पर निर्भर हो जाते हैं जो मानव गति से चलती है। स्केल करने के लिए, हम जितना संभव हो उतना सत्यापन लूप में पूरे समय धकेलना चाहते हैं, न कि अंत तक इंतज़ार करना चाहते हैं। अगर हम अपने स्वचालित जाँचों में स्केल कर सकते हैं, तो हम अपने संपूर्ण डिलीवरी सिस्टम की गति और थ्रूपुट बढ़ा सकते हैं। अगर सत्यापन लूप में जगह खत्म हो जाती है, तो हमें कई चीज़ों में से एक करने की आवश्यकता होती है।
पहला, हम अपने सत्यापन सिस्टम को स्केल कर सकते हैं और आने वाले बदलावों पर रोक और दबाव बनाने की अधिक क्षमता बना सकते हैं। दूसरा, हम एजेंटों द्वारा नए बदलाव उत्पन्न करने की दर को कम कर सकते हैं ताकि सत्यापन काम की मात्रा के साथ तालमेल बिठा सके। तीसरा, हम अपने गुणवत्ता स्तर को कम कर सकते हैं ताकि सत्यापन उतना सख्ती से दबाव न बनाए जितना अन्यथा बना सकता है। स्केलिंग के दृष्टिकोण से, हमें इन सभी चीज़ों के लिए तैयार रहने की आवश्यकता है। साथ ही, हमें यह समझने से नहीं चूकना चाहिए कि हम कुछ दिशाओं में बाधाएँ हटाकर वास्तव में अधिक काम कर सकते हैं। शायद हम एजेंट डेवलपर्स के समूह या स्वचालित सॉफ़्टवेयर फैक्ट्रियों का उपयोग करके एजेंट-जनित बदलावों की गति बढ़ा सकते हैं, बिना हमारे प्रत्येक की समीक्षा करने की प्रतीक्षा किए।
और कुछ जगहों पर हम उन्हें अधिक स्वतंत्रता देना चाह सकते हैं, बशर्ते हम अन्य जगहों पर सख्त बाधाएँ बनाए रखें। जहाँ हम सबसे अधिक परवाह करते हैं वहाँ सख्त बाधाएँ प्रदान करके, हम गुणवत्ता से समझौता किए बिना अपना थ्रूपुट अधिकतम कर सकते हैं। इन निर्णयों में कई विकल्प हैं। सबसे स्पष्ट रूप से, हमें गुणवत्ता के विभिन्न आयामों के बीच समझौता करना होता है। जैसा कि हमने जोर दिया है, सुरक्षा बहुत महत्वपूर्ण है, लेकिन हमें सुरक्षा देने और समय पर उत्पाद देने के बीच भी समझौता करना पड़ा है। एक सिरे पर नवाचार-केंद्रित से लेकर दूसरे सिरे पर गुणवत्ता-केंद्रित तक का एक स्पेक्ट्रम है। रास्ते में कहीं न कहीं, हमें चुनाव करना होगा कि हम उस स्पेक्ट्रम पर कहाँ रहना चाहते हैं।
हम वातावरण और सिस्टम से स्पष्ट फीडबैक अपने एजेंटों या टीमों तक भेजना चाहते हैं, ताकि लोग रुचि, इरादे और आर्किटेक्चर जैसी अधिक व्यक्तिपरक चिंताओं पर ध्यान केंद्रित कर सकें। अगर हम मनुष्यों को बाधाओं की सुरक्षित सीमा के भीतर रहने में मदद कर सकते हैं, तो हम उन्हें यह समझने की कोशिश में कड़ी मेहनत करने की आवश्यकता से बच सकते हैं कि चीज़ें कहाँ गलत हुईं।
सॉफ़्टवेयर गुणवत्ता में केवल सही होना ही शामिल नहीं है। सॉफ़्टवेयर गुणवत्ता का अर्थ रखरखाव योग्यता, अच्छा प्रदर्शन, सुरक्षा, दक्षता और समझने में आसानी भी है। ये सभी बाधाएँ जो हमें इन मानकों को पूरा करने और हमारे उत्पादन को प्रवाहित रखने में मदद करती हैं, हमारी डिलीवरी पाइपलाइन में बैक-प्रेशर बनाती हैं।
हमें जानबूझकर निर्णय लेने की आवश्यकता है कि कहाँ मजबूत बाधाएँ लागू करनी हैं और कहाँ उन्हें हटाना या ढीला करना है। मजबूत बाधाएँ वहाँ लागू करें जहाँ वे इन दोनों लक्ष्यों को पूरा कर रही हों। अगर वे एक या दोनों को पूरा नहीं कर रही हैं, तो उन्हें समर्थन न दें। मामले की आवश्यकता के अनुसार मानकों को बढ़ाने या घटाने के लिए तैयार रहें। और याद रखें कि सॉफ़्टवेयर सिस्टम में विभिन्न बिंदुओं पर ये बाधाएँ ही सॉफ़्टवेयर गुणवत्ता को लागू करने योग्य बनाती हैं।
हमें मजबूत बाधाएँ वहाँ लागू करनी चाहिए जहाँ वे इस दोहरे उद्देश्य को सबसे अच्छा पूरा करेंगी, और उन बाधाओं को हटाने या ढीला करने पर विचार करना चाहिए जो किसी भी उद्देश्य को अच्छी तरह पूरा नहीं कर रही हैं। हमें आवश्यकता अनुसार गुणवत्ता के स्तर को ऊपर या नीचे करने के लिए भी तैयार रहना चाहिए। वास्तव में, हमारे सॉफ़्टवेयर सिस्टम में विभिन्न बिंदुओं पर ये बाधाएँ ही गुणवत्ता को दाँत देती हैं। कई मामलों में, हम नए उपकरण तैनात करके या पहले से मौजूद उपकरणों को मजबूत करके अधिक बैक-प्रेशर और अधिक बाधाएँ बना सकते हैं। इन सभी चीज़ों का उपयोग अधिकांश परिवर्तन अनुरोधों पर दबाव बनाने के लिए किया जा सकता है। हम उन्हें पूरी पाइपलाइन में बनाना चाहते हैं।
हम पाइपलाइन के अंत तक इंतज़ार नहीं करना चाहते, जब हमारा CI सिस्टम बस हमें बताएगा कि समस्याओं को ठीक किए बिना डिप्लॉय करने की अनुमति नहीं है। हम इन संकेतों का उपयोग यथासंभव जल्दी, हर संभव माध्यम से करना चाहते हैं। इस सिस्टम में सबसे बड़ी बाधा वह है जो हम खुद पर लगाते हैं - सिस्टम को बनाने और संचालित करने के लिए उठाए गए निर्णयों और कार्यों के पीछे खड़े होने की। लेकिन अन्य सभी बाधाओं की तरह, हमें इस बारे में विचारपूर्ण समझौते करने की आवश्यकता है कि हम अपने निर्णय को कितना नियंत्रित करने दें, कितना दबाव बनाने दें, और कितना अंतिम जाँच के रूप में कार्य करने दें।
गुणवत्ता उन बाधाओं में है जो हम अपने एजेंटों के आस-पास रखते हैं। इसलिए जब आप अपने ऐप्स के लिए गुणवत्ता के बारे में सोच रहे हों, तो इस समस्या विवरण को लें और अपनी खुद की बाधा-संचालित योजना बनाएँ।
गुणवत्ता की बात करें तो, एजेंट आपका कोड लिख रहे हैं। [Sonar](https://fandf.co/45bRKE8) आपको इसे शिप करने योग्य बनाने के लिए क्वालिटी गेट देता है। यह हर कमिट पर वही पूर्ण जाँच चलाता है: गहन क्रॉस-फ़ाइल विश्लेषण, जोखिम कहाँ है इसका नक्शा, और एक क्वालिटी गेट जो हर मानव और एजेंट को एक ही स्तर पर रखता है।
यह लेख 100% मानव लिखित को Pangram 4 द्वारा दर्जा दिया गया।
