2.0 भाग 2 का परिचय: सॉफ़्टवेयर प्रोग्रामिंग
भाग 2 ऐसा सॉफ़्टवेयर लिखने के दैनिक शिल्प के बारे में है जिसे कई लोग लंबे जीवनकाल में पढ़ सकें, बदल सकें, और जिस पर भरोसा कर सकें। भाग 1 ने यह नींव रखी कि टीमें कैसे संगठित होती हैं और निर्णय लेती हैं। यह भाग कोड की ओर ही मुड़ता है: वे परंपराएँ जिनका आप पालन करते हैं, जिस तरह आप डिज़ाइन और इंटरफ़ेस को आकार देते हैं, आप अपने काम को कैसे टेस्ट और समीक्षा करते हैं, आप स्रोत इतिहास को कैसे प्रबंधित करते हैं, और आप चीज़ों को कैसे लिखकर रखते हैं। ये वे प्रथाएँ हैं जो एक ऐसे कोडबेस को अलग करती हैं जो डिलीवरी को तेज़ करता है उससे जो हर परिवर्तन से लड़ता है।
किसी बड़ी टीम में, शिल्प व्यक्तिगत पसंद का मामला नहीं है। यह इस बात का मामला है कि आप समन्वय कैसे करते हैं। जब सैकड़ों या हज़ारों इंजीनियर, ठेकेदार, और उत्तराधिकारी एक ही सिस्टम को छूते हैं, तो साझा परंपराएँ और स्पष्ट अनुबंध ही वह चीज़ हैं जो सबको लगातार टकरावों के बिना समानांतर काम करने देते हैं। याद रखें कि कोड को लिखे जाने से कहीं अधिक बार पढ़ा जाता है, और उस पढ़ाई का अधिकांश हिस्सा वर्षों बाद, ऐसे लोगों द्वारा होता है जिनसे आप कभी नहीं मिलेंगे।
एंटरप्राइज़ और सरकारी परिवेश में दांव और बढ़ जाते हैं। सिस्टम नियमित रूप से अपने लेखकों से एक दशक या उससे अधिक जीवित रहते हैं। विनियमन और ऑडिट को नियंत्रण के दस्तावेज़ीकृत प्रमाण चाहिए। ज्ञान को स्टाफ़ के बदलाव और अनुबंध की सीमाओं के पार स्थानांतरित होना पड़ता है। इसलिए यहाँ के अध्याय गुणवत्ता को वीरता के रूप में नहीं, बल्कि पूरी टीम के काम करने के तरीके के एक इंजीनियर्ड, बड़े पैमाने पर स्वचालित गुण के रूप में लेते हैं।
इस भाग के अध्याय
2.1 कोडिंग मानक और शैली: नामकरण, फ़ॉर्मेटिंग, और मुहावरों के लिए साझा, स्वचालित रूप से लागू की गई परंपराएँ जो कई लेखकों को ऐसे लिखने देती हैं मानो एक सावधान लेखक ने लिखा हो, ताकि समीक्षक अपना ध्यान शैली के बजाय डिज़ाइन पर बिताएँ।
2.2 सॉफ़्टवेयर डिज़ाइन सिद्धांत: SOLID (पाँच ऑब्जेक्ट-ओरिएंटेड डिज़ाइन सिद्धांत), DRY (खुद को न दोहराएँ), कपलिंग और कोहीज़न, और डोमेन-ड्रिवन डिज़ाइन (व्यावसायिक डोमेन की भाषा में सॉफ़्टवेयर का मॉडलिंग) जैसे ह्यूरिस्टिक्स, जिन्हें पालन करने योग्य कानूनों के बजाय प्रयोज्यता के एक डोमेन और ज्ञात विफलता प्रतिरूपों वाले उपकरणों के रूप में लिया जाता है।
2.3 API और इंटरफ़ेस डिज़ाइन: उन अनुबंधों को डिज़ाइन करना जिनके माध्यम से सिस्टम और टीमें मिलती हैं, ताकि स्वतंत्र टीमें उपभोक्ताओं को तोड़े बिना या लॉकस्टेप डिप्लॉयमेंट पर मजबूर किए बिना अपनी आंतरिक चीज़ें बदल सकें।
2.4 टेस्टिंग रणनीति: क्या टेस्ट करना है, किस स्तर पर, और किस भरोसे तक, इसके बारे में जानबूझकर लिए गए निर्णय, जो एक तेज़ और भरोसेमंद सुरक्षा जाल बनाते हैं जो किसी बड़े संगठन को बार-बार और सुरक्षित रूप से डिप्लॉय करने देता है।
2.5 कोड समीक्षा और सहयोग: दोष पकड़ने, ज्ञान फैलाने, मानक लागू करने, और अनुपालन नियंत्रणों को संतुष्ट करने के लिए मर्ज होने से पहले परिवर्तनों की जाँच करना, जबकि समीक्षा को समारोहपूर्ण होने के बजाय तेज़ और रचनात्मक बनाए रखना।
2.6 वर्ज़न कंट्रोल और स्रोत प्रबंधन: हर परिवर्तन के लिए रिकॉर्ड का सिस्टम, और ब्रांचिंग, रिपॉज़िटरी, और कमिट अनुशासन जो मेनलाइन को रिलीज़-योग्य, इतिहास को पठनीय, और ऑडिट ट्रेल को अक्षुण्ण रखता है।
2.7 दस्तावेज़ीकरण: शुरुआती गाइडों से लेकर रनबुक (चरण-दर-चरण परिचालन प्रक्रियाएँ) और निर्णय लॉग तक लिखित ज्ञान, जो प्रमुख-व्यक्ति जोखिम से बचाता है, ऑनबोर्डिंग को तेज़ करता है, और वर्षों तथा अनुबंध की सीमाओं के पार समझ स्थानांतरित करता है।
2.8 सॉफ़्टवेयर आवश्यकताएँ: सॉफ़्टवेयर को क्या और कितनी अच्छी तरह करना चाहिए, यह जानना, निर्दिष्ट करना, वैध ठहराना, और प्रबंधित करना, उस ट्रेसेबिलिटी के साथ जो विनियमित और सरकारी काम की माँग है।
2.9 सॉफ़्टवेयर निर्माण: काम करने वाला सॉफ़्टवेयर बनाने का शिल्प: जटिलता को न्यूनतम करना, सत्यापन और परिवर्तन के लिए निर्माण करना, रक्षात्मक प्रोग्रामिंग, और अनुशासित पुनः-उपयोग।
2.10 सॉफ़्टवेयर कॉन्फ़िगरेशन प्रबंधन: हर कॉन्फ़िगरेशन आइटम (कोई भी कलाकृति जिसके वर्ज़न को ट्रैक और नियंत्रित किया जाना चाहिए) और परिवर्तन की पहचान, नियंत्रण, और ऑडिट करना, ताकि रिलीज़ें पुनरुत्पादनीय हों और ऑडिट ट्रेल अक्षुण्ण रहे।
2.11 सॉफ़्टवेयर गुणवत्ता: गुणवत्ता को टेस्टिंग से व्यापक एक प्रबंधित गुण के रूप में: गुणवत्ता मॉडल, आश्वासन बनाम नियंत्रण, मापन, दोष प्रबंधन, और गुणवत्ता की लागत।
2.12 सॉफ़्टवेयर मॉडल और विधियाँ: कब और कैसे मॉडल करना है, जिसमें संरचनात्मक और व्यावहारिक मॉडल, फॉर्मल मेथड्स (गणितीय रूप से आधारित विनिर्देशन और सत्यापन), प्रोटोटाइपिंग, और एजाइल मेथड्स शामिल हैं, और कब मॉडलिंग अपव्यय है।
2.13 कंप्यूटिंग, गणितीय, और इंजीनियरिंग नींव: प्रथा के नीचे टिके स्थायी बुनियादी सिद्धांत: एल्गोरिद्म और डेटा संरचनाएँ, लॉजिक और प्रायिकता, और अनुभवजन्य इंजीनियरिंग विधि।
2.14 प्रोजेक्ट और रिपॉज़िटरी संरचना: किसी समाधान और उसकी रिपॉज़िटरी को व्यवस्थित करने के लिए सुसंगत परंपराएँ, जिसमें मानक फ़ोल्डर, एक README प्रवेश-बिंदु, और साझा कॉन्फ़िगरेशन शामिल हैं, ताकि कोई भी इंजीनियर किसी भी कोडबेस में नेविगेट कर सके।
2.15 डीबगिंग और समस्या-निवारण: दोषों को खोजना और ठीक करना, अनुमान लगाने और छर्रे जैसे परिवर्तनों के बजाय पुनरुत्पादन, बाइनरी सर्च से अलगाव, परिकल्पनाएँ बनाने और टेस्ट करने, और हर फिक्स को एक रीग्रेशन टेस्ट के रूप में दर्ज करने की एक अनुशासित, सिखाई जा सकने वाली प्रथा के रूप में।
2.16 परफ़ॉर्मेंस इंजीनियरिंग: प्रदर्शन बजट तय करके, अनुकूलन से पहले मापकर और प्रोफ़ाइल करके, एल्गोरिद्मिक लागत और टेल लेटेंसी को समझकर, और रिग्रेशन से बचाव करके, कोड और कंपोनेंट स्तर पर, जानबूझकर सॉफ़्टवेयर को पर्याप्त तेज़ बनाना।
2.17 समवर्तीता और समानांतरता: अपरिवर्तनीयता और संदेश-पासिंग को डिफ़ॉल्ट मानकर सही समवर्ती कोड लिखना, रेस, डेडलॉक, और मेमोरी दृश्यता को समझना, सही सिंक्रोनाइज़ेशन और उच्च-स्तरीय मॉडल चुनना, और अनिश्चयात्मक व्यवहार को जानबूझकर टेस्ट करना।
2.18 निर्भरता और सप्लाई-चेन प्रबंधन: वर्ज़न अनुशासन और लॉकफ़ाइलों, एक स्थिर अपडेट लय, न्यूनतम तथा जाँचे गए निर्भरता फ़ुटप्रिंट, और एक भरोसेमंद सप्लाई चेन के लिए उद्गम तथा एक सॉफ़्टवेयर बिल ऑफ़ मटीरियल्स के ज़रिये किसी आधुनिक सिस्टम का अधिकांश हिस्सा बनाने वाले थर्ड-पार्टी कोड को प्रबंधित करना।
2.19 रीफ़ैक्टरिंग और तकनीकी ऋण: एक भरोसेमंद टेस्ट सूट के पीछे काम कर रहे कोड की आंतरिक डिज़ाइन को सुधारना, कोड स्मेल्स को पहचानना और छोटी नामित रीफ़ैक्टरिंग लागू करना, बड़े परिवर्तन के लिए स्ट्रैंगलर फ़िग का उपयोग करना, और तकनीकी ऋण को नैतिक विफलता के बजाय एक दृश्यमान, फंडेड पोर्टफोलियो के रूप में प्रबंधित करना।
2.20 त्रुटि प्रबंधन और लचीलापन प्रतिरूप: स्पष्ट त्रुटि अनुबंधों, फ़ेल-फ़ास्ट बनाम फ़ेल-सेफ़ विकल्पों, बैकऑफ़ और इडेम्पोटेंस के साथ रीट्राई, सर्किट ब्रेकर और सुरुचिपूर्ण गिरावट के ज़रिये, और किसी त्रुटि को कभी चुपचाप न निगलकर, यह जानबूझकर तय करना कि कोड कैसे विफल होता और उबरता है।
2.21 टाइप सिस्टम और स्टैटिक एनालिसिस: ऐसी स्टैटिक और ग्रेजुअल टाइपिंग के ज़रिये जो अवैध स्थितियों को अप्रस्तुत-योग्य बनाती है, और एडिटर तथा पाइपलाइन में जुड़े लिंटर, टाइप चेकर, और एनालाइज़र के ज़रिये, कोड चलने से पहले दोष की पूरी श्रेणियों को पकड़ना।
ये अध्याय कैसे आपस में जुड़ते हैं
भाग 2 की मूल धारा है पैमाने पर बदलने-योग्यता। यहाँ की हर प्रथा इसलिए मौजूद है ताकि कई लोग एक साझा, दीर्घजीवी सिस्टम को भरोसे के साथ बदल सकें। कोडिंग मानक (2.1) और डिज़ाइन सिद्धांत (2.2) कोड को इस तरह आकार देते हैं कि आप उसे समझ और संशोधित कर सकें। इंटरफ़ेस डिज़ाइन (2.3) वे सीमाएँ खींचता है जो टीमों को अपनी आंतरिक चीज़ें स्वतंत्र रूप से बदलने देती हैं। टेस्टिंग (2.4) वह सुरक्षा जाल प्रदान करती है जो परिवर्तन को सुरक्षित बनाता है। कोड समीक्षा (2.5) वह जगह है जहाँ व्यक्तिगत काम सामूहिक स्वामित्व से मिलता है, और जहाँ मानक वास्तव में लागू किए जाते हैं। वर्ज़न कंट्रोल (2.6) वह नींव है जिस पर समीक्षा, एकीकरण, और ऑडिटिंग सभी टिके होते हैं। और दस्तावेज़ीकरण (2.7) इन सबके पीछे के इरादे को बाद में आने वाले लोगों के लिए संरक्षित रखता है।
ये अध्याय पूरी गाइडबुक को भी फ़ीड करते हैं। यहाँ के इंटरफ़ेस और डिज़ाइन सिद्धांत भाग 3 के सिस्टमों के, विशेष रूप से आर्किटेक्चर बुनियादी सिद्धांत (अध्याय 3.1) के, निर्माण खंड बन जाते हैं। टेस्टिंग रणनीति (2.4) और वर्ज़न कंट्रोल (2.6) अध्याय 8.1 में स्वचालित डिलीवरी पाइपलाइनों के लिए कच्चा माल हैं। दस्तावेज़ीकरण प्रथाएँ (2.7) सीधे संचालन के रनबुक और ऑब्ज़र्वेबिलिटी से जुड़ती हैं, जैसे अध्याय 9.2। और यह पूरा भाग भाग 1 में रखे गए मूल्यों और निर्णय-निर्माण नींव पर निर्मित है, साझा सिद्धांतों को ठोस दैनिक शिल्प में बदलता है।