कभी ऐसा होता है कि लाइब्रेरी के किसी फ़ंक्शन से लौटने वाले मानों का क्रम या त्रुटि संदेश के शब्द ज़रा से बदले जाते हैं, और किसी दूर की सेवा के अचानक काम करना बंद कर देने की सूचना आ जाती है। दस्तावेज़ में उन बारीकियों की कभी गारंटी नहीं दी गई थी, फिर भी कोई उस व्यवहार पर निर्भर था। इसी वास्तविकता को एक पंक्ति में समेटने वाला अवलोकन है ‘हाइरम का नियम (Hyrum's Law)’।
सरल शब्दों में, हाइरम का नियम सॉफ़्टवेयर इंजीनियरिंग का एक अनुभवजन्य नियम है: ‘जब किसी इंटरफ़ेस का उपयोग करने वालों की संख्या पर्याप्त हो जाती है, तो दस्तावेज़ में क्या वादा किया गया है, यह मायने नहीं रखता; सिस्टम के हर अवलोकन योग्य व्यवहार पर कोई न कोई निर्भर हो जाता है।’ Google में बड़े पैमाने पर कोड में बदलावों का काम संभालने वाले हाइरम राइट (Hyrum Wright) के इस अवलोकन को उनके सहकर्मी टाइटस विंटर्स (Titus Winters) ने ‘हाइरम का नियम’ नाम देकर प्रचलित किया।
इस सामग्री में हम क्रम से हाइरम के नियम का सटीक अर्थ और उसकी उत्पत्ति, निहित इंटरफ़ेस बनने की प्रक्रिया, विकास कार्य में अक्सर दिखने वाले उदाहरण, और उससे निपटने के तरीकों तथा उनकी सीमाओं पर चर्चा करेंगे।
दस्तावेज़ से गहरा अनुबंध: हाइरम का नियम
हाइरम का नियम क्या है?
इस नियम को आम तौर पर इस तरह लिखा जाता है: यदि किसी एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (API) के उपयोगकर्ता पर्याप्त संख्या में हों, तो अनुबंध में चाहे जो लिखा हो, सिस्टम के हर अवलोकन योग्य व्यवहार पर कोई न कोई निर्भर होगा। राइट ने अपने लेख में इस अवलोकन को ‘हाइरम का नियम’ नाम देने और व्यापक रूप से प्रचलित करने का श्रेय विंटर्स को दिया है।
इसी आशय में ‘निहित इंटरफ़ेस का नियम (Law of Implicit Interfaces)’ शब्द भी इस्तेमाल होता है। इसका अर्थ है कि उपयोगकर्ताओं की संख्या बढ़ने पर कार्यान्वयन की वे बारीकियाँ भी व्यवहार में अनुबंध बन जाती हैं जिन्हें निजी माना गया था, और अंततः कार्यान्वयन में मामूली बदलाव पर भी ‘बग-दर-बग संगतता (bug-for-bug compatibility)’ बनाए रखने की माँग होने लगती है।
- स्पष्ट अनुबंध (Explicit Contract): दस्तावेज़ और विनिर्देशों में दर्ज इनपुट, आउटपुट और त्रुटि की शर्तें।
- निहित इंटरफ़ेस (Implicit Interface): वह व्यवहार जिसे लोग बार-बार देखकर उसकी अपेक्षा करने लगते हैं, भले ही वह दस्तावेज़ में दर्ज न हो।
- अवलोकन योग्य व्यवहार (Observable Behavior): प्रतिक्रिया का क्रम, विलंब अवधि, त्रुटि संदेश के शब्द और लॉग का प्रारूप जैसे वे सभी परिणाम जिन्हें बाहर से देखा जा सकता है।
निहित इंटरफ़ेस कैसे बनता है
हाइरम का नियम डेवलपरों के आलस्य से पैदा नहीं होता; यह ऐसा प्रभाव है जो पैमाना बढ़ने पर लगभग अनिवार्य रूप से सामने आता है। कारण यह है कि अमूर्तन के ज़रिए अंदरूनी हिस्से छिपा देने का विश्वास होने पर भी बाहर से कई संकेत देखे जा सकते हैं।
(1) उपयोगकर्ता दस्तावेज़ से ज़्यादा व्यवहार देखते हैं
समय की तंगी में अक्सर विनिर्देश की हर पंक्ति से मिलान करने के बजाय पहले यह देखा जाता है कि सिस्टम कल की तरह काम कर रहा है या नहीं। इस तरह संयोग से स्थिर दिखने वाली बारीकियाँ ‘स्वाभाविक वादे’ जैसी स्थापित हो जाती हैं।
(2) निर्भरताएँ अलग-अलग होती हैं, लेकिन मिलकर पूरे कार्यान्वयन को घेर लेती हैं
कोई टीम क्रमबद्धता पर निर्भर करती है, दूसरी त्रुटि कोड की स्ट्रिंग पर, और कोई अन्य औसत प्रतिक्रिया समय पर। उपयोगकर्ताओं की संख्या बढ़ने पर इन निर्भरताओं का कुल दायरा कार्यान्वयन के लगभग हर पहलू तक पहुँच जाता है।
(3) इसका संबंध जोएल स्पोल्स्की के रिसावयुक्त अमूर्तन से है
जोएल स्पोल्स्की (Joel Spolsky) का ‘रिसावयुक्त अमूर्तन का नियम (Law of Leaky Abstractions)’ कहता है कि अमूर्तन अंदरूनी परिस्थितियों को पूरी तरह छिपा नहीं सकता। हाइरम का नियम इसमें यह जोड़ता है कि उपयोगकर्ता अधिक होने पर बाहर झलकने वाले वे संकेत भी अनुबंध की तरह स्थापित हो जाते हैं।
विकास कार्य में मिलने वाले उदाहरण
यह सुनने में सैद्धांतिक लग सकता है, लेकिन लाइब्रेरी और सेवाओं के रोज़मर्रा के काम में भी यही ढर्रा दोहराया जाता है। ‘विनिर्देश के दायरे से बाहर’ माना गया बदलाव अक्सर सबसे दूर के सिस्टम को प्रभावित करता है।
(1) लौटाई गई सूची का क्रम
दस्तावेज़ में ‘क्रम की गारंटी नहीं है’ लिखा होने पर भी, यदि अब तक परिणाम हमेशा एक ही क्रम में आए हों, तो उस क्रम के अनुरूप लिखा गया कोड बढ़ता जाता है। किसी दिन समानांतर प्रसंस्करण लागू करने से क्रम बदल जाए, तो परीक्षणों में शामिल न की गई धारणाएँ एक साथ सामने आ जाती हैं।
(2) त्रुटि संदेश और लॉग के शब्द
कभी मनुष्यों के पढ़ने के लिए लिखे गए वाक्य को कोई दूसरा प्रोग्राम स्ट्रिंग के रूप में पार्स करके उसके आधार पर अलग-अलग कार्रवाई करता है। वाक्य को बस अधिक सहज बनाया गया हो और स्वचालन रुक जाए, तो वह इसी तरह का मामला है।
(3) प्रदर्शन और समय-निर्धारण
विनिर्देश में विलंब अवधि की गारंटी न होने पर भी, वर्षों से लगभग समान रही गति व्यवहार में अपेक्षित मानक बन जाती है। कैश हटाने या जाँच के चरण बढ़ाने से गति थोड़ी धीमी हो जाए, तो ‘कार्य वही है, लेकिन हमारे यहाँ ही टाइमआउट हो रहा है’ जैसी शिकायतें आने लगती हैं।
हाइरम के नियम से निपटने के तरीके और सीमाएँ
इस नियम का अर्थ बदलाव छोड़ देना नहीं है। बल्कि यह इस चेतावनी के अधिक करीब है कि अवलोकन योग्य पहलू अनुबंध बन सकते हैं, इसलिए बदलाव की गुंजाइश जानबूझकर बचाकर रखनी चाहिए।
- अनुबंध की स्पष्टता (Clear Contract): दस्तावेज़ और परीक्षणों के ज़रिए साफ़ अंतर करें कि किन बातों की गारंटी है और किनकी नहीं।
- जानबूझकर उतार-चढ़ाव (Intentional Jitter): शुरू से ही क्रम बदलते रहें या विलंब में थोड़ा उतार-चढ़ाव रखें, ताकि संयोग पर आधारित धारणाएँ पनप न सकें।
- संगतता परीक्षण (Compatibility Testing): बड़े पैमाने पर बदलाव से पहले वास्तविक कॉल पैटर्न को व्यापक रूप से चलाकर पहले ही पता लगाएँ कि कहाँ काम बिगड़ता है।
हालाँकि, उपयोगकर्ताओं की संख्या बहुत अधिक होने पर कोई भी छोटा संशोधन किसी न किसी का काम बिगाड़ सकता है। ‘Software Engineering at Google’ में भी इस नियम को एंट्रॉपी की तरह ऐसी सीमा माना गया है जिसे मिटाया नहीं जा सकता, लेकिन डिज़ाइन और रखरखाव में हमेशा ध्यान में रखना चाहिए। दूसरी ओर, इस नियम का बहाना बनाकर आवश्यक सुधारों को अनिश्चित काल तक टालते रहने की प्रवृत्ति से भी बचना चाहिए।
हाइरम का नियम हमें इस वास्तविकता की याद दिलाता है कि लोकप्रिय सिस्टम का असली इंटरफ़ेस दस्तावेज़ में लिखी बातों से कहीं अधिक गहरा होता है। Google में बड़े पैमाने पर लाइब्रेरी में बदलाव करने के अनुभव से जन्मा यह अवलोकन आज API और प्लेटफ़ॉर्म को लंबे समय तक बनाए रखने वाली टीमों की साझा भाषा बन गया है।
किसी छोटे व्यवहार को बदलने से पहले एक बार फिर यह सोचना कि ‘दस्तावेज़ में न होने पर भी क्या कोई पहले से इसे देख और इस्तेमाल कर रहा होगा’, ऐसे बदलावों को डिज़ाइन करने के लिए हाइरम के नियम के उपयोग की पहली सीढ़ी है जिनसे मौजूदा कामकाज न बिगड़े।
