क्या सॉफ्टवेयर विकास के लिए दस्तावेजों को संग्रहीत करने के लिए विकी वास्तव में उपयुक्त हैं? [बन्द है]


18

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

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


3
FYI करें: विकी एक संक्षिप्त नाम नहीं है , यह एक हवाई शब्द है जिसका अर्थ है "त्वरित"।
जोर्ग डब्ल्यू मित्तग

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

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

जवाबों:


16

क्या सॉफ्टवेयर डेवलपमेंट के लिए डॉक्यूमेंट स्टोर करना WIKI वास्तव में उचित है?

डॉक्स, पीडीएफ़ और अन्य प्रकार की फ़ाइलों को लिखने के बजाय, आप एक सहयोग उपकरण के रूप में विकी की पूरी क्षमता को क्यों नहीं हटाते हैं? आप अपने दस्तावेज़ वहां लिख सकते हैं, अपने आरेख और बेहतर तरीके से संलग्न कर सकते हैं : यदि आप फिटनेस का उपयोग करते हैं , तो आप अपने विकी पृष्ठों को वास्तव में उपयोगी और जीवित प्रलेखन में बदल सकते हैं, क्योंकि वे एक निष्पादन योग्य विनिर्देश बन सकते हैं।

हर कोई जानता है कि, अच्छी तरह से प्रलेखित सॉफ्टवेयर विकास सफलता की ओर जाता है

इस एक के लिए बाहर देखो। दस्तावेज़ सफलता की ओर नहीं होंगे, क्योंकि वे बकवास कोड को अच्छे में नहीं बदलेंगे। लेकिन दस्तावेज सफल सॉफ्टवेयर के रास्ते का एक हिस्सा हैं। लेकिन सिर्फ एक हिस्सा है और वे अच्छे व्यवहार और अच्छे लोगों को प्रतिस्थापित नहीं करेंगे।


8

चूंकि कई उत्तर एक सुझाव के रूप में Trac को इंगित करते हैं, मैं एक समान सुझाव देना चाहूंगा, लेकिन मेरी राय में बेहतर है, वैकल्पिक: Redmine

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

सब कुछ से अधिक यह वास्तव में उपयोग करना आसान है और इसका उपयोग करने वाली टीम को प्राप्त करना आसान है।

विशेषताएं:

  • कई परियोजनाओं का समर्थन करते हैं
  • लचीली भूमिका आधारित अभिगम नियंत्रण
  • लचीला मुद्दा ट्रैकिंग प्रणाली
  • गैन्ट चार्ट और कैलेंडर
  • समाचार, दस्तावेज और फाइल प्रबंधन
  • फ़ीड्स और ईमेल सूचनाएं
  • प्रति परियोजना विकि
  • प्रति परियोजना मंचों
  • समय का देखभाल
  • मुद्दों, समय-प्रविष्टियों, परियोजनाओं और उपयोगकर्ताओं के लिए कस्टम फ़ील्ड
  • एससीएम एकीकरण (SVN, CVS, Git, Mercurial, Bazaar और Darcs)
  • ईमेल के माध्यम से निर्माण जारी करें
  • एकाधिक LDAP प्रमाणीकरण समर्थन
  • उपयोगकर्ता स्व-पंजीकरण का समर्थन
  • बहुभाषी समर्थन
  • एकाधिक डेटाबेस समर्थन करते हैं

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


+1 मैं काम में रेडमाइन का उपयोग करता हूं और यह वास्तव में एक बेहतरीन प्रणाली है।
लुइज डेमिम

5

कुछ विकी (उदाहरण के लिए Ikiwiki ) आपके डेटा को Git में संग्रहीत करने की क्षमता रखते हैं, जैसा कि आपने उल्लेख किया है। यह देखते हुए, आप अपने नियमित स्रोत भंडार के तहत दस्तावेज को Git सबमॉड्यूल के रूप में लिंक कर सकते हैं ।

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

इसका अजीब हिस्सा यह है कि जब भी प्रलेखन अपडेट किया जाता है (यहां तक ​​कि इविकी वेब इंटरफेस के माध्यम से), तो आपको गिट स्रोत भंडार में संबंधित सबमॉड्यूल को भी अपडेट करना होगा। हालाँकि, यह आसानी से स्वचालित हो सकता है।


दिलचस्प। क्या दस्तावेज़ को गिट रिपॉजिटरी में डालने और ikiwiki के माध्यम से दस्तावेज़ को संग्रहीत करने के बीच कोई अंतर है?
एडिसन चुआंग

1
@ एडीसन चुआंग: नहीं, वहाँ नहीं है। वास्तव में, एक ikiwiki रिपॉजिटरी का एक क्लोन दिया गया है, आप अपनी पसंद के टेक्स्ट एडिटर का उपयोग करके पृष्ठों को संपादित कर सकते हैं (आपको भद्दे ब्राउज़र-आधारित टेक्स्ट एंट्री बॉक्स का उपयोग करने की आवश्यकता नहीं है)। आप पुराने दस्तावेज़ या जो भी हो, का एक स्नैपशॉट रखने के लिए, विकी की विभिन्न शाखाएँ भी हो सकते हैं।
ग्रेग हेविल

ऐसा लगता है कि दस्तावेज़ को बाइनरी फ़ाइलों के बावजूद किसी भी मुद्दे के बिना संस्करण नियंत्रण प्रणाली में संग्रहीत किया जा सकता है। डेवलपर केवल विकी पृष्ठों को मांग पर HTML पृष्ठों में बदलने के लिए ikiwiki जैसे टूल का उपयोग कर सकता है।
एडीसन चुआंग

Ikiwiki wiki इंजन के लिए +1; हट्टा विकि इंजन मर्क्युरियल खजाने के लिए एक समान विचार है।
डेविड कैरी

ISTR Fitnesse अपने विकि पृष्ठों को पाठ फ़ाइलों के रूप में संग्रहीत करता है, इसलिए यदि आप चाहें तो उन्हें भी आपके संस्करण नियंत्रण प्रणाली में रखा जा सकता है। हालांकि इसका प्राथमिक उद्देश्य परीक्षण है, लेकिन इसका कोई कारण नहीं है कि यह आपके प्रलेखन के लिए एक सामान्य-उद्देश्य विकी प्रणाली के रूप में उपयोग न करे।
जूल्स

4

यह सोर्स कोड के रूप में उसी रिपॉजिटरी में प्रलेखन को स्टोर करने के लिए समझ में आता है। स्फिंक्स मेरे लिए एक अच्छे विकल्प की तरह लगता है।

  • यह इनपुट के रूप में reStructuredText फ़ाइलों को लेता है , जो संपादित करना और अलग करना आसान है
  • यह हाइपरलिंकड आउटपुट (HTML, PDF, ...) उत्पन्न करता है
  • आप अपने स्रोत कोड (पायथन, सी, सी ++, जावास्क्रिप्ट) का संदर्भ ले सकते हैं

2

Trac, Subversion, एक एकीकृत Wiki और सुविधाजनक रिपोर्टिंग सुविधाओं के लिए एक इंटरफ़ेस प्रदान करता है। http://trac.edgewall.org/
लेकिन मैं आपके स्थापित स्टैक के बारे में नहीं जानता।


और मर्क्यूरियल के लिए एक अच्छा इंटरफ़ेस। और यह प्रमुख रूप से हैक करने योग्य है।
फ्रैंक शीयर

0

मैं ऑफ़लाइन काम के अनुरूप होने की कोशिश नहीं करूंगा। मैं उस संसाधन का उपयोग करूंगा जो सभी के लिए काम करने में सबसे आसान हो। उदाहरण के लिए, यदि आप PHP कोड लिख रहे हैं, तो मैं इनलाइन प्रलेखन का उपयोग करने का सुझाव दूंगा जो कि PHPDocumentor द्वारा उत्पन्न किया जा सकता है । इसे कहीं भी जेनरेट किया जा सकता है और Trac के लिए एक प्लगइन है । फिर ऑनलाइन या बंद, आपके पास प्रलेखन तक पहुंच है, काफी जल्दी भी।

कुंजी प्रयोज्य के बारे में है। यदि इसे बनाए रखना मुश्किल है, तो यह भुगतना शुरू कर देगा। जब यह भुगतना शुरू होता है, तो प्रलेखन गुणवत्ता कम हो जाती है। जब ऐसा होता है, तो लोग शिकायत करने लगते हैं और फिर सब कुछ ढह जाता है।


-1

प्रलेखन स्टोर करने के लिए एक विकी का उपयोग करना मेरे लिए बहुत मायने रखता है।

वेरीसी डीवीसीएस का एक उदाहरण है जो विकी सामग्री और स्रोत कोड के सख्त एकीकरण की अनुमति देता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.