অভ্যন্তরীণ অ্যাপ্লিকেশনগুলির জন্য কেন অভ্যন্তরীণ গ্রন্থাগারগুলি বিকাশ করবেন?


10

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

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

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

যখন আমি প্রতিটি প্রকল্পে ফাইলগুলি অন্তর্ভুক্ত করি বলি, আমি বর্তমানে প্রতি বিকাশিত প্রকল্পের উত্স ট্রিতে অনুলিপি এবং আটকানো বলতে চাইছি না। আমি বোঝাতে চাইছি সাধারণ উত্স কোড সম্বলিত কিছু ডিরেক্টরি / গ্রন্থাগার (কোনও প্রকল্পের সাথে পৃথক) বিকাশ যা সাধারণ উপায়ে কোনও প্রকল্পের ফাইলগুলিতে অন্তর্ভুক্ত করা যায়, অর্থাৎ # অন্তর্ভুক্ত।

পিএস আমি একাধিক ডেস্কটপ অ্যাপ্লিকেশনগুলির জন্য এখানে সি / সি ++ বিকাশের কথা বলছি।


উত্তর:


25

এমনকি অভ্যন্তরীণ ব্যবহারের জন্য লাইব্রেরি এবং ভাগ করা লাইব্রেরি (.dll বা .so ফাইলগুলিতে) তৈরি করার অসংখ্য কারণ রয়েছে :

  1. প্রকল্পগুলি জুড়ে পুনরায় ব্যবহার করা অনেক পরিষ্কার
  2. দায়িত্ব বিচ্ছিন্নকরণ - আপনার কোডের অংশটি আরও উপযুক্ত বিভিন্ন বিকাশকারী বা দল হতে পারে
  3. নির্দিষ্ট দল সনাক্ত না করে অন্যান্য দলগুলি যে লাইব্রেরিগুলি তৈরি করে সেগুলি থেকে আপনি উন্নতি করতে পারেন
  4. দ্রুত গড়ার সময়, গ্রন্থাগারটি স্থিতিশীল থাকলে এটি পুনর্নির্মাণের প্রয়োজন হয় না।
  5. ডিস্ক স্পেস - আপনার প্রকল্পে কেবল গ্রন্থাগার এবং শিরোনাম থাকতে পারে
  6. আপনি যদি ভাগ করা লাইব্রেরি ব্যবহার করেন তবে বেশ কয়েকটি প্রোগ্রাম ব্যবহার করা হলেও আপনি র‌্যামে লোড হওয়া কেবল একটি অনুলিপি দিয়ে মেমরি সঞ্চয় করতে পারবেন
  7. আপনি সাধারণত গ্রন্থাগারগুলির আরও ভাল ডকুমেন্টেশন এবং পরীক্ষার সাথে শেষ করেন
  8. ক্লিনার নকশা এবং কোড - লাইব্রেরি মধ্যে স্ট্রাকচারিং জিনিস সম্পর্কে চিন্তা প্রতিটি লাইব্রেরিতে কার্যকারিতা সংশ্লিষ্ট দলের মধ্যে স্থাপিত হবে এবং আপনি জেনেরিক কোড, আলাদা ঝোঁক লাইব্রেরি মধ্যে , আবেদন সুনির্দিষ্ট থেকে অ্যাপ্লিকেশানে
  9. আপনার যদি গ্রন্থাগারে মালিকানাধীন অ্যালগরিদম থাকে তবে আপনি উত্স অ্যাক্সেসকে সীমাবদ্ধ করতে পারেন, উদাহরণস্বরূপ ঠিকাদার বা উত্সাহিত দলগুলিকে উত্সটিতে না যাওয়ার অনুমতি না দেওয়া।
  10. অ্যাপ্লিকেশনটির মূল অংশ হিসাবে এটি লেখা হয়েছিল লাইব্রেরি কোডটি অন্য কোনও লাইসেন্সের অধীনে স্থাপন করা যেতে পারে, কিছু সংস্থাগুলি এমনকি ওপেন সোর্স লাইব্রেরিগুলিতে পরিচিত ছিল যে তারা গর্বিত - ওপেন সোর্স সম্প্রদায়ের বড় কুদো অর্জন এবং কিছু সময় বড় বর্ধিতকরণ অবদান রেখেছিল পেছনে.

কিছু সংস্থার এমনকি অ্যাকাউন্টিং অনুশীলন রয়েছে যেখানে প্রকল্পগুলি যেগুলি গ্রন্থাগার তৈরি করে তাদের প্রতিটি পুনরায় ব্যবহারের জন্য কিছুটা পরিশোধ প্রদান করে।


1
বা 9 পয়েন্টের পরিবর্তনে, আপনি মূল অ্যাপ্লিকেশন কোডের চেয়ে ভিন্ন লাইসেন্সের অধীনে গ্রন্থাগারটি প্রকাশ করতে পারেন।
মাইকেল বর্গওয়ার্ট

@ মিশেলবর্গওয়ার্ট - উপরে 10 ভাল পয়েন্ট অনুরোধ জানানো।
স্টিভ বার্নেস

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

11

আরও কিছু সম্ভাব্য কারণ যা বৃহত্তর, অযৌক্তিক প্রকল্পগুলিতে প্রয়োগ হতে পারে:

  • সংকলনের সময়: হাজার হাজার ফাইল, হাজার হাজার ক্লাস, ফাংশন ইত্যাদির সাথে বিশাল একক একাধিক সি ++ প্রকল্পগুলি সংকলন করতে খুব দীর্ঘ সময় নিতে পারে (যা আপনি কোডের কয়েকটি লাইন পরিবর্তন করে প্রতিবার পুনরায় সংকলন করতে চাইলে উত্পাদনশীলতায় ক্ষতিগ্রস্থ হয়)। স্ট্যাটিকালি-লিংকড এবং ডায়নামিকালি-লিঙ্কড লাইব্রেরিগুলি স্বাধীনভাবে সংকলিত হয় এবং যদি তাদের উত্সটি পরিবর্তন না হয় তবে পুনরায় সংকলনের প্রয়োজন হয় না।

  • স্বতন্ত্র মডিউল বা সাবসিস্টেমগুলির যৌক্তিক পৃথকীকরণ : কার্যকারিতার পৃথক ক্ষেত্রগুলি পৃথক মডিউলগুলিতে স্থাপন করা হলে বড় সিস্টেমগুলি পরিচালনা করা সহজতর হয় এবং হাজার হাজার ফাইল / শ্রেণি সমন্বিত বিশাল ফোল্ডার / প্রকল্পগুলির মাধ্যমে বিকাশকারীদের সন্ধান করা হয় না।

  • বিকাশকারী / দলগুলির মধ্যে সীমানা : বিকাশকারীরা একই সাথে পৃথক পৃথক নতুন কার্যকারিতা তৈরি করে যদি প্রতিটি বিকাশকারীকে বিভিন্ন মডিউলটিতে কাজ করা সম্ভব হয় তবে একত্রীকরণ সংঘাতের সম্ভাবনা হ্রাস করতে পারে।

  • কোড যা কোনও লাইভ পরিবেশে প্রকাশ করা উচিত নয় : উদাহরণস্বরূপ, ইউনিট টেস্ট লাইব্রেরি বা 'মক' লাইব্রেরি যা বিকাশকারী পরীক্ষার জন্য লাইভ সিস্টেম উপাদান (হার্ডওয়্যার, এপিআই, রিমোট সিস্টেম, ডাটাবেস, ইত্যাদি) বিকল্পের জন্য ব্যবহৃত হয়

  • সংকলক পতাকা : আপনি যদি কোনও তৃতীয় পক্ষের এপিআইয়ের সাথে একীকরণের খুব দুর্ভাগ্যজনক অবস্থানে খুঁজে পান যা একটি অদ্ভুত সংকলক পতাকা প্রত্যাশা করে, তবে গ্রন্থাগারটি তৃতীয় পক্ষের এপিআই এবং বাকী অ্যাপ্লিকেশনের মধ্যে বসে একটি "সংক্ষেপণ স্তর" হতে পারে।

  • Featuresচ্ছিক বৈশিষ্ট্য / অপ্টিমাইজেশন : বড় সিস্টেমে কোনও অ্যাপ্লিকেশন যদি অ্যাপ্লিকেশনটির প্রাথমিক কার্যকারিতাটির জন্য তাত্পর্যপূর্ণ না হয় তবে রানটাইমের সময় কিছু গতিযুক্ত যুক্ত মডিউলগুলি মেমরিতে লোড করার আগে অপেক্ষা করতে পারে।


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


3
@ ডাউনভোটার - আপনি ডাউনটোটের কারণ ব্যাখ্যা করতে পারেন? প্রত্যেকের জন্য এই সাইটের গুণমান উন্নত করতে উত্তরগুলির প্রতিক্রিয়া দরকারী।
বেন কটরেল

4

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

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

সুতরাং আমি অনুমান করি আপনার আসল প্রশ্নটি হ'ল - সোর্স কোড লিবস কখন তৈরি করবেন, বা কখন প্রম্পম্পাইল্ড বাইনারি লাইবস পছন্দ করবেন? এই সাইটের এই পুরানো উত্তরে , আমি শিরোনাম-কেবল লিবসের কিছু উপকারিতা এবং কনস সম্পর্কে আলোচনা করেছি, সম্ভবত এটি আপনাকে সহায়তা করে। উত্স-কোড লিবের প্রধান সুবিধা হ'ল, এগুলি প্রয়োগ হিসাবে অ্যাপ্লিকেশন হিসাবে তাদের একই রান-টাইম এবং / অথবা সামঞ্জস্যপূর্ণ সংকলক / লিঙ্কার ফ্ল্যাগগুলির সাথে সংকলন করতে হবে না। ত্রুটিগুলি হ'ল অতিরিক্ত সংকলনের সময়, এবং উত্স কোডটিতে অ্যাক্সেস সরবরাহের প্রয়োজনীয়তা (যা আপনার মনে রাখা ধরণের "অভ্যন্তরীণ" প্রকল্পগুলির জন্য অবশ্যই সমস্যা নয়)।


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

@ অ্যান্ড্রুমুরতাঘ: আপনি মাইকেলবার্গওয়ার্টের উত্তরটি এত তাড়াতাড়ি গ্রহণ করার বিষয়টি আমাকে অবাক করে দিয়েছিল, কারণ তিনি যা লিখেছেন তা তাঁর বা আমার একটি ভুল বোঝাবুঝি বলে মনে হচ্ছে।
ডক ব্রাউন 21

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

2

আমি অন্যান্য মন্তব্যকারীদের সাথে সম্মত হই যখন তারা লিখেন যে আপনার কোডটি নকল করা উচিত নয়। আপনার ক্ষেত্রে যাইহোক, মনে হচ্ছে আপনি (বা আপনি যাদের সাথে কাজ করেন) কোডের জন্য লাইব্রেরি তৈরি করছেন যা অন্য কোথাও সদৃশ নয়

এই ক্ষেত্রে, আমি অকাল সাধারণীকরণের বিরুদ্ধে সাবধানতা অবলম্বন করি । অনেক সময় এমন হয় যখন কেউ মনে করে যে কোনও কোডের টুকরোটি পুনরায় ব্যবহারযোগ্য হবে। তবে, দ্বিতীয় ব্যবহারের ক্ষেত্রে এই জাতীয় কোড কীভাবে ব্যবহার করা হবে তার অন্তরঙ্গ বিবরণ না জেনে, "পুনরায় ব্যবহারযোগ্যতা" বৈশিষ্ট্যগুলিতে অতিরিক্ত সময় ব্যয় করা খুব সহজ যে অতিরিক্ত ক্ষেত্রে এটি কার্যকরভাবে কার্যকর হবে না বা অনুমানগুলি ভুল প্রমাণিত হয় যা ভুল প্রমাণিত হয় দ্বিতীয় ক্ষেত্রে।

একটি ব্যবহারের ক্ষেত্রে "লাইব্রেরি" লিখতে কোনও ব্যয় ছাড়াই খুব ব্যয়বহুল অনুশীলনে রূপান্তরিত হতে পারে --- আমাকে বেশ কয়েকবার কামড়েছে।

উদাহরণ ব্যয়:

  1. "সাধারণ" ব্যবহারের ক্ষেত্রে বিবেচনা করার জন্য সময় / শক্তি ব্যয় করে
  2. আপনার "ক্লায়েন্ট" (আপনার নিজস্ব কোড) "বিতরণযোগ্য" লাইব্রেরি তৈরি করতে সময় ব্যয় করেছে
  3. "লাইব্রেরি "টি পরবর্তী ব্যবহারের ক্ষেত্রে সম্পূর্ণরূপে মেলে না তবুও ভবিষ্যতের চাপ

আমার সাধারণ নিয়মটি হ'ল: আমার কাছে কমপক্ষে 2 টি পৃথক জায়গা না রয়েছে যেখানে কোডের দরকার হয়, যদি না আমার একটি লাইব্রেরিতে কোড তৈরি করবেন না।


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

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

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

1

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

কারণ যদি আপনি "কেবলমাত্র তাদের উত্স গাছের মধ্যে অন্তর্ভুক্ত করেন", আপনি কোডটি নকল করছেন

এর সাথে সমস্যাটি হ'ল আপনি কোডটি অনুলিপি করেছেন এমন প্রকল্পের দ্বারা করা কোনও উন্নতি (সমালোচনামূলক বাগফিক্স সহ) থেকে আপনি উপকৃত হবেন না বা আপনার করা কোনও উন্নতি থেকে তারা উপকৃত হবেন না।

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

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


1
সুতরাং আমি যেমন বুঝতে পেরেছি, কোনও কোডকে কোনও গ্রন্থাগারে তৈরি করার মূল কারণ হ'ল যখন সেই কোডটি নকল করা, আপডেট করা, রক্ষণাবেক্ষণ না করার জন্য বিভিন্ন প্রকল্পে (সেগুলি অভ্যন্তরীণভাবে বিকশিত হলেও) ব্যবহার করা হবে is আলাদাভাবে? এবং যদি আপনি কেবল একটি একক প্রকল্প বিকাশ করতে যাচ্ছেন তবে লাইব্রেরিতে কিছু তৈরি করার দরকার নেই (যদি আপনি পরবর্তী কোনও প্রকল্পে এটি ব্যবহারের ইচ্ছা না করেন)।
অ্যান্ড্রু মুরতাগ

@ অ্যান্ড্রুমুরতাঘ: হ্যাঁ, আমি ঠিক এটি কীভাবে রেখেছিলাম pretty যদিও প্রযুক্তিগত কারণগুলিও হতে পারে; আমি সি / সি ++ বিকাশের সাথে তেমন পরিচিত নই - সম্ভবত কোডটির কিছু অংশ একটি লাইব্রেরি হিসাবে রাখা প্রয়োজন তাই এটি বিকল্পভাবে লোড করা যায় এমনকি চাহিদা অনুযায়ী লোড এবং আনলোড করা যায়, এবং এইভাবে fuctionality প্রয়োজন না হলে মেমরির ব্যবহার হ্রাস করতে পারে?
মাইকেল বর্গওয়ার্ট

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

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

রক্ষণাবেক্ষণ সম্পর্কেও চিন্তা করুন। 1) lib স্বাধীন এবং সমান্তরালভাবে বজায় রাখা যেতে পারে। 2) কোড প্রতিস্থাপন করা সহজ। 3) ছোট কোড বেস ছোট দলের জন্য পরিচালনা করা সহজ এবং প্রত্যেকের জন্য বোঝা সহজ। 4) যদি সময়-বাজারে সমালোচনা হয় তবে আপনি দ্রুত বিল্ডিং করতে পছন্দ করবেন। লাইবসে কোড হ'ল এমন কোড যা আপনি পাইপলাইনে (আইএমও) বার বার সংকলন করেন না। 5) এটি নির্ভরযোগ্য পুনরায় ব্যবহারযোগ্য কোড ... আপনি এটি তৈরি করেছেন ;-)
লাইভ

1

আপনার সমাধানটি দীর্ঘমেয়াদে ব্যয় করতে চাই।

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

তবে, আপনার প্রকল্পটি বাড়ার সাথে সাথে "সিউডো-লাইব্রেরি" এর ব্যয়ও ঘটবে। ধরে নিন আপনার কাছে একটি "সিউডো-লাইব্রেরি" রয়েছে Aযা একটি অ্যাপ্লিকেশন এবং ইউনিট পরীক্ষক দ্বারা ব্যবহৃত হয়। প্রতিবার আপনি সিপিসি যুক্ত করার সময় A, আপনাকে এটি উভয় প্রকল্পে যুক্ত করতে হবে, অন্যথায় তারা লিঙ্ক করবে না।

যদি আপনার "সিউডো-লাইব্রেরি" অন্য "সিউডো-লাইব্রেরি" ব্যবহার করে তবে কী হবে B? আপনাকে আরও নতুন প্রকল্পে আরও নতুন সিপিপি যুক্ত করতে হবে। এবং যদি Bঅন্য লাইব্রেরি ব্যবহার করতে চান? আপনাকে Aকেবলমাত্র উপর নির্ভর করে সমস্ত প্রকল্পের সিপিসিগুলি মুছতে হবে B

একটি বাস্তব গ্রন্থাগার ব্যবহার করা হবে যদি এই সব বিনামূল্যে হয়। সুতরাং প্রশ্নটি হল, সত্যিকারের লাইব্রেরিতে সরানো ন্যায্যতার জন্য কতগুলি সিপিসি প্রয়োজন?

তবে অপেক্ষা করুন, আরও বেশি জামানত রয়েছে: একটি বিকাশকারী নতুন সিপিপি-র প্রয়োজনে সমস্ত প্রকল্প শিকার করার এই বোকা কাজটিকে পছন্দ করেন না এবং ইতিমধ্যে বিদ্যমান ফাইলগুলিতে কোথাও তার কোড / ক্লাস যুক্ত করবেন যা কোনও ভাল জিনিস নয় দীর্ঘমেয়াদে.

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


0

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

যদি লাইব্রেরিটি কেবলমাত্র একটি অ্যাপ্লিকেশন দ্বারা ব্যবহৃত হয় তবে সম্ভবত আপনার আলাদা লাইব্রেরি হিসাবে এটির দরকার নেই

গ্রন্থাগার 3,500 অ্যাপ্লিকেশন দ্বারা ব্যবহার করা হয়, তাহলে আপনি একেবারে না একটি পৃথক লাইব্রেরি রূপে এটি প্রয়োজন।

লাইব্রেরিতে কোনও বাগ আছে এবং এটি ঠিক করার দরকার আছে? অথবা এমন কোন সংবিধিবদ্ধ বা নিয়ন্ত্রক পরিবর্তন তার মানে কি বরাবর আসে আছে উপায় গ্রন্থাগার কাজ করার ধরন পাল্টে কিভাবে?

যদি এটি একটি পৃথক লাইব্রেরিতে থাকে তবে আপনি (সম্ভাব্য) লাইব্রেরিটি ঠিক করতে পারেন, এটি পুনরায় পরীক্ষা করতে পারেন এবং এটি পুনরায় স্থাপন করতে পারেন এবং ঠিকঠাক থেকে প্রতিটি অ্যাপ্লিকেশন সুবিধা পাবেন।

যদি এটি কেবলমাত্র উত্স কোডে থাকে যা প্রতিটি অ্যাপ্লিকেশনে "স্থানীয়" থাকে তবে আপনাকে প্রতিটি অ্যাপ্লিকেশন পৃথকভাবে পরিবর্তন করতে হবে, পুনর্নির্মাণ করতে হবে, পুনরায় পরীক্ষা করতে হবে এবং পুনরায় স্থাপন করতে হবে । এটি অনেক বড় (অর্থাত্ আরও ব্যয়বহুল) অনুশীলন।

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