সব গ্রহণ করুন, কিছুই বুঝবেন না
কোড সাজেশন গ্রহণ করার জন্য এন্টার (Enter) চাপ দেওয়া স্ক্রল করার চেয়ে অনেক সহজ। মাত্র একটি কি-স্ট্রোক (keystroke) কোডটিকে আপনার করে তোলে। কিন্তু সেই কোড পড়া এবং বোঝার গতি মোটেও বাড়েনি।
আপনি কত দ্রুত কোড গ্রহণ করছেন এবং কত দ্রুত তা বুঝতে পারছেন—এই দুটির মধ্যে একটি ব্যবধান রয়েছে। আর এই ব্যবধানের মধ্যেই ভুলগুলো ঘটে।
টেকনিক্যাল ডেট (Technical debt)-এর আগে সুনির্দিষ্ট কারণ ছিল। হয়তো ডেডলাইন খুব কম ছিল অথবা আপনি কাজের শর্টকাট খুঁজছিলেন। আপনি কারণটি চিহ্নিত করতে পারতেন। কিন্তু এখন আপনি একটি শান্ত মঙ্গলবারেই ডেট তৈরি করছেন। আপনি পরপর ছয়টি সাজেশন গ্রহণ করছেন কারণ সেগুলো দেখতে ঠিক মনে হচ্ছে। কেউ আপনাকে তাড়াহুড়ো করতে বলেনি, কিন্তু কোডটি পরীক্ষা করা হয়নি।
ব্রায়ান কার্নিঘান (Brian Kernighan) ১৯৭৪ সালে বলেছিলেন যে, ডিবাগিং (debugging) করা একটি প্রোগ্রাম লেখার চেয়ে দ্বিগুণ কঠিন। তিনি মানুষের লেখা কোড নিয়ে কথা বলছিলেন। অন্তত মানুষ তাদের নিজেদের কাজ বুঝতে পারে।
আজ একটি সাজেশন লিন্টার (linter) পাস করতে পারে এমনকি টেস্টও (tests) পাস করতে পারে। তবুও এটি ভুল কোনো ধারণার ওপর ভিত্তি করে হতে পারে। এটি ঘটে কারণ মানুষ সাজেশনটিকে কোড হিসেবে না দেখে আউটপুট হিসেবে দেখে। যে আউটপুট দেখতে ভালো লাগে, তা সহজেই অনুমোদিত হয়ে যায়।
যদি একটি মডেল কোড এবং টেস্ট উভয়ই লিখে দেয়, তবে আপনি আসলে ছাত্রের নিজের উত্তর দিয়ে তার হোমওয়ার্ক গ্রেডিং করছেন। এটি আপনাকে জানায় না যে লজিকটি সঠিক কি না। এটি আপনাকে জানায় না যে এজ কেসগুলো (edge cases) কভার করা হয়েছে কি না। যখন কোডটি আপনার নিজের এডিটর এবং আপনার নিজস্ব স্টাইলে সামনে আসে, তখন এটি ভুলে যাওয়া খুব সহজ।
এটি প্রকৃত সমস্যা তৈরি করে:
- আপনি এমন কোড ডিবাগ করছেন যা আপনি কখনোই পড়েননি। কয়েক সপ্তাহ পর যখন কিছু ভেঙে পড়ে, তখন আপনাকে শূন্য থেকে শুরু করতে হয়।
- এজ কেসগুলো (Edge cases) ব্যর্থ হয়। একটি সাজেশন 'হ্যাপি পাথ' (happy path) খুব ভালোভাবে সামলাতে পারে। এতে একটি 'null check' থাকতে পারে। কিন্তু এটি আপনার ব্যবসার প্রয়োজনীয় সুনির্দিষ্ট লজিকটি মিস করতে পারে।
- আপনি আপনার নিজের পুল রিকোয়েস্ট (pull requests) ডিফেন্ড করতে পারেন না। যদি একজন রিভিউয়ার জিজ্ঞাসা করেন আপনি কেন একটি নির্দিষ্ট মেথড বেছে নিয়েছেন, তবে আপনার কাছে কোনো উত্তর থাকে না। আপনি সিদ্ধান্তটি নেননি; আপনি শুধু সেটি প্রত্যাখ্যান করেননি।
এই টুলগুলো দরকারী। এগুলো আপনাকে কোডবেস (codebases) অন্বেষণ করতে বা নতুন ফিচার পরিকল্পনা করতে সাহায্য করে। সমস্যা হলো আপনার দৃষ্টিভঙ্গি। আপনাকে প্রতিটি সাজেশনকে কেবল এক পলক দেখে যাওয়ার বিষয় হিসেবে নয়, বরং পড়ার এবং সিদ্ধান্ত নেওয়ার বিষয় হিসেবে বিবেচনা করতে হবে।
বয়লারপ্লেট (boilerplate) বা দ্রুত স্ক্রিপ্টের জন্য গতি ঠিক আছে। কিন্তু বিজনেস লজিক বা সিকিউরিটির ক্ষেত্রে আপনার দৃষ্টিভঙ্গি পরিবর্তন করতে হবে। কোডটি এমনভাবে পড়ুন যেন এটি আপনার দায়িত্ব। কারণ এটি আপনার দায়িত্বই হবে।
এর পরিবর্তে এই কাজগুলো করুন:
- কোড চাওয়ার আগে মডেলের সাথে আপনার সমাধানটি নিয়ে আলোচনা করুন।
- ডিফ (diff) এমনভাবে রিভিউ করুন যেন আপনি নিজেই এটি লিখেছেন।
- কোড গ্রহণ করার আগে টুলটিকে তার যুক্তির ব্যাখ্যা দিতে বলুন।
- সাজেশনগুলোকে একজন জুনিয়র ডেভেলপারের কাজের মতো বিবেচনা করুন। এটি দরকারী কিন্তু এটিই চূড়ান্ত সত্য নয়।
- যে লাইনগুলো আপনাকে অবাক করে, সেখানে গতি কমিয়ে দিন। অবাক হওয়া একটি সংকেত।
কি-স্ট্রোকের খরচ কমেছে, কিন্তু আপনার দায়িত্ব কমেনি। উপলব্ধি ছাড়া গতি কেবল দ্রুতগতির ঋণ।
Source: https://dev.to/cloudx/accept-all-understand-none-4dob
Optional learning community: https://t.me/GyaanSetuAi