सॉफ्टवेयर सर्वोत्तम प्रथाओं के लिए उपयुक्त संदर्भ

14

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

जे डो ने 1975 में यूनिट परीक्षणों का आविष्कार किया । Bloggs et al द्वारा हाल ही में किए गए एक अध्ययन से पता चला है कि यूनिट परीक्षण 73% तक सॉफ्टवेयर त्रुटियों की घटनाओं को कम करते हैं ... 234 अलग-अलग यूनिट परीक्षणों को कोड बेस में जोड़ा गया था, जिसे Timpkins et al द्वारा बनाए गए xUnit ढांचे द्वारा प्रबंधित किया गया था। $^{[23]}$ $^{[24]}$ $^{[25]}$

मैं व्यापक रूप से स्वीकृत सॉफ्टवेयर इंजीनियरिंग सर्वोत्तम प्रथाओं के लिए, विशेष रूप से सहकर्मी-समीक्षात्मक लेखों की तलाश कर रहा हूँ (जहाँ मैं विशेष रूप से स्वीकृत सॉफ्टवेयर इंजीनियरिंग में DOIs, BibTeX इत्यादि प्राप्त कर सकता हूँ)।

इकाई परीक्षण
संस्करण नियंत्रण
सरलीकरण / सरोकारों को अलग करना
प्रदर्शन प्रोफाइल / अनुकूलन रूपरेखा जानकारी के आधार पर
बग / मुद्दा ट्रैकिंग

मैं प्रारंभिक आविष्कार और प्रभावशीलता के बाद के मूल्यांकन दोनों के बारे में जानकारी की तलाश कर रहा हूं। यदि एक समीक्षा लेख है जो इस सामान को एक ही स्थान पर सूचीबद्ध करता है तो इतना बेहतर है।

reference-request

— user1915639
स्रोत

1

क्या यह मदद करता है: plosbiology.org/article/…

— akid

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

— किरिल १

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

— ज्योफ ऑक्सबेरी

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

— ख़त्म

13

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

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

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

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

— ज्योफ ऑक्सबेरी
स्रोत

"सॉफ्टवेयर बढ़ईगीरी" पढ़ने की सूची उपयोगी लगती है।

— user1915639

6

मेरे पास इन विचारों / प्रथाओं के मूल के संदर्भ नहीं हैं। लेकिन यहाँ कुछ हाल ही में प्रासंगिक संदर्भ दिए गए हैं:

— डेविड केचेसन
स्रोत

मैं निश्चित रूप से इन संदर्भों में से दूसरे नंबर पर हूं :-) यह पूरी जानकारी है वुल्फगैंग बैंगर्थ, टिमो हेस्टर क्या कम्प्यूटेशनल ओपन सोर्स सॉफ्टवेयर पुस्तकालयों को सफल बनाता है? कम्प्यूटेशनल साइंस एंड डिस्कवरी, वॉल्यूम। ६, लेख ०१५०१० (१24 पृष्ठ), २०१३

— वोल्फगैंग बंगर्थ १14

-2

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

मैं आपकी परियोजना की आवश्यकता के बारे में बताते हुए उससे संपर्क करूंगा, कि उसे इसकी आवश्यकता क्यों है और उपयोग की जाने वाली विधियों के संदर्भ में और आपने उनका उपयोग क्यों किया।

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

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

— internetscooter
स्रोत

1

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

— ज्योफ ऑक्सबेरी

"एक गूदा अपनी पीएचडी में अधिक शक्तिशाली बयान" एक सुंदर गलती है तो

— Denis