অনুসন্ধানের জন্য সফ্টওয়্যার: আবিষ্কারে ভারসাম্য অর্জন করা

আমি সারাজীবন গবেষণায় কাজ করেছি, তাই আমি একটি স্টেরিওটাইপ জানি যে গবেষকরা কুৎসিত কোড লেখেন (যেমন এখানে দেখুন, এখানে বা এখানে )। কিন্তু আমি ভেবেছিলাম: আমরা এটা ঠিক করতে পারি, তাই না? তাই একাধিকবার আমি চমৎকার গবেষণা কাঠামো ডিজাইন করার চেষ্টা করেছি। আমি সফ্টওয়্যার ইঞ্জিনিয়ারিং বই এবং আমার পড়তে পছন্দ করা ব্লগগুলি ব্যবহার করে ইন্টারফেসগুলি আনার এবং চমৎকার বিমূর্ততা তৈরি করার চেষ্টা করেছি।

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

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

1. কিছু কৌশলগত প্রযুক্তি ঋণ গ্রহণ করুন

একটি কোম্পানিতে একটি সফল গবেষণা প্রকল্প দুটি পর্যায় রয়েছে: অনুসন্ধান এবং শোষণ। "অন্বেষণ"-এ আপনি যতটা সম্ভব বৈচিত্র্যময় সমাধান চেষ্টা করতে চান। "শোষণ" চলাকালীন আপনাকে সর্বোত্তম সমাধানটিকে শক্তিশালী করতে হবে এবং এটি একটি দরকারী পণ্যে পরিণত করতে হবে।

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

কিন্তু প্রথম "অন্বেষণ" পর্যায়ে আপনি এমন ভিত্তি তৈরি করছেন না যা চিরকাল বেঁচে থাকবে। আসলে, যদি আপনার বেশিরভাগ প্রচেষ্টা বেঁচে থাকে, তাহলে আপনি (সংজ্ঞা অনুসারে) যথেষ্ট অন্বেষণ করেননি।

এই পোস্টের অনেক অনুশীলনগুলি সাধারণত "প্রযুক্তি ঋণ" হয়ে যাওয়ার উদাহরণ। পরিষ্কার পুনঃব্যবহারযোগ্য ভাল-বিমূর্ত কোড না লিখে আপনি এটি পান। ঋণ কি সবসময় খারাপ? আমরা কখনই ঋণ বা বন্ধক পেতে পছন্দ করি না, তবে টাকা ধার করা প্রায়শই জীবনের একটি ভাল কৌশল। দ্রুত এবং পরে লাভ করতে ঋণ পেতে ঠিক আছে.

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

কোড পুনঃব্যবহারের বিরুদ্ধে মামলা

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

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

নতুন কিছু আমদানি করার আগে দুবার চিন্তা করুন

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

কিছুর উপর নির্ভর করা সম্ভবত ভাল যদি:

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

• 
  

কিন্তু নির্ভরতা সম্পর্কে সতর্ক থাকুন যদি:

• আপনি কীভাবে এটি দ্রুত ব্যবহার করবেন তা বুঝতে পারবেন না, এটি খুব নতুন (বা খুব পুরানো) বা কেউ এটি সম্পর্কে জানে বলে মনে হয় না; কোন ডক্স বা পরীক্ষা আছে

• এটি আপনার মনোরেপো থেকে এবং ক্রমাগত অন্যান্য দল দ্বারা পরিবর্তন করা হচ্ছে

• এটি অন্যান্য অনেক নির্ভরতা এবং সরঞ্জামের মধ্যে টানছে; অথবা এটি ইনস্টল করা কঠিন

• এবং অবশেষে, আপনি অনুভব করেন যে আপনি (বা কিছু এলএলএম) কয়েক ঘন্টার মধ্যে এই কোডটি লিখতে পারেন।

  
  

একটি সুস্পষ্ট নির্ভরতার পরিবর্তে, আপনি একটি সুন্দর গো প্রবাদ অনুসরণ করতে পারেন: " একটু অনুলিপি করা একটু নির্ভরতার চেয়ে ভাল ", যা আমাদের পরবর্তী বিষয়।

কপিপেস্ট আপনাকে পরীক্ষার স্বাধীনতা দেয়

কেউ কেউ বলে যে " কপি-পেস্ট হওয়া উচিত অবৈধ "। কিন্তু আমার বিস্ময়ের সাথে আমি নিজেকে প্রায়ই এটির পক্ষে তর্ক করতে দেখেছি। অন্বেষণ পর্বের সময় কপিপেস্ট সর্বোত্তম পছন্দ হতে পারে।

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

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

কপিপেস্টের বিকল্প একটি শাখায় অবস্থান করছে। কিন্তু আমি মনে করি এটা টিমওয়ার্কে অনেক বেশি মাথা ঘামায়। এছাড়াও, আমি কপিপেস্টের সৌন্দর্য সম্পর্কে আরও বেশ কয়েকটি পোস্ট পেয়েছি - উপসংহারে আরও পোস্ট দেখুন।

শেয়ার করা গবেষণা কোড বজায় রাখা কঠিন

ব্যাপকভাবে ব্যবহৃত শেয়ার্ড কোডের রক্ষণাবেক্ষণের জন্য অনেক কাজ প্রয়োজন। Pytorch সংস্করণের বিরুদ্ধে প্লট করা ফাইল লাইনের torch.nn.Module নম্বরটি দেখুন। আপনি দেখতে পাচ্ছেন যে এমনকি সবচেয়ে উন্নত গবেষণা দলগুলি জটিলতা নিয়ন্ত্রণে রাখতে লড়াই করে।

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

অন্বেষণের জন্য ডিজাইন, কোড পুনঃব্যবহারের জন্য নয়

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

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

অকাল সফ্টওয়্যার বিনিয়োগে মূল্যবান সময় নষ্ট করবেন না যেমন:

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

2. দ্রুত অনুসন্ধানে বিনিয়োগ করুন

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

সাধারণ পথের গতি বাড়ান

আপনি চেষ্টা করতে চান বিভিন্ন গবেষণা পাথ আছে. এমন একটি নকশা, একটি লাইব্রেরি বা একটি অপ্টিমাইজেশান আছে যা বেশিরভাগ পথ থেকে সময় কমিয়ে দেবে? কোনো কিছুকে অতিরিক্ত ইঞ্জিনিয়ার না করার ব্যাপারে আপনার সতর্কতা অবলম্বন করা উচিত কারণ আপনি যে সমস্ত ধারণাগুলি চেষ্টা করতে চলেছেন তা আপনি সবসময় জানেন না। এটি প্রতিটি প্রকল্পের জন্য খুব কাস্টম, কিন্তু এখানে কিছু উদাহরণ রয়েছে:

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

দ্রুত শাখা আউট

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

তবে এটি একটি সফ্টওয়্যার পোস্ট, তাই নতুন প্রকল্পগুলিকে সহজে শাখা তৈরি করার জন্য এখানে কিছু অনুশীলন রয়েছে:

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

শব্দ অনুপাত সংকেত বৃদ্ধি

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

• 
  

• পার্শ্ব প্রতিক্রিয়া সহ কোড এড়িয়ে চলুন

• ক্লাসের পরিবর্তে ফাংশনে ডিফল্ট; এবং ক্লাসের সাথে, এনক্যাপসুলেশন বনাম উত্তরাধিকার পছন্দ করে

• ফাংশন/ক্লাস/মডিউলের দৈর্ঘ্য কমানো; ইফ-স্টেটমেন্টের সংখ্যা কমিয়ে দিন

• পাইথন ভালো করে জান, কিন্তু সহজ কৌশল ব্যবহার করুন। মেটাক্লাস, ডেকোরেটর এবং কার্যকরী প্রোগ্রামিংয়ের বুদ্ধিবৃত্তিক আগাছায় যাওয়ার প্রলোভনকে প্রতিহত করুন।

  
  

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

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

উপসংহার

পাঞ্চলাইন গবেষণা কোড সম্পর্কে এই পোস্ট থেকে আসে:

“আপনি [ভাল সফ্টওয়্যার ডিজাইন] নিয়ে বিরক্ত করবেন না কারণ কোডটি বিন্দু নয়। কোডটি এমন একটি টুল যা আপনাকে আপনার প্রয়োজনীয় উত্তর দেয়” ।

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

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

• পুনঃব্যবহারযোগ্য কোড: ভাল, খারাপ এবং কুৎসিত

• যখন এটি নিজেকে পুনরাবৃত্তি করার অর্থ মেকস

• পুনঃব্যবহারের সুবিধা এবং অসুবিধা সহ ভারসাম্যপূর্ণ স্ট্যাকএক্সচেঞ্জ

  
  

এবং এখানে কপিপেস্টিং অনুশীলনের জন্য আরও কয়েকটি পোস্ট রয়েছে:

• কপিপেস্ট কি সত্যিই একটি সমস্যা?

• কখন আপনার কোড কপি-পেস্ট করা উচিত?

• কপি-পেস্ট প্রোগ্রামিংয়ের ভাল এবং খারাপ

• "5 YOE সহ একজন সিনিয়র হিসাবে, আমি মনে করি আমার বেতনের একটি অংশ হল কোন কোডটি অনুলিপি করতে হবে তা জানা"

  
  

পড়ার জন্য আপনাকে ধন্যবাদ! আমি মনে করি কিছু বিট একটু বিতর্কিত, দয়া করে আমাকে মন্তব্যে জানান!