জুনিয়র ডেভেলপারদের করা ভুলসমূহ
কাজ করে এমন কোড শিপ করা হলো একটি ন্যূনতম মান। এটি লক্ষ্য নয়।
আমি একবার একটি pull request রিভিউ করেছিলাম যা বুঝতে ৪৫ মিনিট সময় লেগেছিল। লজিক ঠিক ছিল। টেস্টগুলো পাস করেছিল। কিন্তু কোডটি এমনভাবে লেখা হয়েছিল যেন কেবল লেখকই এটি পড়বেন।
আমি যখন ফিডব্যাক দিলাম, ডেভেলপার বললেন, "কিন্তু তো এটা কাজ করছে।"
তিনি ঠিকই বলেছিলেন। এটি কাজ করছিল। আর এটাই ছিল আসল সমস্যা।
জুনিয়র ডেভেলপাররা প্রায়ই টেকনিক্যাল স্কিলের দিকে মনোযোগ দেন। কিন্তু আসল ঘাটতি থাকে প্রায়শই অভ্যাস এবং মানসিকতার ক্ষেত্রে।
এখানে কিছু সূক্ষ্ম ভুল দেওয়া হলো যা আপনার গতি কমিয়ে দেয়:
অন্যদের পরিবর্তে নিজের জন্য কোড লেখা কোড লেখার চেয়ে এটি পড়ার পরিমাণ অনেক বেশি। আজ আপনি যে ফাংশনটি লিখছেন, আগামী দুই বছরে হয়তো তিনজন ভিন্ন মানুষ সেটি ব্যবহার বা পরিবর্তন করতে পারে। যদি একজন অপরিচিত ব্যক্তি ৩০ সেকেন্ডের মধ্যে আপনার কোড বুঝতে না পারেন, তবে আপনি ব্যর্থ হয়েছেন।
না বুঝে কোড কপি করা Stack Overflow ব্যবহার করা ঠিক আছে। কিন্তু একটি regex pattern কীভাবে কাজ করে তা না জেনে কপি করা বিপজ্জনক। আপনি আপনার codebase-এ একটি 'ব্ল্যাক বক্স' তৈরি করছেন। যখন এটি ভেঙে যাবে, তখন আপনি এটি ডিবাগ করতে পারবেন না।
অপ্রয়োজনীয় জটিলতা যোগ করা জুনিয়ররা প্রায়শই জটিলতাকে দক্ষতার সাথে তুলনা করেন। তারা সহজ কাজের ক্ষেত্রেও design patterns প্রয়োগ করেন। অপ্রয়োজনীয় abstraction কোডকে ডিবাগ করা এবং পরিবর্তন করা কঠিন করে তোলে। শুধুমাত্র তখনই abstraction যোগ করুন যখন আপনি এর অনুপস্থিতিতে সমস্যার সম্মুখীন হবেন।
এরর মেসেজ অবহেলা করা এরর মেসেজ হলো বিনামূল্যে পাওয়া ডকুমেন্টেশন। স্ট্যাক ট্রেস (stack trace) দেখার সাথে সাথেই গুগলে সার্চ করতে যাবেন না। পুরো মেসেজটি পড়ুন। এটি প্রায়শই আপনাকে বলে দেয় ঠিক কোন লাইনে এবং কেন ত্রুটি ঘটেছে।
খুব দ্রুত বা খুব দেরিতে সাহায্য চাওয়া ১০ মিনিটের একটি সমস্যার জন্য তিন ঘণ্টা আটকে থাকবেন না। এটি অদক্ষতা। আবার কোনো কনটেক্সট বা প্রেক্ষাপট ছাড়াই শুধু একটি স্ক্রিনশট দিয়ে কোনো সিনিয়রকে পিন (ping) করবেন না। ২০ মিনিটের নিয়মটি অনুসরণ করুন: সমস্যাটি সমাধানের জন্য ২০ মিনিট চেষ্টা করুন। আপনি কী কী চেষ্টা করেছেন তা লিখে রাখুন। তারপর সেই ডকুমেন্টেশনসহ সাহায্য চান।
যা ইতিমধ্যে আছে তা পুনরায় তৈরি করা নতুন কোনো utility লেখার আগে codebase সার্চ করে দেখুন। আপনার টিমের সদস্যরা সম্ভবত ইতিমধ্যে সেই সমস্যার সমাধান করে রেখেছে।
দুর্বল কমিট মেসেজ "fix bug"-এর মতো একটি কমিট মেসেজ আপনার টিমকে কিছুই জানায় না। কী পরিবর্তন করা হয়েছে এবং কেন করা হয়েছে তা ব্যাখ্যা করুন। Git history-কে ডকুমেন্টেশন হিসেবে বিবেচনা করুন।
রিকোয়ারমেন্টস বা প্রয়োজনীয়তাকে আইন হিসেবে গণ্য করা রিকোয়ারমেন্টস প্রায়শই edge cases গুলো এড়িয়ে যায়। আপনাকে যা বলা হয়েছে শুধু সেটুকুই ইমপ্লিমেন্ট করবেন না। পরিস্থিতি খারাপ হলে কী হবে তা জিজ্ঞাসা করুন।
"Merged" বাটনে থেমে যাওয়া আপনার PR মার্জ হওয়ার সাথে সাথে মালিকানা বা দায়িত্ব শেষ হয়ে যায় না। আপনার ফিচারটি QA পর্যায়ে কীভাবে কাজ করছে তা অনুসরণ করুন। প্রোডাকশনে এটি পর্যবেক্ষণ করুন। এরর রিপোর্টগুলো পড়ুন।
সবচেয়ে বড় ঘাটতি হলো জবাবদিহিতা। সিনিয়র ডেভেলপাররা শুধু কোড লেখেন না। তারা নতুন কোনো সমস্যা তৈরি না করেই সমস্যার সমাধান করেন।
"কাজ শেষ করা"-র জন্য অপ্টিমাইজ করা বন্ধ করুন। "ভালো কাজ করা"-র জন্য অপ্টিমাইজ করা শুরু করুন।