क्या मुझे इस्तेमाल किए गए पुस्तकालयों के कोड को पढ़ने की आवश्यकता है?

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

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


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

व्यवहार की अस्पष्टता

आइए एक अज्ञात भाषा में ऐसे अमूर्त पुस्तकालय के इंटरफ़ेस की कल्पना करें:

interface IInterface { bool Init(); int Calculate(int val); void Release(); } 

सब कुछ स्पष्ट है, है ना? हम इनिट () कहते हैं, फिर हम कुछ को परिकलित करने के लिए स्थानांतरित करते हैं (), हमें जवाब मिलता है, हम रिलीज () कहते हैं।

प्राथमिक? अपना समय ले लो। उत्तर दें कि क्या होगा यदि:

1. कॉल Init () दो बार? और 1000 गुना?
2. Init को कॉल किए बिना कॉल कैलकुलेट () करें?
3. कॉल रिलीज () नहीं है? और अगर दो बार फोन किया तो? और अगर 1000 बार? लेकिन क्या अगर Init () को कॉल करने से पहले?
4. कॉल इनीट (), गणना (), रिलीज () विभिन्न थ्रेड्स से?
5. सामान्य तौर पर घाटी तर्क की सीमा क्या है? पूरा इंट? और बिल्कुल? और 0 भी? MIN_INT और MAX_INT के बारे में क्या?
6. और फिर कुछ अपवादों को फेंक दिया जाता है?
7. क्या कोई लॉग यहाँ लिखा है? यह किसी तरह कॉन्फ़िगर करता है?

कुआँ, आदि।

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

पुस्तकालय का उद्देश्य

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

परीक्षण

तुरंत बारीकियों का एक पूरा सेट है। यदि लाइब्रेरी में परीक्षण होते हैं, तो यह बहुत कुछ कहता है, उन्हें पढ़ा जा सकता है, चला सकते हैं, यह महत्वपूर्ण रूप से समझ देगा कि यह पुस्तकालय कैसे उपयोग किया जा सकता है / होना चाहिए। उदाहरण के लिए, मैंने अक्सर परीक्षणों में "TODO: ...", "संभव बग", परीक्षणों के टुकड़ों पर टिप्पणी की है कि "कार्यक्षमता लागू करने के बाद असहजता", आदि। यहां तक ​​कि सबसे प्राथमिक परीक्षण अचानक पता चल सकता है, उदाहरण के लिए, कि लेखक फ़ंक्शन के इनपुट पर केल्विन में एक तापमान की उम्मीद करता है, हालांकि आप 100% सुनिश्चित थे कि यह सेल्सियस में होना चाहिए।

यदि कोई परीक्षण नहीं हैं, तो यह भी बहुत कुछ कहता है (सबसे पहले, कि किसी अन्य पुस्तकालय की तलाश करना बेहतर होगा)। शायद आपको उन्हें खुद लिखना चाहिए। और शायद पुस्तकालय इस तरह से लिखा जाता है कि उन्हें लिखना बहुत मुश्किल है - फिर पुस्तकालय का उपयोग करने में समस्याएं हो सकती हैं।

पुस्तकालय निर्माता योग्यता

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

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

लापरवाही

आप नहीं जानते कि पुस्तकालय को लिखने वाले व्यक्ति इसे कितना गुणवत्तापूर्ण बनाना चाहते थे। शायद उन्होंने एक अतिरिक्त सौ घंटे कोड को "चमकाने" में बिताए, या शायद यह पुस्तकालय उनके आखिरी काम का आखिरी उत्पाद था, जो कि नफरत वाले नियोक्ता को छोड़ने से पहले "पिछले दो सप्ताह" के दौरान लिखा गया था। क्या आप सोच सकते हैं कि पहले और दूसरे मामले में कोड की गुणवत्ता कितनी अलग हो सकती है?

बुराई का इरादा

हम सभी हाल ही में एनएसए बुकमार्क की एक यादृच्छिक संख्या जनरेटर की कहानी जानते हैं। खैर, अफवाहों के बारे में (या अफवाहों के बारे में) इस मामले में $ 10 मिलियन के बारे में भी पता है। लोग रोजमर्रा की जिंदगी में बहुत संदेहवादी और संदिग्ध हैं, लेकिन सॉफ्टवेयर में विश्वास के संदर्भ में (और यहां तक ​​कि अचानक मुक्त होने पर भी) वे पूरी तरह से महत्वपूर्ण पदों पर रहते हैं।

मुझे बताओ कि तुम्हारा दोस्त कौन है और मैं तुम्हें बताऊंगा कि तुम कौन हो

अपने पुस्तकालयों के साथ उत्पाद के संबंध के लिए भी यही सच है। यदि लाइब्रेरी में कोई बग है, तो यह आपके उत्पाद में होगा। पुस्तकालय में एक स्मृति रिसाव? नहीं, अब यह आपके उत्पाद में स्मृति रिसाव है। ताला? प्रदर्शन के मुद्दे? अपरिभाषित व्यवहार? प्राप्त करना, हस्ताक्षर करना।

निष्कर्ष

अमूर्तता तब नहीं होती है जब आप किसी चीज की आंतरिक संरचना को नहीं समझते हैं, यह तब होता है जब आप इसके बारे में इतने सुनिश्चित होते हैं कि आप इसके बारे में सोचने के लिए नहीं उठा सकते।