नीचे से ऊपर प्रोग्रामिंग

जनवरी 1993

(यह निबंध ऑन लिसप के परिचय से है।)

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

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

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

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

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

भाषा को अधिक काम करने के लिए प्रेरित करके, नीचे से ऊपर डिजाइन ऐसे प्रोग्राम देता है जो छोटे और अधिक चुस्त होते हैं। एक छोटा प्रोग्राम को इतने सारे घटकों में विभाजित नहीं करना पड़ता है, और कम घटक का अर्थ है ऐसे प्रोग्राम जो पढ़ने या संशोधित करने में आसान होते हैं। कम घटकों का अर्थ है घटकों के बीच कम कनेक्शन, और इस प्रकार वहां त्रुटियों की संभावना कम होती है। जैसा कि औद्योगिक डिजाइनर किसी मशीन में चलने वाले भागों की संख्या को कम करने का प्रयास करते हैं, अनुभवी लिसप प्रोग्रामर अपने प्रोग्राम के आकार और जटिलता को कम करने के लिए नीचे से ऊपर डिजाइन का उपयोग करते हैं।

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

नीचे से ऊपर डिजाइन प्रोग्राम को पढ़ने में आसान बनाता है।

इस प्रकार का उदाहरण सारांश पाठक से एक सामान्य-उद्देश्य ऑपरेटर को समझने के लिए कहता है; कार्यात्मक सारांश का एक उदाहरण पाठक से एक विशेष-उद्देश्य सबरूटीन को समझने के लिए कहता है। [1]

क्योंकि यह आपको हमेशा अपने कोड में पैटर्न की तलाश में रहने के लिए प्रेरित करता है, नीचे से ऊपर काम करने से आपके प्रोग्राम के डिजाइन के बारे में आपके विचारों को स्पष्ट करने में मदद मिलती है। यदि किसी प्रोग्राम के दो दूर के घटक रूप में समान हैं, तो आपको समानता को नोटिस करने के लिए प्रेरित किया जाएगा और शायद प्रोग्राम को सरल तरीके से फिर से डिज़ाइन करें।

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

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

नया: मुफ्त में ऑन लिसप डाउनलोड करें.

[1] "लेकिन कोई भी आपके सभी नए उपयोगिताओं को समझे बिना प्रोग्राम नहीं पढ़ सकता।" यह देखने के लिए कि ऐसे कथन आमतौर पर गलत क्यों होते हैं, धारा 4.8 देखें।