यूनिक्स के तहत प्रोग्रामिंग की कला (और न केवल)। भाग एक, "प्रतिरूपकता का नियम"

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



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



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



एरिक रेमंड इस "दर्शन" के 17 नियमों की रूपरेखा देता है। मैं प्रत्येक नियम के लिए एक नोट समर्पित करूंगा। मैं इन अवधारणाओं को यथासंभव समझने, सरल और लोकप्रिय रूप में प्रस्तुत करने की कोशिश करूंगा।



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



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



वास्तविक जीवन से दो उदाहरण: 1) सिस्टम यूनिट से एक क्लासिक होम पीसी और मॉनिटर 2) एक लैपटॉप। उदाहरण के लिए, दोनों स्क्रीन पर खाली गया। कारण कुछ भी हो सकता है, जैसा कि हम इसे समझते हैं। लेकिन एक घर पीसी के मामले में, पहली धारणा की जांच करना आसान है: क्या मॉनिटर दूसरे कंप्यूटर पर काम करता है? यदि यह काम नहीं करता है, तो इसका कारण मॉनिटर है। यदि हां, तो इसका कारण कंप्यूटर में है। अगला, आप दूसरे कंप्यूटर पर वीडियो कार्ड आज़मा सकते हैं - और तुरंत समझ सकते हैं कि यह मामला है या नहीं। स्थिति एक कीबोर्ड, एक माउस के समान है ...



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



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



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



उदाहरण के लिए, सादगी की अनुमति देता है, उदाहरण के लिए, घटक को एक परीक्षण वातावरण में रखना जहां सभी उपयोग के मामलों का अनुकरण किया जाएगा और जहां यह जांचा जाएगा कि गणना किए गए परिणाम अपेक्षित परिणाम से मेल खाते हैं या नहीं। उदाहरण के लिए, फिर से, हमारे अभ्यास से एक उदाहरण - प्रसव के समय की गणना करते समय, एक तालिका विकसित की गई थी जहां प्रत्येक परीक्षण मामले के लिए डिलीवरी का समय मैन्युअल रूप से गणना किया गया था, और फिर, किसी भी परिवर्तन के साथ, परीक्षणों में विचलन या उनकी अनुपस्थिति दिखाई दी।



एक बार, कॉलेज के बाद, मैंने रियाज़ान इकोवेंट कंपनी के लिए डक्ट डिज़ाइन सिस्टम लिखा । वहाँ एक व्यक्ति वायु नलिकाओं का एक मनमाना मॉडल बना सकता है - तीनों आयामों में शाखाओं के साथ पाइप। कुछ बिंदु पर, मुझे पूरे सॉफ़्टवेयर भाग को पूरी तरह से फिर से करना पड़ा, क्योंकि यह अभी बहुत जटिल हो गया था। डिजाइन परिवर्तन के लिए जिम्मेदार व्यक्तिगत घटक - जैसे, उदाहरण के लिए, एक तत्व को जोड़ना, पाठ के रूप में एक टेक्स्ट इंटरफ़ेस था, "ब्लॉक चौड़ाई = 100 ऊंचाई = 100 गहराई = 10 जोड़ें"। बेशक, किसी ने उपयोगकर्ता को इस तरह के कमांड टाइप करने के लिए मजबूर नहीं किया था, इसके लिए एक अलग ग्राफिकल विंडो इंटरफ़ेस था जहां उसने चौड़ाई, ऊंचाई, गहराई दर्ज की, लेकिन फिर भी फॉर्म को कमांड में बदल दिया गया। इससे उन जटिल परिस्थितियों को डीबग करना बहुत आसान हो गया, जहाँ आपको सैकड़ों ऑब्जेक्ट बनाने और उन्हें आकर्षित करने की आवश्यकता थी।



UNIX दुनिया में, कमांड लाइन के लिए एक एकीकृत इंटरफ़ेस लंबे समय से आविष्कार किया गया है, इसे "पाइप" (पाइप; |) कहा जाता है। चैनलों के माध्यम से, आप बहुत आसानी से विभिन्न कार्यक्रमों को जोड़ सकते हैं जो एक, बहुत सरल कार्य करते हैं। उदाहरण के लिए, एक उपयोगिता है जो लाइनों, वर्णों (wc) की संख्या और एक फ़ाइल (कैट) की सामग्री को प्रदर्शित करने वाली उपयोगिता को गिनाती है। उन्हें एक के बाद एक रखकर, हम प्राप्त कर सकते हैं, उदाहरण के लिए, फ़ाइल में पंक्तियों की संख्या (बिल्ली फ़ाइल | wc -l)। और ऐसी "उपयोगिताओं" को पहले से ही बहुत विकसित किया गया है। उन्हें "फ्लाई पर" संयोजित करने की क्षमता वस्तुतः सेकंड में काफी जटिल कार्यों को हल करने में मदद करती है।



अंत में, कुछ सरल युक्तियाँ प्रतिरूपता नियम के मेरे परिणाम हैं:

• प्रत्येक ब्लॉक, प्रोग्राम, मॉड्यूल को केवल एक काम करना चाहिए और इसे अच्छी तरह से करना चाहिए। यदि लक्ष्य, ब्लॉक का उद्देश्य "स्मियर" होना शुरू हो जाता है, तो यह भागों में इसके विभाजन के बारे में सोचने योग्य है।
• यदि संभव हो, तो उद्योग मानकों (XML, HTTP, RPC, CSV, JSON) में से इंटरफेस चुनें और किसी भी स्थिति में उनके पार न जाएं।
• यदि आप ब्लॉक की संख्या बढ़ाकर इंटरफ़ेस को सरल बना सकते हैं - सरल करें। अधिक ब्लॉक होने दें, लेकिन उन्हें अलग से परीक्षण करना संभव होगा। बेशक, यह सामान्य है जब ब्लॉक अपने दम पर नहीं होते हैं, लेकिन एक पदानुक्रम में पंक्तिबद्ध होते हैं।
• यदि आप एक ब्लॉक की कार्यक्षमता को छोटे ब्लॉकों में तोड़कर, स्पष्ट कार्य के साथ, मानक इंटरफेस के साथ, प्रदर्शन में ध्यान देने योग्य हानि के बिना, इसे तोड़ सकते हैं, तो इसे सरल बना सकते हैं। यहां तक ​​कि अगर प्रदर्शन में नुकसान होता है - तो ध्यान से सोचें, कभी-कभी यह बलिदान करने के लायक है। लोहा अब सस्ता है।

» जारी: स्पष्टता का नियम