मैं कोड पुन: उपयोग पुस्तकालय कैसे बना और बनाए रखूं?

Question

मैं पुन: प्रयोज्य कोड का एक संग्रह स्थापित करने की कोशिश कर रहा हूं। मैं प्रत्येक पुन: प्रयोज्य कोड मॉड्यूल के बारे में सोच रहा था कि एक निश्चित "परिपक्वता स्तर" रेटिंग है। रेटिंग को उस स्तर के रूप में परिभाषित किया जाएगा जिस पर एक पुन: प्रयोज्य कोड आवश्यकताओं के एक निश्चित सेट के भीतर है। उच्चतम परिपक्वता स्तर आवश्यकताओं के एक पूर्वनिर्धारित सेट में मानक की उच्चतम डिग्री होगी।

उदाहरण के लिए:
स्तर; आवश्यकताओं; विवरण
स्तर 0; कोड का उपयोग करने के लिए कानूनी है; क्या व्यावसायिक उद्योग/कई अनुबंधों/आदि में कोड का उपयोग कानूनी है?
स्तर 1; आधार कोडलाइन और स्तर 0 आवश्यकताओं को पूरा करता है; प्रोटोटाइप कोड, तृतीय पक्ष उपकरण, आदि
स्तर 2; फंक्शन इंटरफ़ेस और टिप्पणियां हैं और स्तर 1 आवश्यकताओं को पूरा करती हैं; प्रत्येक वर्ग और समारोह के लिए पर्याप्त दस्तावेज; टिप्पणियों से कार्यक्षमता निर्धारित करने में सक्षम
स्तर 3; कोडिंग मानकों का पालन करता है और स्तर 2 आवश्यकताओं को पूरा करता है; अनुयायियों को कोडिंग मानकों को परिभाषित किया गया है और कोड जांच उपयोगिता परीक्षण
स्तर 4 पास करता है; परीक्षण मामलों को शामिल करता है और स्तर 3 आवश्यकताओं को पूरा करता है; कोड
स्तर 5 की सभी कार्यक्षमता का परीक्षण करने के लिए पर्याप्त परीक्षण मामले हैं; पुन: उपयोग समिति द्वारा स्वीकृत और स्तर 4 आवश्यकताओं को पूरा करता है; पुन: उपयोग के विशेषज्ञों और साथियों द्वारा की समीक्षा की और सत्यापित यह

मैं सोच रहा हूँ परिपक्वता के सभी स्तरों को पूरा करती है कि अगर यह परिपक्वता का स्तर एक सौपानिक संरचना, जहां आदेश को अगले स्तर तक ले जाने के लिए आप सभी की आवश्यकताओं को पूरा करने की जरूरत है होना चाहिए पिछले स्तर (जैसा कि मैंने ऊपर दिखाया है)?

या यदि यह अगले स्तर को पूरा करने के लिए आवश्यकताओं का सबसेट होना चाहिए?

उदाहरण के लिए, हमने वाई आवश्यकताओं में से एक्स को पूरा किया है, हम अगले स्तर पर जा सकते हैं (आवश्यकताएं उपर्युक्त के अनुसार समान होंगी)।

स्तर 0, 6 आवश्यकताओं
स्तर 1 से बाहर 0 से मिलता है, 6 आवश्यकताओं
में से 1 को पूरा करती है ...

समस्या मैं सबसेट दृष्टिकोण के साथ देखते हैं

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

क्या किसी ने इससे पहले किया है, और यदि हां, तो आपने अपनी लाइब्रेरी कैसे सेट की? क्या आपके पास परिपक्वता स्तर बिल्कुल या कुछ अन्य संरचना है? कोई भी इनपुट बहुत प्रंशसनीय होगा।

Answer 1

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

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

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

संचार की रेखाओं के साथ, यह समय-समय पर मौजूद होने के लिए बिल्कुल भी चोट नहीं पहुंचाता है। फिर! संचार।

तो, कम से कम प्रत्येक पुस्तकालय के अपने निर्माण करना चाहिए:

• पुस्तकालय प्रकाशित (शायद ग्राहकों को सूचित)
• प्रलेखन प्रकाशित
• रन इकाई परीक्षण
• परिपक्वता के स्तर प्रकाशित

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

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

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

Answer 2

मुझे लगता है कि आप किसी भी समस्या में बहुत ज्यादा सोच रहे हैं।

आपने मेरी लाइब्रेरी कैसे सेट की? आसान, यदि आप दो या दो से अधिक परियोजनाओं में समान (या लगभग वही) विधि का उपयोग करते हैं, तो उसे लाइब्रेरी में ले जाएं।

Answer 3

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

यहाँ ग में मेरे पुस्तकालय ++
http://code.google.com/p/kgui/

Answer 4

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

एक दृष्टिकोण मैं एक बड़ी कंपनी में ठीक काम कर रहा देखा यह है:

• सभी तृतीय पक्ष लाइब्रेरी एक विशेष निर्देशिका के लिए प्रतिबद्ध हैं और हमेशा एक संस्करण संख्या में शामिल हैं।
• हमारे स्वयं के सामान्य पुस्तकालय संदर्भ के आधार पर विभाजित हैं, उन्हें अन्य चीजों के लिए है। जैसे यदि उपयोगिता कोड Infragistics लाइब्रेरी का संदर्भ देता है तो उपयोगिता कोड का यह बिट InfragisticsUtils लाइब्रेरी में जाता है।
• हमारे स्वयं के सामान्य पुस्तकालय जो स्पष्ट रूप से पहचाने जाने योग्य "इकाइयां" अलग पुस्तकालयों में जाते हैं। उदाहरण के लिए, मूल्य निर्धारण प्रतिभूतियों से संबंधित कोड की एक लाइब्रेरी एक अलग परियोजना है।
• सभी पुन: प्रयोज्य कोड जो ऊपर दिए गए किसी भी को संतुष्ट नहीं करते हैं, सभी Utilities प्रोजेक्ट में कैच में जाते हैं।
• हमारे स्वयं के पुस्तकालय संकलित और एक साझा स्थान पर जारी किए जाते हैं जहां परियोजनाएं उनका संदर्भ दे सकती हैं। यह परियोजनाओं की विकास टीम पर निर्भर है कि वे एक संकलित बाइनरी का संदर्भ लेना चाहते हैं या सिर्फ उपयोगिता परियोजना को उनके समाधान में शामिल करना चाहते हैं।

जाहिर है आप कैच-ऑल Utilities पुस्तकालय में मिल कोड की गुणवत्ता में काफी भिन्न हो सकते हैं। इसे कम करने के लिए हमने बस यह सुनिश्चित किया कि विभिन्न विकास टीमों के दो लोगों ने सभी चेकइन की समीक्षा Utilities पर की। यह बहुत सारी चीजें निकाल देता है जिसमें कोई जगह नहीं है!

Answer 5

इसे अपनी खुद की लाइब्रेरी रखने के लिए अच्छा दृष्टिकोण माना जाता है, लेकिन हजारों लाइनें एक बर्बाद है!

Answer 6

विल ट्रैक्स के "प्रयुक्त प्रोग्राम सेल्समैन के कन्फेशंस" और एचपी के पुन: उपयोग रब्बी, मार्टिन ग्रीस द्वारा सामान देखें।

Answer 7

सालों से माइक्रोसॉफ्ट software factories के नाम से जाना जाने वाला एक बड़ा वकील रहा है, जिसका एक बड़ा हिस्सा पुन: उपयोग की समस्याओं को हल करने के लिए समर्पित है।

पुन: उपयोग की क्या समस्याएं हैं? सबसे पहले, यह मुश्किल है। लाइब्रेरी और एपीआई के साथ आने में बहुत मुश्किल है जो परियोजना की तत्काल जरूरतों से परे काम करेगा। भविष्य की भविष्यवाणी कैसे करते हो? इसके अलावा, एक केंद्रीकृत भंडार की समस्या जो ज्ञान आधार और अभ्यास के जीवंत समुदाय दोनों के रूप में कार्य करती है वह बहुत ही चुनौतीपूर्ण है। आप कुछ ऐसा कैसे करते हैं जो बहुत ही लचीला अभी तक उपयोग में आसान है? कई ने कोशिश की है और असफल रहा है। software factories और software product lines दोनों इन समस्याओं का समाधान करने का प्रयास करते हैं।

गुड लक!

Answer 8

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

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

शायद कोई व्यक्ति उस कोड का टुकड़ा लेता है और टिप्पणियां जोड़ता है और इसे मानकों तक लाता है। तब वह व्यक्ति इसे \ sw_repository \ level1 \ examplePrototype में रखेगा।

फिर वही व्यक्ति, थोड़ी देर बाद, उदाहरणप्रोटोटाइप के लिए यूनिट परीक्षण बनाता है। यह तब स्तर 2 पर जायेगा और इसी तरह।

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

Answer 9

किट ने का उल्लेख सबसे महत्वपूर्ण समस्या: पुन: उपयोग। बाकी का विचार अच्छा है, लेकिन यह एक विस्तार से अधिक नहीं है।

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

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

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

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

सिर्फ मेरी 2 सेंट ...;)