নবজাতক প্রোগ্রামারদের দ্বারা করা সাধারণ ভুলের বিশ্লেষণ, pt. 1

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

1. আরও অভিজ্ঞ সহকর্মীদের কাছ থেকে সাহায্য চাওয়ার ভয়

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

2. আপনার নিজের থেকে তথ্য অনুসন্ধান করার চেষ্টা না

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

3. অন্ধভাবে কপি এবং পেস্ট করা

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

4. ভুল সমাধান সঙ্গে স্টিকিং

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

5. আপনার বর্তমান অ্যাসাইনমেন্ট সম্পর্কে প্রশ্ন জিজ্ঞাসা করার ভয়

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

6. দলের নেতৃত্বে অবাস্তবভাবে উচ্চ প্রত্যাশা রাখা

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

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

বিকল্পভাবে, আপনি IDE-তে টীকাগুলি দেখতে পারেন কে এবং কখন একটি নির্দিষ্ট লাইনের কোড শেষবার পরিবর্তন করা হয়েছিল। আপনার প্রশ্ন জিজ্ঞাসা করার জন্য সবচেয়ে উপযুক্ত ব্যক্তি কে তা সঠিকভাবে আপনি কীভাবে খুঁজে পেতে পারেন। আপনি সম্ভবত ইতিমধ্যেই বুঝতে পেরেছেন, যখন টিম লিডের প্রশ্ন আসে, ঠিক যেমন সহকর্মীদের প্রশ্নের ক্ষেত্রে, আপনাকে একটি সুখী মাধ্যম খুঁজে বের করার চেষ্টা করতে হবে — প্রশ্ন জিজ্ঞাসা করতে ভয় পাবেন না, তবে খুব বেশি জিজ্ঞাসা করবেন না তাদের মধ্যে.

7. কোড পর্যালোচনার ভয়

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

8. রহস্যময় সিদ্ধান্তের জন্য প্রবণতা

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

9. চাকা পুনরায় উদ্ভাবন

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

10. পরীক্ষা লিখতে ব্যর্থতা

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

11. অত্যধিক মন্তব্য

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

Cat cat = new Cat(); // Cat object

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

12. খারাপ নামকরণ

নবাগতরা তাদের ক্লাস, ভেরিয়েবল, পদ্ধতি ইত্যাদির নামকরণে দ্রুত এবং ঢিলেঢালাভাবে খেলতে পারে। উদাহরণস্বরূপ, এমন একটি ক্লাস তৈরি করে যার নাম তার উদ্দেশ্য বর্ণনা করে না। অথবা তারা একটি সংক্ষিপ্ত নাম সহ একটি ভেরিয়েবল ঘোষণা করে, x এর মতো কিছু । তারা যখন n এবং y নামে আরও দুটি চলকতৈরি হয়, x এর জন্য দায়ী কি মনে রাখা খুব কঠিন হয়ে পড়ে। এই পরিস্থিতির মুখোমুখি হয়ে, আপনাকে কোডটি সম্পর্কে সাবধানে চিন্তা করতে হবে, এটিকে একটি মাইক্রোস্কোপের নীচে বিশ্লেষণ করতে হবে (সম্ভবত একটি ডিবাগার ব্যবহার করে), কার্যকারিতা অধ্যয়ন করতে হবে যাতে কী ঘটছে তা বোঝার জন্য। আমি উপরে উল্লিখিত সঠিক নামকরণের রীতিগুলি এখানেই আমাদের সাহায্যে আসে৷ সঠিক নাম কোড পঠনযোগ্যতা উন্নত করে, এইভাবে কোডের সাথে নিজেকে পরিচিত করার জন্য প্রয়োজনীয় সময় হ্রাস করে, কারণ একটি পদ্ধতি ব্যবহার করা অনেক সহজ যখন এর নামটি প্রায় তার কার্যকারিতা বর্ণনা করে। কোডের সবকিছুতে নাম থাকে (ভেরিয়েবল, পদ্ধতি, ক্লাস, অবজেক্ট, ফাইল ইত্যাদি), তাই সঠিক, পরিষ্কার কোড তৈরি করার সময় এই পয়েন্টটি খুবই গুরুত্বপূর্ণ হয়ে ওঠে। আপনার মনে রাখা উচিত যে নামের অর্থ বোঝানো উচিত, উদাহরণস্বরূপ, কেন পরিবর্তনশীল বিদ্যমান, এটি কী করে, এবং কিভাবে এটি ব্যবহার করা হয়। আমি একাধিকবার নোট করব যে একটি ভেরিয়েবলের জন্য সেরা মন্তব্য হল এটি একটি ভাল নাম দেওয়া। মন্তব্য এবং সঠিক নামকরণের গভীর অধ্যয়নের জন্য, আমি নিরবধি ক্লাসিক পড়ার পরামর্শ দিই:রবার্ট মার্টিন দ্বারা "ক্লিন কোড: এজিল সফ্টওয়্যার কারুশিল্পের একটি হ্যান্ডবুক" । সেই নোটে, এই নিবন্ধের প্রথম অংশ (আমার প্রতিচ্ছবি) শেষ হয়েছে। চলবে...