मेरा प्रथम श्रेणी पुस्तकालय शिपिंग। किसी भी गोच मैं के बारे में पता होना चाहिए?


12

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

यहाँ मैं यहाँ हूँ:

  • लाइब्रेरी यूनिट का परीक्षण किया गया है और इसमें लगभग 97% कोड कवरेज है
  • एपीआई अच्छी तरह से प्रलेखित है और इंटेलीजेंस समर्थन के लिए xml डॉक्स बनाए गए हैं
  • मैंने यह सुनिश्चित किया है कि सार्वजनिक / निजी वर्ग के एक्सेसर्स सही और सही हों। वही सभी गेटर्स / सेटर के लिए जाता है
  • त्रुटि से निपटने के रूप में सुंदर नहीं है जैसा कि मैं इसे होना चाहता हूं, लेकिन मैं एक समय सीमा के खिलाफ हूं और स्वीकार किया है कि इसका "अभी भी उतना ही अच्छा" होने जा रहा है।
  • कोई मित्रवत प्रवेश नहीं। Debug.Writeline बड़े पैमाने पर इस्तेमाल किया गया था ... मैंने हाल ही में सीखा है कि यह मेरी अनुभवहीनता का प्रतिबिंब है :(

आपकी सलाह की बहुत सराहना की जाती है!

लाइब्रेरी का उपयोग रिपोर्ट बनाने के लिए किया जाएगा। मानक टोपी - आसानी से डेटाबेस से जुड़ता है, प्रतिक्रिया की धारा के लिए डेटा और आउटपुट आउटपुट कैलक्स करता है।


मुझे प्रोग्रामर में से एक को छोड़ने के लिए फ्रिंज संसाधन के रूप में टैप किया गया था, और यह कार्य मुझे "आपके दांत काट" ​​प्रोजेक्ट के रूप में दिया गया था। प्रोडक्शन कोड लिखने के दौरान कंपनी के अन्य प्रोग्रामर के लिए क्लास लाइब्रेरी जारी की जाएगी।


2
विवरण चाहिए, कैसे जारी करें? बिक्री के लिए जारी? साझा करने के लिए ओपन-सोर्स जारी करें? एक अनुबंध पर एक ग्राहक के लिए जारी आप पर हैं? अपने पूर्णकालिक नियोक्ता के लिए एक परियोजना के हिस्से के रूप में अपने बाकी विकास संगठन को जारी करना? अपने पूर्णकालिक नियोक्ता के लिए ग्राहक की उपलब्धता के लिए एक नए उत्पाद के v1.0 के रूप में जारी करना?
जिमी हॉफ

@ जिमीहॉफ्ता: आपके सवालों के जवाब जोड़े। समय निकालने के लिए धन्यवाद!
श्री जावास्क्रिप्ट

1
आप यह कैसे काम करता है की कोई जानकारी नहीं के साथ पुस्तकालय के एक उपयोगकर्ता के बहाने हैं। इसका उपयोग कुछ बनाने के लिए करें। अनुभव के आधार पर चीजों को बदलना / हटाना / जोड़ना। फिर इसे वास्तविक उपयोगकर्ताओं के लिए जारी करें और उनकी प्रतिक्रिया प्राप्त करें।
mike30

शायद ऑफ़लाइन (ish) संदर्भ सामग्री रखने के लिए सैंडकास्टल या अन्य डॉक्टर-जनरेटिंग लाइब्रेरी का उपयोग करें?
जेसी सी। स्लीकर

7
आराम करें। यहां तक ​​कि एक एकल इकाई परीक्षण और एपीआई प्रलेखन की एक भी पंक्ति पहले से ही इस रिलीज़ को ~ 95% से ऊपर "कंपनी में अन्य प्रोग्रामर के लिए उपयोग करने के लिए जारी", मेरे अनुभव में ऊपर उठाती है।
कार्सन 63000 20

जवाबों:


8

एपीआई में लॉक-इन

एक एपीआई को प्रभावी ढंग से बनाने की कला अपेक्षाओं के प्रबंधन के बारे में अधिक है क्योंकि यह संरचना के बारे में है।

जब मैं कहता हूं कि एपीआई मैं विशेष रूप से यह उल्लेख कर रहा हूं कि सार्वजनिक / आंतरिक वर्गों / विधियों का नाम कैसे लिया जाता है और उनका पहुंच स्तर क्या है (अर्थात निजी / सार्वजनिक / आंतरिक)।

यदि आप चिंतित हैं कि कोड प्राइम-टाइम के लिए पूरी तरह से तैयार नहीं हो सकता है तो आप इसे हमेशा बीटा के रूप में प्रकाशित कर सकते हैं।

विज्ञप्ति:

  • बीटा (पूर्व 1.0)

    • कई एपीआई ब्रेकिंग परिवर्तन हो सकते हैं
    • संस्करणों के बीच पीछे की ओर संगतता परिवर्तन की कमी हो सकती है
    • पॉलिश की कमी हो सकती है
  • आधिकारिक (1.0+)

    • अगली बड़ी रिलीज तक एपीआई लॉक है
    • शुरू किए गए किसी भी परिवर्तन को पिछड़ी संगतता की गारंटी देनी चाहिए
  • मामूली (पूर्व 1.1)

    • बग फिक्स और या सुविधा कार्यान्वयन शामिल हैं
    • ऐड-इन कर सकते हैं, लेकिन परिभाषित एपीआई से दूर नहीं

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

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

यह कैसे उपयोग किया जाएगा के बारे में आपकी धारणाएं गलत हैं

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

इसे संभालने का एक तरीका यह है कि एक्सेसर्स (यानी निजी / सार्वजनिक / आंतरिक) का उपयोग करके जितना संभव हो उतना कार्यान्वयन को बंद कर दिया जाए, लेकिन डिज़ाइन या इंजीनियरिंग की कोई भी राशि आपको उपयोगकर्ताओं को कोड जारी करने के लिए उतनी अंतर्दृष्टि नहीं देगी।

यह वास्तव में कोई फर्क नहीं पड़ता है कि आपको लगता है कि 'सही' कैसे आपका कोड बन सकता है, आपके उपयोगकर्ता यह साबित करेंगे कि यह नहीं है।

मैं तर्क दूंगा कि यह एक प्राथमिक कारण है कि एक मौजूदा कोडबेस का उपयोग करना हमेशा बेहतर होता है बजाय एक पूर्ण पुनर्लेखन के। कम से कम एक पूर्ण पुनर्लेखन में ब्लोट ट्रिम हो जाएगा लेकिन एक उच्च संभावना है कि नए कोडबेस में मूल कोडबेस के रूप में कई (और संभवतः अधिक) बग होंगे।

आपके मामले में आप स्क्रैच से लड़ाई-सख्त हो रहे हैं ताकि आप शुरू कर सकें।


ऐसा लगता है कि आपके पास अपने बाकी के ठिकाने हैं। एपीआई प्रलेखन महत्वपूर्ण है और भविष्य में परिवर्तन होने पर स्थिरता सुनिश्चित करने के लिए परीक्षण अच्छे होंगे।

कोड के उत्पादन के लिए जारी होने से पहले एक सुसंगत लॉगिंग योजना को लागू करना महत्वपूर्ण होगा क्योंकि आपको लॉग को वैश्विक रूप से सक्षम / अक्षम / फ़िल्टर करने की आवश्यकता होगी। BTW, ज्यादातर मामलों में लॉगिंग में वास्तव में एक पुस्तकालय आयात करना और Debug.WriteLine () से कुछ लॉगिंग .ebug (), Logging.Info (), Logging.Error () जैसे आउटपुट कॉल को बदलना शामिल है। लकड़हारा खुद ही विन्यास, फ़िल्टरिंग और आउटपुट स्कीमों की व्यापक रेंज (पूर्व फाइलें, कंसोल, आदि) के लिए एक मानक कार्यान्वयन प्रदान करता है।

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


1
+1 पुन: लॉगिंग - मैं अत्यधिक TraceSource की सलाह देता हूं । यह किसी भी बाहरी निर्भरता का परिचय नहीं देता है क्योंकि यह कोर .NET लाइब्रेरी का हिस्सा है और यह उपयोगकर्ताओं को श्रोताओं को संलग्न करने और कोड के माध्यम से और app.config फ़ाइलों के माध्यम से दोनों को कॉन्फ़िगर करने की अनुमति देता है।
Dan Lyons

4

ये दो चीजें हैं जो मुझे लगती हैं सॉफ्टवेयर जारी करने की कुंजी:

  • जानिए आपने क्या जारी किया है
  • अपेक्षाओं को प्रबंधित करें

आप चाहते हैं कि जो आपने जारी किया है, वह वापस और बग फिक्स कर सके और आप चाहते हैं कि लोग यह समझें कि आपका कोड क्या समस्या हल करेगा।

यह जानते हुए कि आपने क्या जारी किया है

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

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

सुनिश्चित करें कि आपके पास कोई अंतिम दस्तावेज है, जिसमें दस्तावेज़ीकरण शामिल है। सॉफ्टवेयर जारी करने और कुछ याद करने के बारे में नर्वस या उत्साहित होना बहुत आसान है।

उम्मीदों का प्रबंधन

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

दस्तावेज़ कैसे आप प्रतिक्रिया, अच्छा या बुरा चाहते हैं। जैसा कि यह एक आंतरिक परियोजना है, अगर सभी के पास एक सामान्य बग ट्रैकिंग सिस्टम तक पहुंच है, तो उन्हें उचित परियोजना के खिलाफ बग दर्ज करने के लिए कहें।

भविष्य में, यदि संभव हो तो एपीआई को बदलने से बचें, यह एक ऐसी चीज है जिसमें आपके ग्राहकों को नाराज करने की क्षमता है। याद रखें कि अपवाद API का हिस्सा हैं, भले ही C # में वे विधि प्रलेखन का हिस्सा नहीं हैं। यह हो सकता है अपवाद एक बाद की तारीख में फेंक दिया जा रहा है सुधार करने के लिए संभव हो सकता है, लेकिन आप अंत उपयोगकर्ताओं के लिए बात करते हैं और देखते हैं कि क्या प्रभाव यह होगा की आवश्यकता होगी।


0

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

सामान्य:

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

.Net विशिष्ट:

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