जो लोग R के साथ काम करते हैं वे अच्छी तरह से जानते हैं कि भाषा मूल रूप से इंटरैक्टिव काम के लिए एक उपकरण के रूप में डिज़ाइन की गई थी। स्वाभाविक रूप से, एक व्यक्ति द्वारा सांत्वना-आधारित चरण-दर-चरण अनुप्रयोग के लिए सुविधाजनक तरीके जो विषय में गहरी है, अंतिम उपयोगकर्ता के लिए एक एप्लिकेशन बनाने के लिए अनुपयुक्त है। सभी चर और निशान के माध्यम से देखने के लिए, तुरंत कोड तत्वों को मैन्युअल रूप से निष्पादित करने के लिए (संभवतः आंशिक रूप से परिवर्तनशील चर) को देखने के लिए, एक त्रुटि के तथ्य पर विस्तृत निदान प्राप्त करने की क्षमता - यह सब अनुपलब्ध होगा जब R अनुप्रयोग एंटरप्राइज़ वातावरण में ऑफ़लाइन है। (हम आर कहते हैं, हम मूल रूप से चमकदार वेब अनुप्रयोगों का मतलब है)।
हालांकि, सब कुछ इतना बुरा नहीं है। आर वातावरण (पैकेज और एप्रोच) इतना विकसित हो गया है कि बहुत से सरल ट्रिक्स उपयोगकर्ता की स्थिरता और विश्वसनीयता सुनिश्चित करने की समस्या को हल कर सकते हैं। उनमें से कई का वर्णन नीचे किया जाएगा।
यह पिछले प्रकाशनों का एक सिलसिला है।
कार्य की कठिनाई क्या है?
कार्यों की मुख्य श्रेणी जिसके लिए अक्सर आर का उपयोग किया जाता है, विविध डेटा प्रोसेसिंग है। और यहां तक कि एक पूरी तरह से डीबग किए गए एल्गोरिदम, जो परीक्षणों द्वारा सभी पक्षों पर निर्धारित किए गए हैं और पूरी तरह से प्रलेखित हैं, आसानी से टूट सकते हैं और यदि डेटा इसके इनपुट में फिसल जाता है तो बकवास को बाहर कर सकते हैं।
डेटा अन्य सूचना प्रणालियों के साथ-साथ उपयोगकर्ताओं से भी इनपुट किया जा सकता है। और, अगर पहले मामले में एपीआई के अनुपालन की मांग करना और सूचना प्रवाह की स्थिरता पर बहुत सख्त प्रतिबंध लगाना संभव है, तो दूसरे मामले में आश्चर्य से कोई बच नहीं सकता है। कोई व्यक्ति गलती कर सकता है और गलत फाइल को खिसका सकता है, गलत लिख सकता है। 99% उपयोगकर्ता अपने काम में एक्सेल का उपयोग करते हैं और चालाक प्रारूपण के साथ, सिस्टम को बहुत सारे पेजों को ताड़ देना पसंद करते हैं। इस स्थिति में, कार्य और भी जटिल हो जाता है। यहां तक कि एक नेत्रहीन वैध दस्तावेज मशीन के दृष्टिकोण से पूरी तरह से बकवास लग सकता है। तिथियां बिखरी हुई हैं (बहुत प्रसिद्ध कहानी "एक्सेल के डिजाइनर ने सोचा कि 1900 एक लीप वर्ष था, लेकिन यह नहीं था" )। संख्यात्मक मानों को पाठ और टाइपसेट के रूप में संग्रहीत किया जाता है। अदृश्य कोशिकाएं और छिपे हुए सूत्र ... और भी बहुत कुछ। सिद्धांत रूप में, सभी संभव रेक को दूर करना असंभव है - पर्याप्त कल्पना नहीं है। यह विभिन्न स्रोतों में घुमावदार स्रोतों के साथ केवल दोहरीकरण के रिकॉर्ड के लायक है।
एक अतिरिक्त विचार के रूप में, हम निम्नलिखित लेंगे:
उत्कृष्ट दस्तावेज "आर के साथ डेटा सफाई के लिए एक परिचय" प्रारंभिक डेटा तैयारी की प्रक्रिया का वर्णन करता है। आगे के चरणों के लिए, हम सत्यापन के दो चरणों की उपस्थिति को बाहर करते हैं: तकनीकी और तार्किक।
- तकनीकी सत्यापन डेटा स्रोत की शुद्धता को सत्यापित करने के लिए है। संरचना, प्रकार, मात्रात्मक संकेतक।
- तार्किक सत्यापन बहु-चरण हो सकता है, गणना के दौरान किया जा सकता है, और विभिन्न तार्किक आवश्यकताओं के लिए कुछ डेटा तत्वों या उनके संयोजनों की अनुरूपता की जांच करना शामिल है।
- उपयोगकर्ता इंटरफेस के विकास में बुनियादी नियमों में से एक उपयोगकर्ता त्रुटियों के मामले में सबसे पूर्ण निदान का गठन है। यही है, अगर उपयोगकर्ता ने पहले से ही फ़ाइल अपलोड की है, तो इसे यथासंभव शुद्धता के लिए जांचना और सभी त्रुटियों के साथ एक पूर्ण सारांश देना आवश्यक है (यह भी समझाना उचित है कि क्या गलत है), और "गलत इनपुट" जैसे संदेश के साथ पहली समस्या पर क्रैश न हो। मान @ लाइन 528493, पॉज़ 17 ”और इस त्रुटि के साथ एक नई फ़ाइल डाउनलोड करने की आवश्यकता है। यह दृष्टिकोण आपको सही स्रोत बनाने और अंतिम परिणाम की गुणवत्ता में सुधार करने के लिए पुनरावृत्तियों की संख्या को काफी कम करने की अनुमति देता है।
प्रौद्योगिकी और सत्यापन के तरीके
चलिए अंत से। तार्किक सत्यापन के लिए कई पैकेज हैं। हमारे व्यवहार में, हम निम्नलिखित दृष्टिकोणों पर बस गए।
- पहले से ही एक क्लासिक
dplyr । सरल मामलों में, अंतिम परिणाम की जांच और विश्लेषण के साथ बस एक पाइप खींचना सुविधाजनक है। - दिए गए नियमों के अनुपालन के लिए तकनीकी रूप से सही वस्तुओं की जांच के लिए
validate पैकेज।
तकनीकी सत्यापन के लिए, हमने निम्नलिखित दृष्टिकोणों पर ध्यान केंद्रित किया:
- विभिन्न प्रकार के तकनीकी जांच करने के लिए फास्ट कार्यों की एक विस्तृत श्रृंखला के साथ
checkmate पैकेज। - अपवाद के साथ स्पष्ट कार्य "उन्नत आर। डिबगिंग, स्थिति से निपटने और रक्षात्मक प्रोग्रामिंग" , "उन्नत आर। परे अपवाद से निपटने: शर्तें और पुनरारंभ" दोनों एक कदम में सत्यापन की पूरी राशि का संचालन करने के लिए, और आवेदन की स्थिरता सुनिश्चित करने के लिए।
- अपवाद के लिए
purr रैपर का उपयोग करें। बहुत उपयोगी है जब एक पाइप के अंदर उपयोग किया जाता है।
फ़ंक्शन में टूटे हुए कोड में, रक्षात्मक प्रोग्रामिंग का एक महत्वपूर्ण तत्व कार्यों के इनपुट और आउटपुट मापदंडों की जांच करना है। डायनामिक टाइपिंग वाली भाषाओं के मामले में, स्वतंत्र रूप से टाइपिंग जाँच की जानी चाहिए। बुनियादी प्रकारों के लिए, चेकमेट पैकेज आदर्श है, विशेष रूप से इसके qtest \ qassert । data.frame जाँच करने के लिए data.frame निम्नलिखित निर्माण (नामों और प्रकारों की जाँच) पर रुक गए। नाम और प्रकार को मर्ज करने की चाल चेक में लाइनों की संख्या को कम करती है।
ff <- function(dataframe1, dataframe2){ # calledFun <- deparse(as.list(sys.call())[[1]]) tic("Calculating XYZ") # (class, typeof, Date ) list(dataframe1=c("name :: character", "val :: numeric", "ship_date :: Date"), dataframe2=c("out :: character", "label :: character")) %>% purrr::iwalk(~{ flog.info(glue::glue("Function {calledFun}: checking '{.y}' parameter with expected structure '{collapse(.x, sep=', ')}'")) rlang::eval_bare(rlang::sym(.y)) %>% assertDataFrame(min.rows=1, min.cols=length(.x)) %>% {assertSetEqual(.x, stri_join(names(.), map_chr(., class), sep=" :: "), .var.name=.y)} # {assertSubset(.x, stri_join(names(.), map_chr(., typeof), sep=" :: "))} }) … }
प्रकार जाँच फ़ंक्शन के भाग के रूप में, आप अपेक्षित डेटा के अनुसार, अपने स्वाद के लिए एक विधि चुन सकते हैं। class को इसलिए चुना गया क्योंकि यह वह है जो तारीख के रूप में तारीख देता है, न कि एक संख्या (आंतरिक प्रतिनिधित्व) के रूप में। डेटा प्रकारों के निर्धारण के मुद्दे पर बातचीत में "आर 'मोड' और 'क्लास' और 'टाइपोफ' चीजों के प्रकारों का एक व्यापक सर्वेक्षण अपर्याप्त है । "
assertSetEqual या assertSubset को स्पष्ट मिलान कॉलम या न्यूनतम पर्याप्त के कारणों के लिए चुना जाता है।
व्यावहारिक कार्यों के लिए, इस तरह का एक छोटा सेट पूरी तरह से अधिकांश जरूरतों को कवर करता है।
पिछला पोस्ट - एक सिस्टम एडमिनिस्ट्रेटर के लिए लाइफ बॉय के रूप में ।