आप अपनी कोड लाइब्रेरी कैसे व्यवस्थित करते हैं?

Question

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

• आप सब कुछ के लिए वर्ग पुस्तकालय परियोजनाओं के लिए हामी हैं या आप एक परियोजना में सब कुछ रखना पसंद करते हैं कार्य करें:
  उदाहरण के लिए

  ?

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

आदि

संपादित

मैं विशिष्ट मार्गदर्शन के लिए यहाँ नहीं देख रहा हूँ, मैं सिर्फ लोगों के विचारों और प्रथाओं में दिलचस्पी है। मैं विशेष रूप से एक परियोजना के बजाय अलग परियोजनाओं के बीच कोड के पुन: उपयोग में रूचि रखता हूं। (दुर्भाग्य से यहां 'प्रोजेक्ट' का उपयोग भ्रामक है - मेरा मतलब है कि ग्राहकों के लिए किए गए असली दुनिया की परियोजनाओं के बीच पुन: उपयोग करना, विजुअल स्टूडियो भावना में परियोजनाएं नहीं।)

Answer 1

यह आम तौर पर विचार तैनाती से गाइड हो सकता है:

आप कैसे तैनात होगा (यानी कि आप अपने उत्पादन मशीन पर कॉपी जाएगा)?

तो आप क्या कर रहे हैं की तैनाती पैक कर रहे हैं घटकों (अर्थात dll, जार, युद्ध, ...), यह बुद्धिमान पैक फ़ाइलों के सेट का एक संग्रह के रूप में "कोड पुस्तकालय" व्यवस्थित करने के लिए है।
इस तरह, आप सीधे - डीएलएल, जार, युद्ध, ... के साथ विकसित होंगे - जो उत्पादन मंच पर तैनात किया जाएगा।
विचार यह है: यदि यह उन पैक की गई फ़ाइलों के साथ काम करता है, तो यह अभी भी उत्पादन में काम कर सकता है।

---

भिन्न परियोजनाओं, बजाय एक एकल परियोजना के भीतर से के बीच कोड के पुन: उपयोग।

मैं बनाए रखने के पुन: उपयोग उस तरह का एक "घटक" दृष्टिकोण में आसान है

40 से अधिक मौजूदा परियोजनाओं पर (प्रश्न में "Vendor Branches in GIT" पर चर्चा की तरह), हम हासिल की:

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

सारांश:
बड़े कार्यात्मक डोमेन के लिए, एक परियोजना प्रबंधन नहीं किया जा रहा, एक अच्छा अनुप्रयोगी वास्तुकला प्राकृतिक कोड पुन: उपयोग को बढ़ावा मिलेगा।

Answer 2

यह आपके प्लेटफ़ॉर्म पर निर्भर करता है। मैं एक (गर्व) जावा डेवलपर हूं और हम अपने निर्भरता को व्यवस्थित करने के इस तरह के Maven के रूप में या Ivy

Answer 3

हम इन सिद्धांतों का पालन अच्छा उपकरण है:

• रिलीज-पुन: उपयोग समानक सिद्धांत: पुन: उपयोग की ग्रेन्युल है रिलीज का ग्रेन्युल।
• आम क्लोजर सिद्धांत: पैकेज में कक्षाओं को उसी प्रकार के परिवर्तनों के साथ एक साथ बंद किया जाना चाहिए।
• आम पुन: सिद्धांत सिद्धांत: पैकेज में कक्षाओं का एक साथ उपयोग किया जाता है।
• विश्वकोश निर्भरता सिद्धांत: पैकेज निर्भरता ग्राफ में कोई चक्र अनुमति न दें।
• स्थिर निर्भरता सिद्धांत: स्थिरता की दिशा में निर्भर करता है।
• स्थिर सार तत्व सिद्धांत: एक पैकेज यथासंभव स्थिर होना चाहिए क्योंकि यह स्थिर है।

आप here और here से अधिक पा सकते हैं।

Answer 4

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