একটি সঠিকভাবে কাজ প্রোগ্রাম

1. একজন প্রোগ্রামারের কাজ

প্রায়শই নবীন প্রোগ্রামাররা একজন প্রোগ্রামারের কাজ সম্পর্কে অভিজ্ঞ প্রোগ্রামাররা যেভাবে ভাবেন তার থেকে সম্পূর্ণ ভিন্নভাবে চিন্তা করেন।

নতুনরা প্রায়ই এমন কিছু বলে যে "প্রোগ্রামটি কাজ করে, আপনার আর কি দরকার?" একজন অভিজ্ঞ প্রোগ্রামার জানেন যে "সঠিকভাবে কাজ করে" একটি প্রোগ্রামের প্রয়োজনীয়তাগুলির মধ্যে একটি মাত্র , এবং এটি সবচেয়ে গুরুত্বপূর্ণ জিনিসও নয় !

কোড পঠনযোগ্যতা

সবচেয়ে গুরুত্বপূর্ণ বিষয় হল প্রোগ্রাম কোড অন্যান্য প্রোগ্রামারদের কাছে বোধগম্য । এটি একটি সঠিকভাবে কাজ করা প্রোগ্রামের চেয়ে বেশি গুরুত্বপূর্ণ। অনেক বেশি.

আপনার যদি এমন একটি প্রোগ্রাম থাকে যা সঠিকভাবে কাজ না করে তবে আপনি এটি ঠিক করতে পারেন। কিন্তু আপনার যদি এমন একটি প্রোগ্রাম থাকে যার কোডটি বোধগম্য নয়, আপনি এটির সাথে কিছু করতে পারবেন না।

শুধু নোটপ্যাডের মতো যেকোন কম্পাইল করা প্রোগ্রাম নিন এবং এর পটভূমির রঙ লাল করে দিন। আপনার একটি কার্যকরী প্রোগ্রাম আছে, কিন্তু আপনার কাছে বোধগম্য সোর্স কোড নেই: এর মতো একটি প্রোগ্রামে পরিবর্তন করা অসম্ভব।

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

প্রতিটি ব্যবহারের ক্ষেত্রে অ্যাকাউন্টিং

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

একজন নবীন প্রোগ্রামার কীভাবে এসএমএস বার্তা পাঠাতে দেখেন:

একজন পেশাদার প্রোগ্রামার কীভাবে এটি দেখেন:

"সঠিকভাবে কাজ করে" দৃশ্যকল্পটি সাধারণত শুধুমাত্র একটি অনেকগুলি সম্ভব। এবং সেই কারণেই অনেক নতুনরা CodeGym-এর টাস্ক ভ্যালিডেটর সম্পর্কে অভিযোগ করে: 10টি কাজের মধ্যে শুধুমাত্র একটি দৃশ্য, এবং নবাগত প্রোগ্রামার মনে করেন যে এটি যথেষ্ট।

2. অস্বাভাবিক পরিস্থিতি

যেকোন কর্মসূচী বাস্তবায়নে অস্বাভাবিক পরিস্থিতি দেখা দিতে পারে।

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

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

এই কারণেই প্রোগ্রামগুলির বেশ দীর্ঘ সময়ের জন্য খুব সাধারণ আচরণ ছিল: যদি প্রোগ্রামে একটি ত্রুটি ঘটে তবে প্রোগ্রামটি বন্ধ হয়ে যায়। এবং যে একটি চমত্কার ভাল পদ্ধতির ছিল.

ধরা যাক আপনি ডিস্কে একটি নথি সংরক্ষণ করতে চান, সংরক্ষণ প্রক্রিয়া চলাকালীন আপনি আবিষ্কার করেন যে যথেষ্ট ডিস্ক স্থান নেই। আপনি কোন আচরণটি সবচেয়ে বেশি পছন্দ করবেন:

• প্রোগ্রাম শেষ হয়
• প্রোগ্রামটি চলতে থাকে, কিন্তু ফাইলটি সংরক্ষণ করে না।

একজন নবীন প্রোগ্রামার ভাবতে পারে যে দ্বিতীয় বিকল্পটি আরও ভাল, কারণ প্রোগ্রামটি এখনও চলছে। কিন্তু বাস্তবে তা নয়।

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

যদি প্রোগ্রামটি যা করা দরকার তা করতে না পারে তবে সবকিছু ঠিক আছে এমন ভান চালিয়ে যাওয়ার চেয়ে এটিকে বন্ধ করা ভাল। একটি প্রোগ্রাম যখন এটি নিজে থেকে ঠিক করতে পারে না এমন একটি ব্যর্থতার সম্মুখীন হয় তখন এটি করতে পারে সবচেয়ে ভাল জিনিসটি হল অবিলম্বে ব্যবহারকারীকে সমস্যাটি রিপোর্ট করা৷

3. ব্যতিক্রম সম্পর্কে পটভূমি

প্রোগ্রামগুলি শুধুমাত্র অস্বাভাবিক পরিস্থিতির সম্মুখীন হয় না। এগুলি প্রোগ্রামগুলির ভিতরেও ঘটে - পদ্ধতিতে। উদাহরণ স্বরূপ:

• একটি পদ্ধতি ডিস্কে একটি ফাইল লিখতে চায়, কিন্তু কোন স্থান নেই।
• একটি পদ্ধতি একটি ভেরিয়েবলের উপর একটি ফাংশন কল করতে চায়, কিন্তু ভেরিয়েবলটি নাল এর সমান।
• 0 দ্বারা বিভাজন একটি পদ্ধতিতে ঘটে।

এই ক্ষেত্রে, কলিং পদ্ধতি সম্ভবত পরিস্থিতি সংশোধন করতে পারে (একটি বিকল্প দৃশ্যকল্প চালায়) যদি এটি জানে যে কল পদ্ধতিতে কী ধরনের সমস্যা হয়েছে।

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

একসময়, প্রোগ্রামাররা এই প্রশ্নটি নিয়ে চিন্তাভাবনা করেছিল এবং নিম্নলিখিত সমাধান নিয়ে এসেছিল: সমস্ত পদ্ধতি/ফাংশনকে অবশ্যই একটি ত্রুটি কোড ফেরত দিতে হবে যা তাদের মৃত্যুদন্ডের ফলাফল নির্দেশ করে। যদি একটি ফাংশন নিখুঁতভাবে কাজ করে, এটি 0 ফেরত দেয় । যদি না হয়, এটি একটি ত্রুটি কোড ফেরত দিয়েছে (শূন্য নয়)।

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

File file = new File("ca:\\note.txt");
file.writeLine("Text");
file.close();

File file = new File("ca:\\note.txt");
int status = file.writeLine("Text");
if (status == 1)
{
   ...
}
else if (status == 2)
{
   ...
}
status = file.close();
if (status == 3)
{
   ...
}

আরও কি, প্রায়শই একটি ফাংশন যা আবিষ্কার করে যে একটি ত্রুটি ঘটেছে তার সাথে কী করতে হবে তা জানে না: কলকারীকে ত্রুটিটি ফিরিয়ে দিতে হয়েছিল, এবং কলকারীর কলকারী এটি তার কলারকে ফিরিয়ে দেয় এবং আরও অনেক কিছু।

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

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