জাভা প্রকল্পগুলি পৃথক করা


12

আমার কাছে একটি বিশাল জাভা প্রকল্প রয়েছে এবং আমরা আমাদের বিল্ড চক্রের জন্য মাভেন ব্যবহার করি। এই একটি প্রকল্পটি ব্যাপকভাবে ব্যবহৃত হয় - অন্যান্য প্রকল্পগুলিতে, বিভিন্ন অ্যাপ্লিকেশনগুলিতে, যার মধ্যে কিছু রয়েছে এবং এটি অন্য কোথাও রয়েছে ... সত্যি বলতে কী, এটি কিছুটা গণ্ডগোলের বিষয় (বিভিন্ন বিট নির্দিষ্ট সময়ে বিভিন্ন সময়ে যুক্ত হয়েছে) উদ্দেশ্য), এবং আমি এটি কিছুটা পরিষ্কার করতে চাই। এছাড়াও, এটি সম্পূর্ণরূপে পরীক্ষা করা হয়নি (যথাযথ ইউনিট এবং ইন্টিগ্রেশন টেস্টিং ব্যতীত প্রচুর বিট যোগ করা হয়েছে), এবং এমন কিছু পরীক্ষা রয়েছে যা চালাতে বেশ সময় নেয় বা আসলে পাস হয় না ... (আহ-ওহ) - সুতরাং ম্যাভেন বিল্ড চক্রটিতে পরীক্ষাগুলি স্যুইচ অফ করা হয় (আবার, আহ-ওহ)।

আমি এই বৃহত প্রকল্পটিকে ছোট নির্দিষ্ট প্রকল্পগুলিতে পৃথক করার বিষয়ে ভাবছি, যেমন 'চূড়ান্ত' উপ-প্রকল্প (বা বেশ কয়েকটি উপ-প্রকল্প) বিভিন্ন উপ-প্রকল্পগুলির প্রয়োজন যা তা গ্রহণ করবে।

আমার চিন্তাভাবনাটি নিম্নরূপ:

  • যদি আমি বড় প্রকল্পটিকে বিভিন্ন উপ-প্রকল্পে আলাদা করি, তবে এটি প্রতিটি প্রকল্পের দায়িত্ব কী তা তা পরিষ্কার করে দেয়।
  • উপ-প্রকল্পগুলিতে বিভক্ত হয়ে আমি তারপরে প্রতিটি উপ-প্রকল্পের টেস্টিং স্বতন্ত্রভাবে পরিষ্কার করতে পারি এবং মাভেন বিল্ড চক্রের sub উপ-প্রকল্পের পরীক্ষাটি চালু করতে পারি।

এটি নির্মাণের সময়টিতে কী প্রভাব ফেলতে পারে সে সম্পর্কে আমি কিছুটা উদ্বিগ্ন।

  • বৃহত প্রকল্পের উপর কোনও কাঠামো চাপিয়ে দেওয়া (অর্থাত্ ছোট ছোট ছোট ছোট ছোট প্রকল্পের মধ্যে) সংকলকটি কমিয়ে দেবে?

এছাড়াও, আইডিইগুলিতে এটির সম্পাদনার সময় কীভাবে প্রভাব ফেলতে পারে সে সম্পর্কে আমার কিছুটা উদ্বেগ রয়েছে (আমরা মূলত ইন্টেলিজ ব্যবহার করি)। ইন্টেলিজ প্রতিটি প্রকল্প নির্ভরশীল গাছের মাধ্যমে ঘুরে দেখবেন - যেমন সি যদি বি এর উপর নির্ভর করে এটি এ এর ​​উপর নির্ভর করে এবং আমি এ পরিবর্তন করি তবে এটি বি তৈরির চেষ্টা করবে না যতক্ষণ না একটি সংকলন করে, ইত্যাদি। তাত্ক্ষণিকভাবে এটি সুবিধাজনক তবে আমি খুঁজে পেয়েছি যে - উদাহরণস্বরূপ, আমি এ এর ​​একটি ইন্টারফেস পরিবর্তন করি যা বি এবং সি তে ব্যাপকভাবে ব্যবহৃত হয়, সেই পরিবর্তন থেকে সমস্ত ত্রুটিগুলি ঠিক করতে কিছুটা সময় লাগে ...

আরেকটি প্রশ্ন হ'ল ফ্যাক্টরি ক্লাস কীভাবে ব্যবহার করা যায়। প্রকল্পের কিছু দিক বাইরের জারের উপর নির্ভর করে। মাঝে মাঝে (কৃতজ্ঞতার সাথে প্রায়শই নয়) এগুলি আপডেট হয় এবং আমাদের স্থানান্তর করতে হয়। আমরা একটি কারখানার শ্রেণি ব্যবহার করে এটি পরিচালনা করি যা বাহ্যিক কোডের সঠিক সংস্করণগুলিতে নির্দেশ করে (যাতে আমাদের কোড বেস জুড়ে সমস্ত বাস্তবায়ন পরিবর্তন করতে হবে না)।

এই মুহুর্তে এটি বৃহত প্রকল্পের মধ্যে রয়েছে তবে আমি ভাবছি যে সাব-প্রকল্পগুলিতে স্যুইচ করে আমি নতুন বহিরাগত কোড প্রয়োগের জন্য একটি নতুন প্রকল্প বিকাশ করতে পারব, সাব-প্রকল্পটি পুরোপুরি কার্যকরী এবং পরীক্ষিত হয়েছে তা নিশ্চিত করতে এবং তারপরে ব্যবহারকারী প্রকল্পে নির্ভরতা / কারখানা শ্রেণীর স্যুইচ করুন। যাইহোক, বৃহত্তর প্রকল্প জুড়ে এটি ইন্টারফেসের বিস্তৃত ব্যবহার দ্বারা আরও জটিল হয়ে উঠেছে। উদাহরণ স্বরূপ

  • উপ-প্রকল্প এ - এর ইন্টারফেস রয়েছে
  • উপ-প্রকল্প বি - ইন্টারফেস এবং পুরানো বহিরাগত জারের জন্য A এর উপর নির্ভর করে
  • উপ-প্রকল্প সি - বি (এবং এইভাবে এ এবং পুরাতন বাহ্যিক জার) এর উপর নির্ভর করে এবং এতে একটি ফ্যাক্টরি শ্রেণি রয়েছে যা বি এর ইন্টারফেসগুলির প্রয়োগগুলি ব্যবহার করে

আমার যদি বি এর বাহ্যিক জারটি পরিবর্তন করতে হয় তবে আমি এটি করতে পারি:

  • B_ii উপ-প্রকল্প তৈরি করুন - আবার এ এর ​​উপর নির্ভর করে এবং এখন নতুন বাহ্যিক জার
  • একবার সম্পূর্ণরূপে কার্যকরী হয়ে গেলে, আমি সি এর নির্ভরতা বি_আইআইতে যুক্ত করতে এবং ইন্টারফেসগুলির নতুন বাস্তবায়নগুলি ব্যবহার করতে কারখানার শ্রেণি পরিবর্তন করতে পারি।
  • যখন এটি সমস্ত কাজ করছে, আমি তারপরে সি এর নির্ভরশীলতা বি এর উপর নির্ভরতা সরিয়ে ফেলতে পারি এবং যদি ইচ্ছা হয় তবে সাব-প্রকল্প বি সরিয়ে ফেলতে পারি

  • এটি কি এটি বোধগম্য উপায়?

সুতরাং, সাধারণভাবে, আমার প্রশ্নগুলি হ'ল:

  • কারও কি বড় প্রকল্প ভাঙার অভিজ্ঞতা আছে? এমন কোনও টিপস / কৌশল আছে যা আপনি ভাগ করতে ইচ্ছুক?
  • এটি আপনার বিকাশ এবং সময় তৈরিতে কী প্রভাব ফেলেছিল?
  • এই জাতীয় প্রকল্পের ব্রেক আপের কাঠামোগত বিষয়ে আপনি কী পরামর্শ দিতে পারেন?

নোট করুন যে আপনি এ, বি, এবং সি পৃথকভাবে একে অপরের পাশে চেক আউট দিয়ে একটি প্যারেন্ট প্রকল্প তৈরি করতে পারেন। এটি উদাহরণস্বরূপ ইন্টেলিজকে একই সাথে তিনটি মেমরি রাখতে এবং মডিউল সীমানা জুড়ে রিফ্যাক্টরিংগুলি করতে সক্ষম করে।
থরবজর্ন রাভন অ্যান্ডারসন

উত্তর:


10

আমি এটির (দ্রুত কিউ বিটিডাব্লু!) একটি দ্রুত প্রথম কাটতে যাচ্ছি:

বৃহত প্রকল্পের উপর কোনও কাঠামো চাপিয়ে দেওয়া (অর্থাত্ ছোট ছোট ছোট ছোট ছোট প্রকল্পের মধ্যে) সংকলকটি কমিয়ে দেবে?

যথেষ্ট পরিমাণে এটি গুরুত্বপূর্ণ নয়, ওভারহেডটি আসলে ম্যাভেন আমন্ত্রণগুলিতে।

এছাড়াও, আইডিইগুলিতে এটি সম্পাদনার সময় কীভাবে প্রভাব ফেলতে পারে সে সম্পর্কে আমার কিছুটা উদ্বেগ রয়েছে (আমরা মূলত ইন্টেলিজ ব্যবহার করি)। ইন্টেলিজ প্রতিটি প্রকল্প নির্ভরশীল গাছের মাধ্যমে ঘুরে দেখবেন - যেমন সি যদি বি এর উপর নির্ভর করে এটি এ এর ​​উপর নির্ভর করে এবং আমি এ পরিবর্তন করি তবে এটি বি তৈরির চেষ্টা করবে না যতক্ষণ না একটি সংকলন করে, ইত্যাদি। তাত্ক্ষণিকভাবে এটি সুবিধাজনক তবে আমি খুঁজে পেয়েছি যে - উদাহরণস্বরূপ, আমি এ এর ​​একটি ইন্টারফেস পরিবর্তন করি যা বি এবং সি তে ব্যাপকভাবে ব্যবহৃত হয়, সেই পরিবর্তন থেকে সমস্ত ত্রুটিগুলি ঠিক করতে কিছুটা সময় লাগে ...

ম্যাভেন বাইন্ডিং এবং নির্ভরতা পরিচালনার ক্ষেত্রে বিভিন্ন আইডিইগুলির বিভিন্ন শক্তি রয়েছে। খেলার খেলার অবস্থা দেখে মনে হচ্ছে এটি বেশিরভাগ ক্ষেত্রে সর্বাধিক সর্বাধিক সরেজমিন, নেটবিয়ানস এবং ইন্টেলিজজে কাজ করে - তবে আপনাকে আপনার বিকাশকারীদের "ডিস্ক থেকে উত্স ফাইলগুলি রিফ্রেশ করুন এবং সম্পর্কিত সমস্ত মেভেন প্রকল্পগুলি পুনর্নির্মাণ" এর জরুরি ডাবল ঘৃণা শিখাতে হবে।

আমি দেখতে পেয়েছি যে এই দিনগুলিতে আমি কম এবং কম করে চলেছি। একটি এসএসডি ড্রাইভ করা বিটিডব্লিউ এখানে একটি বিশাল পার্থক্য করে makes

স্নিপ কারখানা ক্লাস অনুচ্ছেদ

নির্ভরশীলতা পরিচালনা অবিশ্বাস্যরূপে গুরুত্বপূর্ণ, নির্বিশেষে কোন প্রযুক্তি (মাভেন / আইভী / যাই হোক না কেন) এটি প্রয়োগে আপনাকে সহায়তা করতে ব্যবহার করে।

আমি মাভেন নির্ভরতা প্লাগইন থেকে বিস্তৃত প্রতিবেদন পেয়ে শুরু করব এবং যা পেয়েছি তা স্টক করব। সাধারণভাবে বলতে গেলে আপনি পিওএমের নির্ভরতা ব্যবস্থাপনায় নির্ভরতা নির্ধারণ করুন যতটা সম্ভব খাদ্য শৃঙ্খলা উচ্চতর, তবে কোনও উচ্চতর নয়। সুতরাং যদি আপনার দুটি সাবমডিউলগুলি একটি বাহ্যিক নির্ভরতা ব্যবহার করে, তবে তা তাদের প্যারেন্ট পিওএম এবং এগুলি আরও অনেক কিছু।

বাহ্যিক জেআরগুলি আপগ্রেড করা সর্বদা যথাযথ মিনি-প্রকল্প হিসাবে করা উচিত। আপনি কেন আপগ্রেড করছেন তা মূল্যায়ন করুন, যে কোনও নতুন বৈশিষ্ট্য / বাগ ফিক্স ইত্যাদির সুবিধা নিতে সোর্স কোডকে পরিবর্তন করুন Just

সুতরাং, সাধারণভাবে, আমার প্রশ্নগুলি হ'ল:

কারও কি বড় প্রকল্প ভাঙার অভিজ্ঞতা আছে? এমন কোনও টিপস / কৌশল আছে যা আপনি ভাগ করতে ইচ্ছুক?

  • ইন্টারফেস এবং নির্ভরতা ইনজেকশন আপনার বন্ধু।
  • উত্তরাধিকারের কোডটি কার্যকরভাবে মোকাবেলা করার বিষয়ে মাইকেল ফেদারের বইটি অবশ্যই পড়তে হবে।
  • ইন্টিগ্রেশন টেস্টগুলি আপনার বন্ধু
  • সাব-প্রকল্পগুলিকে ফু-এপিআই (কেবলমাত্র ইন্টারফেস!) এবং ফু-কোর-এ ভাগ করা এবং কেবলমাত্র ফু-এপি-র উপর নির্ভরশীল মডিউলগুলি একটি বিরাট চুক্তিতে সহায়তা করে এবং বিচ্ছেদকে কার্যকর করে
  • Jboss মডিউল এবং / অথবা OSGi পরিষ্কার বিচ্ছিন্নকরণ প্রয়োগ করতে সহায়তা করতে পারে

এটি আপনার বিকাশ এবং সময় তৈরিতে কী প্রভাব ফেলেছিল?

দেব এবং বিল্ড টাইমের উপর খুব সামান্য প্রভাব - আমাদের সামগ্রিক অবিচ্ছিন্ন ডেলিভারি পাইপলাইনের জন্য সময়কালে একটি বিশাল লাভ।

এই জাতীয় প্রকল্পের ব্রেক আপের কাঠামোগত বিষয়ে আপনি কী পরামর্শ দিতে পারেন?

ছোট কাজগুলি ঠিকঠাক করুন এবং বড় জিনিসগুলি পরে পরিষ্কারভাবে বেরিয়ে আসে। সুতরাং জিনিসগুলি কিছুটা হলেও বিভক্ত করুন - আপনি যদি আপনার ইন্টিগ্রেশন পরীক্ষাগুলির সাথে একটি উচ্চ শতাংশের কভারেজ না পেয়ে থাকেন তবে সম্পূর্ণ লটের বিশাল পুনর্গঠন করবেন না।

বিভক্তির পূর্বে ইন্টিগ্রেশন টেস্টগুলি লিখুন - আপনার কমবেশি বিভাজনের পরে একই ফলাফল (গুলি) পাওয়া উচিত।

আপনার এখন যে মডুলারিটির এবং যেখানে আপনি যেতে চান তার চিত্র আঁকুন। অন্তর্বর্তী পদক্ষেপ ডিজাইন।

ছেড়ে দিতে হবে না - কিছু ইয়াক খেউরি এখন থেকে "দ্রুত তৈরি করুন এবং refactor ভয় ছাড়াই" সক্ষম হচ্ছে ভিত্তি তৈরী করে লজ্জাহীন প্লাগ -> বেন থেকে এবং আমি এর দৃঢ় ভিত্তির উপরে জাভা ডেভেলপার

ভাগ্য সুপ্রসন্ন হোক!


0

প্রয়োজনে আমার এই গ্রহণটি পৃথক। যাইহোক, এটি পরবর্তী প্রশ্নটি নিয়ে আসে: এটি প্রয়োজনীয় কিনা তা আমি কীভাবে নির্ধারণ করব?

  • যখন আর্টিফ্যাক্ট আলাদা হয় (যেমন একই প্রকল্পে EAR, WAR, JAR, ইন্টিগ্রেশন-টেস্টিং-জারটি তৈরি করবেন না)।
  • বিচ্ছেদ চলাকালীন আপনি যখন খেয়াল করবেন যে কিছু কোডের একাধিক আর্টিফ্যাক্ট রিফ্যাক্টর তাদের একটি নতুন মধ্যে থাকা প্রয়োজন।
  • যখন আপনার দলের বাইরে অন্য কোনও প্রকল্প আপনার প্রকল্পে থাকা কিছু ব্যবহার করতে চায়।

এর এক কারণ হ'ল বিকাশকারীদের একাধিক প্রকল্প নিয়ে কাজ করতে হবে এবং জাভা প্যাকেজটি কোন প্রকল্পের অন্তর্ভুক্ত তা কোনটি থেকে আলাদা করে বের করার চেষ্টা করতে হবে। আমি এমন প্রকল্পগুলিতে এসেছি যেখানে এটি সত্যই অ্যানিমিক হয়ে উঠেছে এবং এমন একটি প্রকল্প ছিল যা কেবল চারটি ক্লাসে একটি কার্যকারিতা বাস্তবায়িত করেছিল কেবল কারণ এটি আর্কিটেকচারাল দিক। মাভেন জনপ্রিয় হওয়ার আগে এটিও ফিরে এসেছিল সুতরাং শ্রেণীর পথগুলি এবং আইডিই এবং পিপীলিকা উভয় স্ক্রিপ্ট উভয়ই সেট আপ করার দরকার নেই।

অন্য কারণটি হ'ল চারপাশের প্লাম্বিংয়ের ক্ষেত্রে আপনার মোকাবেলার জন্য আরও চলন্ত অংশ রয়েছে এবং আপনি সম্ভবত এটি জেনে যাওয়ার আগে নির্ভরতা স্প্যাগেটি থাকবেন।

একটি প্রকল্পের মধ্যে প্রকল্পের চেয়ে রিফ্যাক্টরিংও সহজ।

যদি বিল্ড টাইম কোনও সমস্যা হয় তবে কেবলমাত্র আরও ভাল হার্ডওয়্যার সরবরাহ করুন।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.