অন্য কেউ এখনও দ্বি প্রান্তের তরোয়াল উল্লেখ করেনি, সুতরাং আমি আমার 2 সেন্ট যুক্ত করব। আপনার যদি একাধিক প্রকল্প থাকে এবং সেগুলি কিছু ভাল পুনরায় ব্যবহারযোগ্য কোড ভাগ করে দেয় তবে ভাল প্রোগ্রামিং অনুশীলন / নীতিগুলি (উদাহরণস্বরূপ DRY) অনুসারে আপনার কোডটি একটি বিশ্বব্যাপী স্থানে স্থাপন করা উচিত এবং এটি এমনভাবে গঠন করা উচিত যাতে এটি সকলের দ্বারা ভাগ করা যায় আপনার প্রকল্পগুলি কোনও পরিবর্তন ছাড়াই। অন্য কথায়, ইন্টারফেসগুলি জেনেরিক এবং প্রত্যেকের পক্ষে উপযুক্ত সাধারণ হতে সংজ্ঞায়িত করুন।
এটি করার জন্য কয়েকটি বিকল্প রয়েছে: 1) এমন একটি বেস প্রকল্প তৈরি করুন যা অন্যরা নির্ভর করে। এই প্রকল্পটি বাইনারি বিতরণ তৈরি করতে পারে যা অন্যান্য প্রকল্পগুলি গ্রাস করে। 2) আপনার সংস্থার মধ্যে একটি ওপেন সোর্স মডেল টানুন। সাধারণ কোডের নিজস্ব কোড শাখা হয়ে উঠুন এবং অন্যান্য প্রকল্পগুলিকে কোড একইভাবে টানুন আপনি কোনও ওএসএস থেকে অনলাইনে সোর্স কোড নিতে পারেন।
এখন এখানে যেখানে তরোয়াল আসে ...
এমন একটি সাধারণ জায়গায় কোড স্থাপন করা যা অন্যান্য প্রকল্পগুলি / লোকেরা নির্ভর করে বরং ব্যয়বহুল হয়ে উঠতে পারে। ধরা যাক আপনার একটি কোডের টুকরা রয়েছে এবং অন্যান্য 4 টি প্রকল্প এতে নির্ভর করে। আপনার গ্রাহকদের মধ্যে একটি যা প্রকল্প এ ব্যবহার করে একটি বাগ খুঁজে পায় এবং আপনাকে একটি সমাধান করতে হবে। আপনি ফিক্স আউট তাড়াতাড়ি এবং গ্রাহক খুশি। তবে আপনি কেবল এমন কিছু কোড সংশোধন করেছেন যা অন্য 3 টি প্রকল্পের উপর নির্ভর করে। কোনও প্রান্ত শর্ত চালু হয়নি তা নিশ্চিত করার জন্য আপনি কি তাদের সবার পরীক্ষা করেছেন?
সাধারণ কোডটি আরও অনেক সাবধানতার সাথে তৈরি করতে হবে এবং মডিউল ইন্টারফেসগুলি অবশ্যই আরও ভাল নকশাকৃত হতে হবে কারণ সেই কোডটি অবশ্যই একটি নয় বরং 4 ক্লায়েন্টকে সমন্বিত করতে হবে এবং যারা প্রত্যেকে কেবল এই কোডটি কোনও পার্থক্যের তুলনায় সামান্য ব্যবহার করতে পারে।
যদি আপনার প্রকল্পগুলি বিভিন্ন প্রকাশের চক্রগুলিতে থাকে তবে আপনার প্রচলিত কোড পরিচালনা করার বিষয়ে আরও সতর্ক হওয়া দরকার। আপনি কেবল সাধারণ কোডটিতে পরিবর্তন করতে পারবেন না কারণ প্রকল্প বি এর নতুন কার্যকারিতা প্রয়োজন, যদি আপনি প্রকল্প সি এর চূড়ান্ত চিত্রটি কাটা থেকে 3 দিন দূরে থাকেন if
আমি বলছি না সাধারণ লাইব্রেরি সঠিক সমাধান নয়। আমি ডিআরওয়াইর একজন শক্তিশালী সমর্থক এবং এর আগেও আমি প্রচলিত কোড তৈরি করেছি এবং সমর্থন করেছি এবং তা অব্যাহত রেখেছি। কেবল এটি বাইরে রাখতে চেয়েছিলেন যে কোডটি সাধারণ করার পক্ষে এটির নিজস্ব ব্যয় হবে।
আপনি যদি কেবল এই কোডটি পুনরায় ব্যবহার করেন তবে এটি ততটা খারাপ নয়। আপনার যদি ইঞ্জিনিয়ারদের একটি দল থাকে এবং তারা সাধারণ কোডটি ব্যবহার শুরু করেন, ব্যয় আরও বেশি বেড়ে যায়। যদি অন্যরা জড়িত থাকে তবে একটি সাধারণ লাইব্রেরীতে কোড স্থাপনের কোডটি এমন একটি পয়েন্টে পৌঁছাতে যত সময় লাগে তার চেয়ে 3 গুণ বেশি সময় লাগবে বলে আপনি মনে করেন যে এটি "সম্পূর্ণ"। আপনার প্রয়োজন হবে ক) সমস্ত ধরণের প্রান্ত পরিস্থিতি এবং অবৈধ ব্যবহারের হাত থেকে রক্ষা করার জন্য গ্রন্থাগারটিকে আরও শক্তিশালী করা, খ) ডকুমেন্টেশন সরবরাহ করুন যাতে অন্যরা লাইব্রেরিটি ব্যবহার করতে পারে এবং গ) লাইব্রেরিটি যখন অন্যভাবে ব্যবহার করে তারা অন্যভাবে ডিবাগ করতে সহায়তা করে অনুমান করা হয়নি এবং আপনার ডকুমেন্টেশনগুলি তাদের নির্দিষ্ট ব্যবহারের ক্ষেত্রে আবরণ দেয় না।
আমি কিছু প্রস্তাব দিতে পারি:
- অটোমেটেড ইউনিট পরীক্ষাগুলি দ্বারা আচ্ছাদিত সাধারণ কোডটি আপনাকে অনেক দূর যেতে পারে এবং আপনাকে কিছুটা মনের ধারণা দিতে পারে যে আপনি যখন কোনও পরিবর্তন করেন, আপনি কেবল অন্য কোনও প্রকল্প ভাঙেন নি।
- আমি কেবল সাধারণ কোডে খুব স্থিতিশীল কার্যকারিতা রাখি। আপনি যদি টাইমার ম্যানেজমেন্ট করতে গত বছর কোনও ক্লাস লিখেছিলেন এবং আপনি 9 মাসে এটি পরিবর্তন করেন নি এবং এখন আপনার কাছে আরও 3 টি প্রকল্প রয়েছে যার টাইমার প্রয়োজন, তবে নিশ্চিত হন যে এটি একটি ভাল প্রার্থী। তবে আপনি যদি কেবল গত সপ্তাহে কিছু লিখেছিলেন, ভাল ... আপনার কাছে এমন অনেকগুলি বিকল্প নেই (এবং আমি পরবর্তী লোকের চেয়ে কপি / পেস্টিং কোডটি ঘৃণা করি) তবে আমি এটিকে সাধারণ করার বিষয়ে দু'বার চিন্তা করব।
- কোডের টুকরটি যদি তুচ্ছ হয় তবে আপনি এটি বেশ কয়েকটি স্থানে ব্যবহার করেছেন, সম্ভবত বুলেটটি কামড়ান, ডিআরওয়াইকে একা রেখে একাধিক অনুলিপিগুলিকে বাঁচতে দেওয়া ভাল।
- কখনও কখনও এটি সাধারণ কোডটি কেবল একটি সাধারণ স্থানে না রাখার এবং প্রত্যেককে এটির রেফারেন্স দেওয়ার জন্য অর্থ প্রদান করে। বরং সাধারণ কোডটিকে সংস্করণ, প্রকাশের তারিখ এবং সমস্ত কিছুর সাথে তার নিজের পুনরায় প্রকাশযোগ্য হিসাবে গণ্য করুন। এইভাবে প্রকল্প সি বলতে পারে, "আমি সাধারণ লাইব্রেরি v1.3 ব্যবহার করি" এবং যদি প্রকল্প ডিতে নতুন কার্যকারিতা প্রয়োজন হয় তবে আপনি v1.3 একা ছেড়ে যান, ভি 1.4 ছেড়ে দিন এবং প্রকল্প সি প্রভাবিত হবে না। মনে রাখবেন, সাধারণ কোডটিকে সাধারণ জায়গায় পরীক্ষা করে দেখার চেয়ে সাধারণ কোডটিকে নিজস্ব পণ্য হিসাবে বিবেচনা করা আরও ব্যয়বহুল।