जावा प्रोजेक्ट बहुत बड़ा हो रहा है

Question

हमारे पास एक बड़ा जावा 8 स्प्रिंग हाइबरनेट मेवेन प्रोजेक्ट है जो बड़ा हो रहा है।

समस्याएं:

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

अब

• परियोजना के बारे में 20 Maven मॉड्यूल में कॉन्फ़िगर किया गया है, तो लगता है कि हम कैसे काम:

 
    Parent 
    |--- Tier1 
    |--- Tier2 
    |--- WebTier 
     |---- ModuleA 
     |---- ModuleB 
     |---- ModuleC 
     |---- ... 
     |---- Entities 
     |---- Shared 
     |---- Batch 
     |---- IntegrationTests 

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

विचार इसे बेहतर बनाने के

• एक MessageBroker मॉड्यूल जोड़ें जहां प्रासंगिक ढीले युग्मन को अनुमति दें। हो सकता है कि JMS, या बस तुल्यकालिक संचार
• के लिए एक गूंगा में स्मृति घटक Shared मॉड्यूल से छुटकारा
• यकीन है कि मॉड्यूल मोटे सुक्ष्म प्रवेश अंक
• भाई बहन के बीच अवांछित युग्मन निकालें और संदेश दलाल जब पसंद करते हैं बनाओ संभव
• Entities रख सकते हैं। कम से कम कोर-बिजनेस इकाइयां (ग्राहक, ग्राहकफाइल, ...)। लेकिन कुछ संस्थाओं स्पष्ट रूप से एक भी मॉड्यूल के हैं (एक बैच निष्पादन की जानकारी Batch मॉड्यूल में होगा)

इस तरह, ModuleA में एक परिवर्तन कर किसी को भी समय की सबसे केवल निर्माण और बिना कि मॉड्यूल में रन परीक्षण होगा आवेदन तोड़ने से डरते हुए।

प्रश्न

• करता है कि एक अच्छी योजना की तरह लग?अच्छा, मैं भविष्य प्रूफ मतलब है, के साथ अच्छे अवसरों को चीजों में सुधार करने, और काम का अत्यधिक मात्रा में स्थिति को देखते हुए की जरूरत नहीं
• हम टियर 1 प्रति ग्रहण/IJ परियोजना, आईडीई शिल्पकृति का निर्माण और यह तैनात जाने होना चाहिए टोमकैट के लिए, या हमारे पास प्रति मॉड्यूल 1 प्रोजेक्ट, और नेक्सस की निर्भरता होनी चाहिए? या शायद बाद का विकल्प अधिक है?
• कोई अन्य सुझाव?

कुछ मीट्रिक

• विंडोज 7, जावा 8, Maven 3.0.3, TestNG।
• एसएसडी या 7200rpm HDD के (सीमित प्रभाव)
• 6Gb रैम
• ढेर 1GB (Maven) जेनकींस

साथ

सीआई

धन्यवाद एक गुच्छा!

Answer 1

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

Answer 2

यह के रूप में बुरा के रूप में आपको लगता है नहीं हो सकता है। यूनिट परीक्षणों और स्थैतिक विश्लेषण के साथ शामिल परियोजनाओं में कुछ समय लगता है।

एक कंपनी मैं था> 1 ghante निर्माण + unittest + CodeCoverage एकीकरण समय के लिए काम किया। यह 26 भाषाओं x 8 समर्थित ओएसएस पर इंस्टॉलर के स्वचालित क्लिकथ्रू परीक्षण के लिए vSphere पर आर्टिफैक्ट को बंद करने के लिए आवश्यक समय की गणना नहीं करता है।