उनके डिजाइन या वास्तुकला के बारे में दस्तावेज़ीकरण के बिना स्रोत परियोजनाएं कैसे सफल हो सकती हैं?

Question

मैं प्रसिद्ध ओपन सोर्स प्रोजेक्ट्स का अध्ययन करके अपने प्रोग्रामिंग कौशल में सुधार करना चाहता हूं, लेकिन मुझे लगता है कि उनके स्रोत कोड में कूदकर खो जाना आसान है।

इसलिए मैंने पहले उनके कोड के संगठन के बारे में एक सामान्य विचार प्राप्त करने के लिए उनके डिजाइन या आर्किटेक्चर (जैसे यूएमएल आरेख) के बारे में उनके दस्तावेज को पढ़ने का फैसला किया। मेरे आश्चर्य के लिए, हालांकि, मुझे बड़े ओपन सोर्स प्रोजेक्ट्स जैसे कि हाइबरनेट, स्प्रिंग, ASP.NET MVC, रेल्स, आदि के लिए कोई आर्किटेक्चरल डॉक्यूमेंटेशन नहीं मिल सकता है।

इसलिए मैंने आश्चर्यचकित करना शुरू कर दिया है: यदि एक नए स्रोत वाले डेवलपर्स के पास पढ़ने के लिए कोई वास्तु / डिजाइन प्रलेखन नहीं है, या यदि परियोजना प्रबंधक ने स्रोत कोड खोला है, लेकिन उसके प्रलेखन को बंद कर दिया है, तो एक खुला स्रोत परियोजना कैसे सफल हो सकती है?

Comments

"अधिकांश"? क्या आप इसे ठोस आँकड़ों के साथ वापस कर सकते हैं? आपने कितने पढ़े? कितने हैं? कितने उपयुक्त दस्तावेज की कमी है? यदि आपके पास नंबर नहीं हैं, तो कृपया "सबसे" जैसे शब्दों को हटा दें और उन्हें वास्तविक तथ्यों के साथ बदलें जो आपने वास्तव में पाया है। इसके अलावा, कृपया अपने आप को संदर्भित करते हुए "I" को कैपिटल करें।

— एस.लॉट

@ व्यक्तिपरक "सबसे" के लिए क्षमा करें। मैं सॉफ्टवेयर इंडस्ट्री में नौसिखिया हूं। मैं उन प्रोजेक्ट्स की खोज करने की कोशिश कर रहा हूं जो मैंने कॉलेज प्रोजेक्ट (जैसे यूएमएल डायग्राम, फ्लो चार्ट, ब्रीफ डिज़ाइन डॉक, डिटेल्ड डिज़ाइन डॉक्टर, आदि) के दौरान उनके प्रोजेक्ट वेबसाइट या कोड रिपॉजिटरी में किस्मत के बिना दोनों के लिए सुना था। केवल कुछ उपयोगकर्ता-गाइड डॉक्टर को खोजने के लिए। क्या आप मुझे उनके desgin / archiecture दस्तावेज़ों को खोजने के लिए कुछ सामान्य तरीके सिखा सकते हैं?

— टॉमकैप्स

कृपया "कई" को हटा दें। यह सबसे गलत है। कृपया विशेष रूप से विशिष्ट ओपन सोर्स प्रोजेक्ट्स को सूचीबद्ध करने के लिए प्रश्न को अपडेट करें जो विशेष रूप से आपके द्वारा देखे जाने वाले विशिष्ट दस्तावेज की कमी है। कृपया सटीक और विशिष्ट रहें। कृपया व्यक्तिपरक और अस्पष्ट मत बनो।

— S.Lott

मुझे संदेह है कि ASP.NET MVC के कारण UML आरेख शामिल नहीं हैं क्योंकि विज़ुअल स्टूडियो उन्हें स्रोत कोड से बना सकते हैं।

— user16764

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

— o11c

Answer 1

क्यों एक खुला स्रोत परियोजना सफल हो सकती है अगर नए-हास्य डेवलपर के पास पढ़ने के लिए कोई वास्तु / डिज़ाइन दस्तावेज़ नहीं है?

यह अनुमान हमेशा लगाया जाता है कि आप जानते हैं कि आप क्या कर रहे हैं और देखने के लिए (और अपेक्षा) क्या आप जा रहे हैं की एक यथोचित अंतरंग समझ है।

यदि आप उदाहरण के लिए, सिम्फनी फ्रेमवर्क के PHP कोड को देखते हैं, तो आपको पहले से ही निर्भरता इंजेक्शन, घटनाओं, मॉडल / दृश्य / नियंत्रक पैटर्न, और आगे के बारे में जानने की उम्मीद है।

इसी तरह, यदि आप लिनक्स कर्नेल के सी कोड में गोता लगाते हैं, तो धारणा यह है कि आप वास्तविक रूप से प्रतिरूपकता, संकेतों, प्रक्रियाओं, थ्रेड्स में सक्षम होंगे और क्या नहीं। आपको पूरे दिन हेक्साडेसिमल खाने और एक विशाल फावड़ा के साथ कोर डंप के माध्यम से खुदाई करने की उम्मीद है।

यह वास्तव में सामान की बात है क्योंकि रखवाले वास्तुकला के दस्तावेजीकरण की परेशानी से नहीं गुज़रेंगे। अवसर पर, आपको स्रोत वृक्ष में निहित झूठ की रूपरेखा मिल जाएगी। आमतौर पर हालांकि, जिस तरह से स्रोत वृक्ष का आयोजन किया जाता है वह चीजों को आत्म-व्याख्यात्मक बनाता है।

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

Comments

यद्यपि यदि आप मेलिंग सूचियों को देखते हैं तो लिनक्स कर्नेल की वास्तुकला के बारे में व्यापक चर्चा होती है जब भी किसी को कोई समस्या होती है या कुछ बदलने की इच्छा होती है। इसके बारे में काफी कुछ दस्तावेज भी लिखे गए हैं - हालांकि कर्नेल स्रोत के पेड़ में नहीं।

— edA-qa मोर्ट-ओर-वाई

Answer 2

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

Comments

मेरी कंपनी में, यह एक आवश्यकता प्रक्रिया है कि डेवलपर्स को परियोजना पर कोई भी कोड लिखने से पहले एक विस्तृत डिज़ाइन दस्तावेज़ प्रदान करना चाहिए। क्या ओपन सोर्स प्रोजेक्ट के लिए यह प्रक्रिया असामान्य है?

— टॉमकैप्स

@TomCaps मुझे लगता है कि सबसे बड़ी वजह यह है कि कुछ FOSS परियोजनाओं का व्यापक प्रलेखन काफी सरल है: यदि आपका लेखन आपके पास एक ज़रूरत को हल करने के लिए एक छोटा सा कार्यक्रम है, तो संभावना है कि आपके डेवलपर के बाद से आपको दस्तावेज़ों की भी ज़रूरत नहीं है, आपको प्रलेखन लिखने की बजाय कार्यक्रम को बेहतर बनाने में अपना समय व्यतीत करना चाहते हैं जो किसी के लिए भी उपयोगी नहीं है (क्या होगा यदि परियोजना डेवलपर द्वारा छोड़कर किसी के द्वारा कभी भी उपयोग नहीं की गई है?)। यह सबसे अच्छा अभ्यास नहीं है, लेकिन कई FOSS परियोजनाएं डेवलपर-समय पर छोटी हैं।

— जेफ वेलिंग

@TomCaps: अधिकांश कंपनियों के लिए यह प्रक्रिया असामान्य है, जो मुझे पता है ...

— ट्रेब

ज्यादातर ओपन सोर्स प्रोजेक्ट्स कंपनियां नहीं हैं। आप सोच रहे हैं कि क्या होता है जब कोई परियोजना होती है जिसे बनाने के लिए मुझे भुगतान किया जाता है, एक समय सीमा और एक बजट के साथ। यदि आपके पास उन लोगों का एक समूह है जो उनके पास या मौज-मस्ती की ज़रूरत को भरने के लिए कोडिंग करते हैं और कोई बजट या ग्राहक नहीं है तो आपके पास उन प्रकार की चीज़ें नहीं हैं।

— एलिन

@TomCaps - ओपन सोर्स सॉफ्टवेयर लिखने वाला कोई भी व्यक्ति वही कर सकता है जो उन्हें पसंद है। कुछ परियोजनाओं (जैसे कि अपाचे परिवार) में किसी को भी कोड आने के लिए नियम और दिशा-निर्देश हैं और कभी-कभी इसमें डूमेंटेशन मानक आदि भी शामिल हैं। मैं "डिटेल डिज़ाइन डॉक्यूमेंट" के मूल्य पर भी सवाल उठाऊंगा क्योंकि यह आपको एक भौतिक डिज़ाइन में लॉक कर देगा जो (में) मेरा व्यक्तिगत अनुभव) आमतौर पर उप-इष्टतम है। "क्या" कार्यक्रम का एक विस्तृत विवरण डेवलपर को कार्यान्वयन को अनुकूलित करने और समाधान के लिए रचनात्मक रणनीतियों को लागू करने के लिए स्वतंत्र छोड़ देता है।

— जेम्स एंडरसन

Answer 3

क्योंकि ओपन सोर्स डेवलपर्स आमतौर पर प्रतिभाशाली होते हैं और अपने विशेषज्ञता क्षेत्र में परियोजना भी चुनते हैं, उनके पास पहले से ही उनकी खोपड़ी के भीतर "प्रलेखन" है। थोड़ा अतिशयोक्ति के साथ पूरी तरह से प्रलेखन की जरूरत है केवल अगर आप उन में से किसी की कमी है: ओ)

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

अतिरिक्त कारण इन परियोजनाओं की सादा जैविक डिजाइन जड़ें हो सकती हैं। आर्किटेक्चर तब डेवलपर्स के दिमाग में विकसित दृष्टि है जैसा कि "प्रलेखित" इकाई से कहा गया है।

Answer 4

इस तरह के डॉक्स अक्सर मौजूद नहीं होते हैं, यह बहुत आसान है: प्रोग्रामर को प्रोग्राम करना पसंद है, डॉक्यूमेंटेशन नहीं लिखना। विशेष रूप से खुले स्रोत परियोजनाओं के साथ, जो डेवलपर्स अक्सर अपने खाली / अवकाश समय के दौरान योगदान करते हैं।

असल में, प्रलेखन लिखना कोई मज़ेदार नहीं है। और अगर वे इसके लिए भुगतान नहीं कर रहे हैं, तो वे अपना खाली समय बिताना चाहते हैं जो कि कुछ मज़ेदार नहीं है?

Comments

कुछ बड़े ओपन सोर्स प्रोजेक्ट्स (जीसीसी, लिनक्स कर्नेल, फायरफॉक्स, क्यूटी, ....) के पास परियोजना में काम करने के लिए भुगतान किया गया (पूर्णकालिक या आधा समय) उनके योगदान का सबसे (या एक महत्वपूर्ण हिस्सा) है। इसलिए जब मुफ्त सॉफ्टवेयर के लिए भुगतान किया जाता है, तो वे बहुत सारे दस्तावेज नहीं लिखते हैं

— बेसिल स्टायरेंविच