जावा बनाम पैकेज बनाम प्रोजेक्ट अलगाव

Question

सबसे पहले, मैं सी # से जावा पर वापस आ रहा हूं, इसलिए क्षमा करें यदि मेरी शब्दावली या दर्शन काफी लाइन नहीं है।

यहां पृष्ठभूमि है: हमारे पास वेब के लिए लिखे गए आंतरिक समर्थन टूल का बढ़ता संग्रह है। वे बैकएंड के लिए फ्रंटएंड और जावा के लिए HTML5/AJAX/अन्य buzzwords का उपयोग करते हैं। ये उपकरण हल्के इन-हाउस फ्रेमवर्क का उपयोग करते हैं ताकि वे सुरक्षा और अन्य कॉन्फ़िगरेशन के लिए एक व्यवस्थापकीय इंटरफ़ेस साझा कर सकें। प्रत्येक उपकरण को एक अलग लेखक द्वारा लिखा गया है और मैं उम्मीद करता हूं कि प्रवृत्ति जारी रहेगी, इसलिए मैं भविष्य के लेखकों के लिए तीसरे पक्ष के पुस्तकालयों पर "मानकीकृत" रहना आसान बनाना चाहता हूं जिन्हें हमने पहले से ही चीजों के लिए उपयोग करने का निर्णय लिया है डि, इकाई परीक्षण, ORM, आदि जैसे

हमारे पैकेज नामकरण वर्तमान में इस तरह दिखता है:

• com.ourcompany.tools.framework
• com.ourcompany.tools.apps.app1name
• com.ourcompany.tools.apps.app2name

... और इसी तरह।

तो मेरा प्रश्न यह है: क्या इन ऐप्स में से प्रत्येक (और ढांचे) को मेवेन सेटअप, ग्रहण इत्यादि के उद्देश्यों के लिए एक अलग परियोजना के रूप में माना जाना चाहिए?

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

एफडब्ल्यूआईडब्ल्यू, मेरा प्रारंभिक वृत्ति उन्हें अलग करना है।

आप क्या कहते हैं, जावा गुरु?

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

मैं निश्चित रूप से अलग-अलग परियोजनाओं में इस तरह की चीजों को अलग कर दूंगा।

आपको निर्भरता/निर्माण प्रक्रिया को स्वचालित रूप से संभालने के लिए मेवेन का उपयोग करना चाहिए (दोनों अपने आंतरिक साझा पुस्तकालयों और तृतीय पक्ष निर्भरताओं के लिए)। एकाधिक अनुप्रयोगों को एक ही साझा पुस्तकालयों का संदर्भ देने में कोई समस्या नहीं होगी - यदि आपको आवश्यकता हो तो आप कई संस्करणों को भी आस-पास रख सकते हैं।

इस दृष्टिकोण से बोनस के युगल:

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

Answer 5

तो आप उन्हें एक साथ रखने के आप कम बाधाओं के विकास होगा अर्थात , अपने उपकरण का निर्माण और तैनाती।

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