अनुसंधान करते समय मुझे किस सॉफ्टवेयर पद्धति का पालन करना चाहिए?


9

मैं आमतौर पर प्रयोगों के डेटा का विश्लेषण करता हूं और हालांकि मेरे पास चरणों का एक सामान्य स्कीमा है जो मुझे करने की आवश्यकता है, मुझे इसे प्रयोगों की बारीकियों या पीछे के प्रश्नों के लिए ट्विक करने की आवश्यकता हो सकती है। मैं आमतौर पर केवल एक ही कोडिंग हूं।

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

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

कौन सा सॉफ्टवेयर कार्यप्रणाली अनुसंधान में सबसे अच्छा फिट बैठता है?

मैं मूल रूप से पूछ रहा हूं कि अनुसंधान की विशिष्टता को बनाए रखने के साथ-साथ गुणवत्ता और समयबद्ध प्रगति को कैसे सुनिश्चित किया जाए।

मैं कैसे काम करता हूं इसका उदाहरण:

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


7
अब तुम ठीक हो जाओ। कोई भी कार्यप्रणाली आपको गलतियाँ करने से नहीं रोकेगी! बस सुनिश्चित करें कि आप एक संस्करण नियंत्रण प्रणाली का उपयोग कर रहे हैं और अपने कोडबेस को अच्छी तरह से व्यवस्थित रखें।
gbjbaanb

कोई भी कार्यप्रणाली गलतियों को नहीं रोकेगी। लेकिन कुछ जल्द ही गलतियों को पकड़ लेंगे! अनुबंध द्वारा डिजाइन, या अनुबंध आधारित डिजाइन।
फ्रैंक हिलमैन

क्या आप कृपया अपने अंतिम वाक्य को विस्तृत कर सकते हैं? मुझे यह बिल्कुल नहीं मिला।
llrs

शायद en.wikipedia.org/wiki/Test-driven_development कुछ प्रकार के स्वचालित परीक्षण ढांचे के साथ - छोटे परीक्षण कीड़े पकड़ने के लिए उपयोगी होते हैं और बड़े परीक्षण आपके परिकल्पना पर मानचित्र (मोटे तौर पर)
david .libremone

1
@ लोपोपिस आदर्श रूप से आप पहले एक परीक्षा लिखते हैं, यह विफल हो जाता है, फिर कोड लिखें, परीक्षा पास होती है, फिर आप अपना कोड बनाते हैं - यदि आपको बाद में लाइन के नीचे एक बग का पता चलता है, तो आप वह परीक्षण लिखते हैं जिसने बग को पकड़ा होगा , यह विफल हो जाता है , कोड को ठीक करें, परीक्षण गुजरता है, फिर आप अपना कोड बनाते हैं - आप सब कुछ नहीं छोड़ सकते हैं, लेकिन आप यह सुनिश्चित कर सकते हैं कि वही बात फिर से न हो
david.libremone

जवाबों:


6

क्या जरूरत है, शायद एक सॉफ्टवेयर पद्धति नहीं है, लेकिन शिक्षा में एक राजनीतिक परिवर्तन जो विज्ञान में सॉफ्टवेयर विकास द्वारा निभाई गई भूमिका की मान्यता के मुद्दे को ठीक करता है।

सॉफ्टवेयर स्थिरता संस्थान (यूके) वैज्ञानिक अनुसंधान में कंप्यूटर प्रोग्रामिंग का अधिक ईमानदार उपयोग के लिए बहस करने के लिए कैसे: संगठन के लिए आप क्या देख रहे हैं के सबसे करीब है।

यह सॉफ्टवेयर विकास के तरीकों में रुचि रखने वालों के लिए सूचना बिंदु भी प्रदान करता है।

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


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


आपके कार्यस्थल पर, ऐसी चीजें हैं जो गायब थीं, और ऐसी चीजें जो आप कर सकते हैं।

जो चीजें गायब थीं:

  • दिशा-निर्देशों का अभाव
  • सवाल पूछने के लिए पर्यवेक्षण या व्यक्ति का अभाव
  • संरक्षक या कंप्यूटर प्रोग्रामर की कमी जो आपके द्वारा उपयोग किए जाने वाले उपकरणों के जानकार हैं (जैसे R)
  • दोहराव और सीखने के उद्देश्यों के लिए सॉफ्टवेयर के पुन: उपयोग, अभिलेखीय, संस्करण नियंत्रण, या पहले विकसित सॉफ्टवेयर के प्रलेखन का अभाव

संक्षेप में, समग्र संस्कृति यह है कि इसमें शामिल लोग वास्तव में रुचि नहीं रखते हैं ... आपने यह अनुमान लगाया है ... वैज्ञानिक अनुसंधान में कंप्यूटर प्रोग्रामिंग का अधिक ईमानदार उपयोग।


चीज़ें जो आप कर सकते हों:

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

करियर सॉफ्टवेयर डेवलपर्स के लिए, इस प्रकृति के दिशा निर्देशों में पाया जा सकता है:

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


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

हा हाँ, एक विकी ... के लिए कुछ करने की कोशिश की मैं यहाँ dokuwiki.org/dokuwiki# reccomend होगा । सेटअप करने के लिए सरल है और डेटाबेस के बजाय दस्तावेजों को पाठ फ़ाइलों के रूप में रखता है। मैंने पाया कि यह सेटअप में आसानी, उपयोग में आसानी और डेटा की स्थिरता के बीच सबसे अच्छा संतुलन था।
न्यूटॉपियन

कंप्यूटर-एडेड विज्ञान में जो समस्याएं @rwong का वर्णन करती हैं, वे उन अधिकांश संस्थानों में मौजूद हैं, जिनमें मैंने काम किया है (भौतिकी और खगोल विज्ञान)
स्टीफन को

2

कार्यप्रणाली पर इतना परेशान मत करो, लेकिन प्रयास करें और उस पर अधिक ध्यान केंद्रित करें जो आपको सॉफ़्टवेयर विकास के लिए, अपनी आवश्यकताओं का ट्रैक रखने की आवश्यकता है।

आपकी तुलना में यहाँ अपेक्षाकृत कम स्थिति में रहने के बाद मैं अपने व्यक्तिगत अनुभव से क्या कर सकता हूँ।

एल्गोरिदम की सटीकता

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

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

संस्करण

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

सुनिश्चित करें कि आप वास्तविक गणना में उपयोग किए गए कोड को टैग करते हैं, अगर आपको संस्करणों के नामकरण में मदद की आवश्यकता है तो सिमेंटिक संस्करण की जाँच करें ।

स्वचालित निर्माण

उपरोक्त बिंदु पर एक कोरोलरी। सुनिश्चित करें कि आप अपने सॉफ़्टवेयर के निर्माण और पैकेजिंग की प्रक्रिया को जितना संभव हो स्वचालित करें। आपको स्रोत और निर्भरता से अंतिम प्रणाली बनाने के लिए इसे तुच्छ बनाने के लिए पर्याप्त मात्रा में जाने की आवश्यकता नहीं है। यहाँ लक्ष्य आपको समय बचाने के लिए है, लेकिन निर्भरता और अन्य बाह्य उपकरणों सहित स्रोत से सॉफ्टवेयर को फिर से बनाने के लिए एक प्रतिलिपि प्रस्तुत करने योग्य मतलब है। Groovy, Maven, ant, Scons, cmake, लेकिन बिल्ड ऑटोमेशन टूल्स और स्क्रिप्टिंग सिस्टम का एक छोटा सा नमूना है जो मदद कर सकता है।

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

पर्यावरण अलगाव

शोधकर्ता अपने प्रोटोकॉल के माध्यम से जटिल प्रणालियों से ब्याज के चर के एक या छोटे सेट को अलग करने में समय की राशि खर्च करते हैं। यह आपके सॉफ़्टवेयर विकास प्रथाओं के लिए भी बढ़ाया जाना चाहिए। आप डॉकटर या वैग्रैंट के साथ कंटेनरीकरण के लिए भी जांच कर सकते हैं। यह आपको उस पर्यावरण पर बेहतर नियंत्रण देगा जिसके तहत सॉफ्टवेयर चलाया जाता है।

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


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

हालाँकि, मैंने बाहरी निर्भरता पर परीक्षण किए हैं, लेकिन यह दुर्लभ था ... यह आपका अपना कोड है जिसका आपको परीक्षण करना चाहिए, क्या आपने पुस्तकालयों का सही उपयोग किया है? क्या यह रेडिकली (आपका कोड) विफल हो जाता है? आदि
न्यूटोपियन

0
  1. क्या आप R का उपयोग कर सकते हैं? बस यही बात है।

  2. अपना कोड सरल रखें । जब तक यह समस्या न हो, पठनीयता के लिए जाएं और प्रदर्शन की चिंता न करें। कार्यप्रणाली प्रोग्रामर्स की टीमों को एक दूसरे के कोड में बग्स रखने से रोकने की कोशिश करती है, भले ही टीम एक व्यक्ति हो।

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


1
मैं आर का उपयोग कर रहा हूं, आशा है कि मेरा कोड उन बग्स को स्पॉट करने के लिए काफी सरल है जो मैं लिख सकता था और कोई भी गलती जो मैं कर सकता था। मैं Google R कोड प्रारूपण शैली का अनुसरण करता हूं, और मैं यह सोचना चाहूंगा कि टिप्पणी यह ​​बताने के लिए उपयोगी है कि मैं कोड में ऐसे फैसले क्यों लेता हूं।
बजे

@ लोपोपिस: फिर मैं कहूंगा कि आप सही रास्ते पर हैं।
माइक डनलैवी

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

1
@ वास्तव में मुझे अपना शोध कोड साझा करने की अनुमति दी गई है, इसलिए कोई भी इसे गीथूब पर समीक्षा कर सकता है
27'16

@ लोपोपिस: इसे पढ़ने योग्य बनाने के लिए और अधिक कारण। एक बात जो मैं करने की कोशिश करता हूं वह विषय वस्तु पर एक बहुत छोटा ट्यूटोरियल (टिप्पणियों में) दे रहा है, क्योंकि संभावना है कि पाठक की विशेषज्ञता मेरा से अलग होगी।
माइक डनलैवी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.