शर्मनाक ढंग से मैंने एक "आम" लाइब्रेरी शुरू की, जिसका नाम कुछ दशक पहले टीम के माहौल में रखा गया था। मैं वास्तव में गतिशीलता को तब समझ नहीं पाया था, जब कुछ ही महीनों में शिथिल-समन्वित टीम सेटिंग में क्या हो सकता है।
जब मैंने इसे पेश किया तो मुझे लगा कि मैंने इसे स्पष्ट कर दिया है और यह भी दस्तावेज किया है कि यह उन चीजों के लिए है जो हम सभी सहमत हैं कि हम दैनिक आधार पर उपयोगी पाते हैं, यह एक न्यूनतम पुस्तकालय होने का इरादा है, और यह कि पुस्तकालय को इसके अलावा और कुछ पर निर्भर नहीं होना चाहिए मानक पुस्तकालय ताकि नई परियोजनाओं में संभव के रूप में तैनात करना आसान हो। उस समय मेरी सोच यह थी कि चीजों के लिए मानक पुस्तकालय के लिए हमारा अपना थोड़ा विस्तार था, जो हमारे विशेष डोमेन में, हमने दैनिक आधार पर उपयोगी पाया।
और यह काफी अच्छी तरह से शुरू हुआ। हमने common/math*दिनचर्या के एक गणित पुस्तकालय ( ) के साथ शुरू किया था, जिसका उपयोग हम सभी दैनिक आधार पर करते थे, क्योंकि हम कंप्यूटर ग्राफिक्स में काम कर रहे थे जो अक्सर रैखिक बीजगणित पर भारी होता था। और चूंकि हम अक्सर सी कोड के साथ हस्तक्षेप कर रहे थे, इसलिए हम find_indexइसके विपरीत कुछ उपयोगी उपयोगिता कार्यों पर सहमत हुएstd::findC ++ में, एक अनुक्रम में पाए जाने वाले तत्व के एक इंडेक्स को पुनरावृत्ति के बजाय लौटाएगा, जिसने नकल की कि हमारा C कैसे काम करता है - इस प्रकार की चीजें - थोड़ा सा उदार लेकिन कम से कम और व्यापक रूप से सभी के लिए परिचित और व्यावहारिक बने रहने के लिए पर्याप्त रूप से उपयोग किया जाता है , और तत्काल परिचितता एक अत्यंत महत्वपूर्ण मानदंड है क्योंकि मैं इसे "सामान्य" या "मानक" कुछ भी बनाने की कोशिश में देखता हूं क्योंकि यह वास्तव में "सामान्य" है, इसके व्यापक रूप में इसके बारे में यह परिचित गुण होना चाहिए गोद लेने और दैनिक उपयोग।
लेकिन समय के साथ पुस्तकालय के डिज़ाइन के इरादे मेरी उंगलियों से फिसल गए क्योंकि लोगों ने व्यक्तिगत रूप से इस्तेमाल होने वाली चीजों को जोड़ना शुरू कर दिया था, उन्होंने सोचा था कि यह किसी और के लिए उपयोग हो सकता है, केवल इसका उपयोग करने वाला कोई और नहीं मिल सकता है। और बाद में किसी ने सामान्य जीएल-संबंधित दिनचर्या के लिए ओपनजीएल पर निर्भर होने वाले कार्यों को जोड़ना शुरू कर दिया। इसके अलावा हमने Qt को अपनाया और लोगों ने Qt पर निर्भर कोड जोड़ना शुरू किया, इसलिए पहले से ही सामान्य पुस्तकालय दो बाहरी पुस्तकालयों पर निर्भर था। कुछ बिंदु पर किसी ने सामान्य shader दिनचर्या जोड़ी जो हमारे एप्लिकेशन-विशिष्ट shader लाइब्रेरी पर निर्भर थी, और उस समय आप इसे Qt, OGL और हमारे एप्लिकेशन-विशिष्ट shader लाइब्रेरी और लेखन के बिना एक नई परियोजना में भी तैनात नहीं कर सकते थे आपके प्रोजेक्ट के लिए एक गैर-तुच्छ बिल्ड स्क्रिप्ट। तो यह इस उदार, अन्योन्याश्रित गंदगी में बदल गया।
लेकिन मुझे इस बात पर बहस करने से भी मिला कि इस लाइब्रेरी में क्या जाना चाहिए और क्या नहीं कि जिसे "आम" माना जाता है वह बहुत ही व्यक्तिपरक विचार में आसानी से बदल सकता है यदि आप एक बहुत ही कठिन नियम को निर्धारित नहीं करते हैं कि "सामान्य" क्या है हर कोई दैनिक आधार पर उपयोगी खोजने के लिए क्या करता है। मानकों के किसी भी ढील और यह जल्दी से चीजों से हर किसी को अपमानित करता है हर कोई एक दैनिक डेवलपर के लिए उपयोगी पाता है एक एकल डेवलपर उपयोगी पाता है जो किसी और के लिए फायदेमंद होने की संभावना हो सकती है, और उस बिंदु पर पुस्तकालय एक उदार गड़बड़ में तेजी से घटता है ।
लेकिन इसके अलावा जब आप उस बिंदु तक पहुंचते हैं, तो कुछ डेवलपर्स साधारण कारण से चीजों को जोड़ना शुरू कर सकते हैं जो उन्हें प्रोग्रामिंग भाषा पसंद नहीं है। वे लूप या फ़ंक्शन कॉल के सिंटैक्स को पसंद नहीं कर सकते हैं, जिस बिंदु पर लाइब्रेरी उन चीजों से भरा होना शुरू कर रही है जो भाषा के मूल सिंटैक्स से लड़ रहे हैं, सीधे कोड की कुछ पंक्तियों की जगह जो वास्तव में नहीं है किसी भी तर्क को विदेशी कोड की एक एकल पंक्ति के लिए नीचे डुप्लिकेट करना केवल उस डेवलपर से परिचित है जिसने इस तरह के शॉर्टहैंड को पेश किया था। फिर ऐसे डेवलपर ऐसे शॉर्टहैंड का उपयोग करके कार्यान्वित सामान्य पुस्तकालय में अधिक कार्यक्षमता जोड़ना शुरू कर सकते हैं, जिस बिंदु पर आम पुस्तकालय के महत्वपूर्ण हिस्से इन विदेशी शॉर्टहैंड्स के साथ परस्पर जुड़ जाते हैं, जो उस डेवलपर को सुंदर और सहज लग सकता है, जिसने इसे पेश किया, लेकिन बदसूरत और विदेशी और हर किसी के लिए समझना मुश्किल है। और उस बिंदु पर मुझे लगता है कि आप जानते हैं कि किसी चीज को वास्तव में "सामान्य" बनाने की कोई उम्मीद खो जाती है, क्योंकि "आम" और "अपरिचित" ध्रुवीय विपरीत विचार हैं।
तो वहाँ कीड़े के सभी प्रकार के डिब्बे हैं, कम से कम एक कम-समन्वित टीम के वातावरण में, एक पुस्तकालय जिसमें महत्वाकांक्षाएं व्यापक हैं और सामान्य रूप से "सामान्य रूप से उपयोग किए जाने वाले सामान" के रूप में। और जबकि अंतर्निहित समस्या अन्य सभी के ऊपर ढीला समन्वय हो सकता है, कम से कम कई पुस्तकालयों के लिए एक अधिक विलक्षण उद्देश्य की सेवा करना है, जैसे कि एक पुस्तकालय गणित दिनचर्या प्रदान करने का इरादा रखता है और कुछ नहीं, संभवतः इसके संदर्भ में उतने महत्वपूर्ण रूप से अस्वीकार नहीं करेगा। एक "आम" पुस्तकालय के रूप में डिजाइन शुद्धता और निर्भरता। तो पूर्वव्यापी में मुझे लगता है कि पुस्तकालयों के पक्ष में गलती करने के लिए बेहतर होगा जो कि अधिक स्पष्ट डिजाइन इरादे हैं। मैंने उन वर्षों में भी पाया है कि उद्देश्य में संकीर्ण और प्रयोज्यता में संकीर्ण मौलिक रूप से भिन्न विचार हैं।
इसके अलावा, मैं कम से कम थोड़ा अव्यवहारिक और देखभाल शायद सौंदर्यशास्त्र के बारे में बहुत अधिक है, लेकिन जिस तरह से मैं एक पुस्तकालय की गुणवत्ता के बारे में अपने विचार को महसूस करता हूं (और शायद "सौंदर्य") को उसके सबसे कमजोर लिंक से भी अधिक आंका जाता है। इसकी सबसे मजबूत, इसी तरह से कि अगर आपने मुझे दुनिया में सबसे अधिक स्वादिष्ट भोजन पेश किया लेकिन, उसी प्लेट पर, वहाँ पर कुछ सड़ रहा है जो वास्तव में बुरी तरह से बदबू आ रही है, मैं पूरी प्लेट को अस्वीकार करना चाहता हूं। और अगर आप मेरे बारे में उस तरह से हैं और ऐसा कुछ बनाते हैं जो सभी प्रकार के परिवर्धन को आमंत्रित करता है जैसा कि कुछ "सामान्य" कहा जाता है, तो आप अपने आप को उस अनुरूप प्लेट को देखने के लिए पा सकते हैं, जो पक्ष में कुछ सड़ रहा है। तो इसी तरह मुझे लगता है कि यह अच्छा है अगर एक पुस्तकालय को व्यवस्थित और नामित किया जाए और उसे इस तरह से प्रलेखित किया जाए कि वह ऐसा न करे ' t समय के साथ अधिक से अधिक परिवर्धन को आमंत्रित करें। और यह कि आपकी व्यक्तिगत रचनाओं पर भी लागू हो सकता है, क्योंकि मैंने निश्चित रूप से यहाँ और वहाँ कुछ सड़ा हुआ सामान बनाया है, और अगर यह सबसे बड़ी प्लेट में नहीं जोड़ा जा रहा है, तो यह बहुत कम "taints" करता है। छोटी, बहुत विलक्षण पुस्तकालयों में चीजों को अलग करने से बेहतर कूट कूट की प्रवृत्ति होती है, यदि केवल इतना ही गुण हो कि सब कुछ युग्मित करना शुरू करना कहीं कम सुविधाजनक हो जाता है।
कोड डिडुप्लीकेशन मुझ पर वर्षों से अंकित किया गया है, लेकिन मुझे लगता है कि मुझे इस बार इसके लिए प्रयास करना चाहिए।
आपके मामले में मैं जो सुझाव दे सकता हूं, वह कोड कटौती पर आसान लेना है। मैं खराब-परीक्षण किए गए, त्रुटि-प्रवण कोड या इस प्रकार के किसी भी चीज़ के बड़े स्निपेट को कॉपी और पेस्ट करने के लिए नहीं कह रहा हूं, या बड़ी मात्रा में गैर-तुच्छ कोड की नकल कर रहा हूं जिसमें भविष्य में परिवर्तन की आवश्यकता होने की संभावना है।
लेकिन विशेष रूप से यदि आप एक "सामान्य" पुस्तकालय बनाने की मानसिकता के हैं, जिसके लिए मैं आपकी इच्छा को व्यापक रूप से लागू, अत्यधिक पुन: प्रयोज्य, और शायद आदर्श रूप से कुछ ऐसा बनाना चाहता हूं जो आपको आज से एक दशक बाद ही मिल जाए। , तो कभी-कभी आपको इस मायावी गुणवत्ता को प्राप्त करने के लिए कुछ दोहराव की भी आवश्यकता हो सकती है। क्योंकि दोहराव वास्तव में एक decoupling तंत्र के रूप में काम कर सकता है। यह ऐसा है जैसे अगर आप किसी वीडियो प्लेयर को MP3 प्लेयर से अलग करना चाहते हैं, तो आपको कम से कम बैटरी और हार्ड ड्राइव जैसी कुछ चीजों की नकल करनी होगी। वे इन चीजों को साझा नहीं कर सकते हैं या फिर वे अविभाज्य रूप से युग्मित हैं और एक-दूसरे का स्वतंत्र रूप से उपयोग नहीं किया जा सकता है, और उस समय लोगों को डिवाइस में कोई दिलचस्पी नहीं हो सकती है यदि वे सब करना चाहते हैं तो एमपी 3 प्ले करें। लेकिन कुछ समय बाद जब आप इन दो उपकरणों को अलग कर देते हैं, तो आप पा सकते हैं कि एमपी 3 प्लेयर एक अलग बैटरी डिज़ाइन या वीडियो प्लेयर की तुलना में छोटे हार्ड ड्राइव से लाभ उठा सकता है, जिस बिंदु पर आप अब कुछ भी दोहरा नहीं रहे हैं; इस अंतः निर्भर उपकरण को दो अलग-अलग में विभाजित करने की अनुमति देने के लिए शुरू में दोहराव के रूप में क्या शुरू हुआ, स्वतंत्र डिवाइस बाद में डिजाइन और कार्यान्वयन के लिए निकल सकते हैं जो अब बिल्कुल बेमानी नहीं हैं।
यह एक पुस्तकालय का उपयोग करने के दृष्टिकोण से चीजों पर विचार करने के लायक है। क्या आप वास्तव में उपयोग करना चाहेंगेएक पुस्तकालय जो कोड दोहराव को कम करता है? संभावना है कि आप ऐसा नहीं करेंगे क्योंकि जो करता है वह स्वाभाविक रूप से अन्य पुस्तकालयों पर निर्भर करेगा। और वे अन्य पुस्तकालय अपने कोड को डुप्लिकेट करने से बचने के लिए अन्य पुस्तकालयों पर निर्भर हो सकते हैं, और इसी तरह, जब तक कि आपको कुछ बुनियादी कार्यक्षमता लोड करने और ऑडियो फ़ाइल चलाने जैसी केवल 50 बुनियादी पुस्तकालयों को आयात / लिंक करने की आवश्यकता नहीं हो सकती है, और यह बहुत ही बेकार है । इस बीच अगर इस तरह की ऑडियो लाइब्रेरी ने जानबूझकर अपनी आज़ादी हासिल करने के लिए कुछ चीज़ों को यहाँ-वहाँ डुप्लिकेट करने के लिए चुना, तो नए प्रोजेक्ट्स में इस्तेमाल करना इतना आसान हो जाता है, और संभावना है कि जीतने के बाद से इसे लगभग अपडेट करने की ज़रूरत नहीं होगी ' टी को अपने आश्रित बाहरी पुस्तकालयों को बदलने के परिणामस्वरूप बदलने की आवश्यकता है जो ऑडियो लाइब्रेरी की आवश्यकता से बहुत अधिक सामान्यीकृत उद्देश्य को पूरा करने की कोशिश कर सकते हैं।
इसलिए कभी-कभी यह जानबूझकर थोड़ा सा नक़ल करने के लिए चुनना होता है (होश में, आलस्य से बाहर कभी नहीं - वास्तव में परिश्रम से बाहर) एक पुस्तकालय को डिकूप करने के लिए और इसे स्वतंत्र बनाने के लिए क्योंकि उस स्वतंत्रता के माध्यम से, यह व्यावहारिक प्रयोज्यता की एक विस्तृत श्रृंखला प्राप्त करता है और यहां तक कि स्थिरता (कोई और अधिक साहसी कपलिंग)। यदि आप सबसे पुन: प्रयोज्य पुस्तकालयों को डिज़ाइन करना चाहते हैं जो आपको एक परियोजना से अगले और पिछले कुछ वर्षों में बनाएंगे, तो इसके दायरे को न्यूनतम करने के लिए, मैं वास्तव में यहां थोड़ा सा नकल करने पर विचार करने का सुझाव दूंगा। और स्वाभाविक रूप से इकाई परीक्षण लिखें और सुनिश्चित करें कि यह वास्तव में पूरी तरह से परीक्षण किया गया है और यह क्या कर रहा है पर विश्वसनीय है। यह केवल उन पुस्तकालयों के लिए है जिन्हें आप वास्तव में एक बिंदु तक सामान्य करने के लिए समय लेना चाहते हैं जो एक ही परियोजना से बहुत आगे निकल जाता है।