आपको SDK, मुझे SDK, सबको SDK! SDK कैसे बनाया जाता है और इसकी आवश्यकता क्यों है

सभी को नमस्कार!

हमारी कंपनी औद्योगिक उपकरणों (पंप, ड्रिल और अन्य औद्योगिक उपकरण) से डेटा भंडारण और प्रसंस्करण के लिए एक सेवा बनाती है। हम अपने ग्राहकों के डेटा को संग्रहीत करते हैं और उनके विश्लेषण के लिए कार्यक्षमता प्रदान करते हैं: रिपोर्ट, ग्राफ़ और बहुत कुछ।

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

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

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

यह निर्धारित होने का समय है

एसडीके क्या है और इसकी आवश्यकता क्यों हो सकती है, इसे परिभाषित करते हुए शुरू करते हैं।

एसडीके (अंग्रेजी सॉफ्टवेयर डेवलपमेंट किट से) विकास उपकरणों का एक सेट है जो सॉफ्टवेयर विशेषज्ञों को एक विशिष्ट सॉफ्टवेयर पैकेज, बुनियादी विकास सॉफ्टवेयर, हार्डवेयर प्लेटफॉर्म, कंप्यूटर सिस्टम, गेम कंसोल, ऑपरेटिंग सिस्टम और अन्य प्लेटफार्मों के लिए एप्लिकेशन बनाने की अनुमति देता है। एसडीके प्रत्येक प्लेटफॉर्म का लाभ उठाता है और एकीकरण समय को कम करता है।
...
एक सॉफ्टवेयर इंजीनियर आमतौर पर लक्ष्य प्रणाली के डेवलपर से एक एसडीके प्राप्त करता है।

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

लेकिन, किसी भी दृष्टिकोण की तरह, एसडीके पथ के फायदे और नुकसान दोनों हैं।

लाभ

एक नए ग्राहक का उच्च गति एकीकरण - आपके ग्राहकों को कम कोड लिखने की आवश्यकता है।

कोड का पुन: उपयोग - एक ही कोड को एक साथ कई स्थानों पर उपयोग किया जाता है। हम कह सकते हैं कि यह पिछले पैराग्राफ का दोहराव है, लेकिन हम इस तथ्य के बारे में बात कर रहे हैं कि काम का तर्क हर जगह अकेला है, जिसका अर्थ है

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

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

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

सभी फायदे, वास्तव में, सबसे महत्वपूर्ण चीज के परिणाम हैं - हम कोड को एक बार बहुत उच्च गुणवत्ता लिखते हैं, और फिर इसका पुन: उपयोग करते हैं ।

कमियों

एसडीके कोड के लिए उच्च गुणवत्ता की आवश्यकताएं मुख्य लाभ का परिणाम हैं। एसडीके में एक त्रुटि इसके उपयोग से सभी प्रणालियों में त्रुटियां उत्पन्न करेगी।

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

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

जब एसडीके वास्तव में जरूरत है

आपके पास कई मानक परिदृश्य हैं जिन्हें समय - समय पर नए सिरे से लागू किया जाता है - वास्तव में, हमारा मामला।

आंतरिक विकास - विभिन्न परियोजनाओं में आप लॉगिंग सिस्टम, सिस्टम कॉन्फ़िगरेशन, HttpRequest, डेटाबेस, फ़ाइलों के साथ काम करते हैं? आंतरिक एसडीके का निर्माण करें - आंतरिक उपयोग के लिए पुस्तकालयों का एक सेट। आप किसी भी समय एसडीके कार्यक्षमता का विस्तार कर सकते हैं, लेकिन नई परियोजनाओं को विकसित करने की गति, परीक्षणों और प्रलेखन के साथ कवरेज का प्रतिशत बढ़ जाएगा, और नए डेवलपर्स के लिए प्रवेश करने की सीमा कम हो जाएगी।

जब एसडीके बेमानी होने की संभावना है

उपयोग परिदृश्य परिभाषित नहीं हैं या लगातार बदल रहे हैं - ग्राहकों के लिए कस्टम समाधान के कार्यान्वयन को छोड़ दें और उनकी मदद करें। वंडरवफ़ल की एक विलक्षण बनाने की आवश्यकता नहीं है, जो केवल हस्तक्षेप करेगा। युवा कंपनियों और स्टार्टअप्स के लिए बहुत प्रासंगिक है।

आप यह नहीं जानते कि इसे गुणात्मक रूप से कैसे किया जाता है - मेरे पास आपके लिए बुरी खबर है: यह सीखने का समय है। लेकिन एक ग्राहक को कुटिल निर्णय देना बहुत गलत है। ग्राहकों का सम्मान किया जाना चाहिए, आखिर।

इसलिए, हमने फैसला किया कि एसडीके क्या है, इसके फायदे और नुकसान के साथ, और जब हमें इसकी आवश्यकता होती है। यदि उसके बाद आपको पता चला कि एसडीके की वास्तव में आवश्यकता है - मैं आपको "एसडीके पथ" पर जाने के लिए आमंत्रित करता हूं और यह पता लगाता हूं कि यह क्या होना चाहिए और इसे कैसे करना है?

"क्या आप लेगो से प्यार करते हैं?" - प्रतिरूपकता

एसडीके का उपयोग करने के लिए सभी संभावित परिदृश्यों की कल्पना करें (आपने पहले ही तय कर लिया है कि आपको इसकी आवश्यकता क्यों है, ठीक है?) और पुस्तकालय के लिए एक स्क्रिप्ट बनाएं। एक विकल्प क्या नहीं है? लेकिन यह एक बुरा दृष्टिकोण है, और इसलिए हम ऐसा नहीं करेंगे। और हम इस तरह होंगे:

• सभी लिपियों को चरणों में तोड़ें
• सामान्य चरणों की पहचान करें
• सभी संभावित चरणों को लागू करने वाले मॉड्यूल की एक सूची बनाएं (एक मॉड्यूल कुछ विशिष्ट को लागू करने के लिए जिम्मेदार है, उदाहरण के लिए, कॉन्फ़िगरेशन के साथ काम करना)

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

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

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

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

"और इसलिए यह संभव था?" - बहुमुखी प्रतिभा

अपने पुस्तकालय के साथ काम करने के लिए ग्राहक को विभिन्न इंटरफेस प्रदान करें। मैं एक उदाहरण दूंगा:

public void LoadConfiguration(string filename); public async Task LoadConfigurationAsync(string filename); 

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

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

 class BaseConfiguration{ public BaseConfiguration FromString(string source){...} public BaseConfiguration FromString(string source,Type configurationType){...} public T FromString<T>(string source) where T:BaseConfiguration } class CustomConfiguration : BaseConfiguration{} 

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

"जनक 1, जनक 2, बच्चे []" - नामकरण

एक प्रोग्रामर में सबसे कठिन हिस्सा क्या है? चर के लिए नामों का आविष्कार करें।

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

Kinect 2.0 SDK उदाहरण

 var skeletons = new Skeleton[0]; using (var skeletonFrame = e.OpenSkeletonFrame()) { if (skeletonFrame != null) { skeletons = new Skeleton[skeletonFrame.SkeletonArrayLength]; skeletonFrame.CopySkeletonDataTo(skeletons); } } if (skeletons.Length == 0) { return; } var skel = skeletons.FirstOrDefault(x => x.TrackingState == SkeletonTrackingState.Tracked); if (skel == null) { return; } var rightHand = skel.Joints[JointType.WristRight]; XValueRight.Text = rightHand.Position.X.ToString(CultureInfo.InvariantCulture); YValueRight.Text = rightHand.Position.Y.ToString(CultureInfo.InvariantCulture); ZValueRight.Text = rightHand.Position.Z.ToString(CultureInfo.InvariantCulture); 

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

"मुझे यकीन है कि अगर डेथ को पता था कि नौकरशाही क्या है, तो लोग कभी नहीं मरेंगे, हमेशा लाइन में खड़े रहेंगे ..." - प्रलेखन

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

एसडीके में प्रलेखन आमतौर पर सरल और संक्षिप्त है। इसे आम तौर पर दो भागों में विभाजित किया जाता है: ट्यूटोरियल - "10 मिनट में एक शहर बनाएँ" और संदर्भ खंड की शैली में एक कदम-दर-चरण पाठ्यक्रम - इस एसडीके का उपयोग करके किए जा सकने वाली हर चीज का संदर्भ।

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

"- इसे साफ रखने के लिए! - मैं इसे कांटे से कैसे साफ करूंगा?" - परीक्षण

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

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

"एक पीड़िता जो अपने अतीत का विरोध नहीं कर सकती थी वह उसके द्वारा सेवन किया गया था" - लोगी

चूंकि आप एसडीके को एक थर्ड-पार्टी कंपनी को देते हैं, जिसके परिणामस्वरूप आप स्थिति पर नियंत्रण खो देते हैं, एक त्रुटि की स्थिति में (परीक्षण के चरण में आप सभी ने "यह करेंगे," ठीक है?), बल्कि एक बहुत लंबी और दर्दनाक प्रक्रिया इस बहुत त्रुटि की खोज करने के लिए इंतजार कर रही है। यह वह जगह है जहाँ लॉग आपकी सहायता के लिए आते हैं।

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

"अलार्म! अचतुंग! ध्यान!" - त्रुटियां

त्रुटियों के बारे में बहुत कुछ सोचते हुए, मैं एक दिलचस्प निष्कर्ष पर आया - आपके एसडीके में एक भी विधि को ऐसी त्रुटि नहीं देनी चाहिए जो दस्तावेज में वर्णित नहीं है । आपको स्वीकार करना होगा कि जब आप HttpRequest के साथ काम करने के लिए किसी तृतीय-पक्ष लायब्रेरी को कनेक्ट करते हैं, तो यह बहुत अप्रिय होता है, और यह आपके ऊपर कुछ NullPointerException और StackTrace फेंकता है, जो आपको लाइब्रेरी के आंतों में ले जाता है। और आपको इन बहुत ही "आंत्र" में डुबकी लगाना होगा, यह समझने की कोशिश करना कि खरगोश छेद कितना गहरा है, और वास्तव में, समस्या क्या है।

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

संस्करण या "अपनी पूंछ कैसे काटें"

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

"ए ट्रेन दैट कैन" - डिप्लॉय

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

• रिलीज रिलीज
• सभी पुस्तकालयों को संग्रह में रखता है
• प्रलेखन के नवीनतम संस्करण का निर्माण (docfx)
• दस्तावेज़ीकरण और संग्रह के नाम पर रिलीज़ संस्करण इंगित करता है
• गिट रिपॉजिटरी में सभी ताजे डालते हैं
• MS Azure पर WebApp, ताज़ा git हुक कमिट और परिवर्तन प्रकाशित करता है

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

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

"और आप ऐसा कर सकते हैं? - बकवास। देखो यह कैसे होना चाहिए!" - उदाहरण और टूलकिट

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

निष्कर्ष

एसडीके विकास मेरे लिए एक दिलचस्प नया कार्य बन गया है, जिसने कई महत्वपूर्ण वास्तु मुद्दों को उठाया है। लेख में वर्णित बहुत सी चीजें स्पष्ट चीजें हैं (मेरे लिए), लेकिन मैं स्पष्ट बड़ी तस्वीर पाने के लिए स्पष्ट चीजों की घोषणा करना भी महत्वपूर्ण मानता हूं।

पुनश्च

पढ़ने के लिए धन्यवाद, मुझे आपकी टिप्पणियों पर खुशी होगी। मुझे उम्मीद है कि यह लेख आपके लिए उपयोगी है।