কোড রিভিউ — এটি কী, কোড রিভিউ এবং PR চেকিং কীভাবে কাজ করে

কোড রিভিউ কী

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

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

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

কোড রিভিউতে কী চেক করবেন

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

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

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

• আর্কিটেকচার — সমাধানের সঠিকতা, SOLID মেনে চলা, ওভার-ইঞ্জিনিয়ারিংয়ের অনুপস্থিতি।
• যুক্তি — ত্রুটি এবং সীমান্ত ক্ষেত্র সহ সমস্ত পরিস্থিতি পরিচালনা।
• পরীক্ষা — নতুন পরিবর্তনের কভারেজ, কোনও ভাঙা বিদ্যমান পরীক্ষা নেই।
• নিরাপত্তা — ইনজেকশন, XSS, CSRF, লগের মাধ্যমে ডেটা ফাঁস।
• কর্মক্ষমতা — অ্যালগরিদম জটিলতা, N+1 কোয়েরি, মেমরি ফাঁস।

রিভিউয়ের আকার: কেন 400 লাইন সর্বোচ্চ

PR আকার সীমা কোড রিভিউ কার্যকারিতার সবচেয়ে গুরুত্বপূর্ণ মেট্রিক। Cisco (2015) এর একটি গবেষণা এবং SmartBear এবং Google-এর পরবর্তী পরীক্ষাগুলি দেখিয়েছে যে পর্যালোচনার পরিমাণ 400 লাইন অতিক্রম করলে, পর্যালোচকের ত্রুটি খুঁজে পাওয়ার ক্ষমতা তীব্রভাবে হ্রাস পায়। যদি PR 400 লাইন অতিক্রম করে, ত্রুটিগুলি এলোমেলো সম্ভাবনার চেয়ে বেশি সনাক্ত করা যায় না।

সর্বোত্তম আকার: প্রতি PR-এ 200–400 লাইন। এই পরিমাণ 30–60 মিনিটে মনোযোগ বজায় রেখে পর্যালোচনা করা যেতে পারে। Google সম্পূর্ণ মনোযোগ সহ প্রতি পর্যালোচনা রাউন্ডে 200 লাইনের বেশি না করার পরামর্শ দেয়। যদি পরিবর্তনগুলি বড় হয়, কাজটি কয়েকটি অনুক্রমিক PR-এ বিভক্ত করা উচিত, প্রতিটি যুক্তিযুক্তভাবে সম্পূর্ণ পরিবর্তন উপস্থাপন করে।

পর্যালোচনার সময়: PR তৈরির 24 ঘন্টার মধ্যে। যদি পর্যালোচনা কয়েক দিন ধরে টানা যায়, কাজের প্রসঙ্গ হারিয়ে যায় এবং লেখককে মন্তব্যের জবাব দেওয়ার সময় প্রসঙ্গ পুনরুদ্ধার করতে সময় ব্যয় করতে হয়। শক্তিশালী কোড রিভিউ সংস্কৃতি সহ দলগুলি পর্যালোচনায় SLA নির্ধারণ করে: উদাহরণস্বরূপ, গুরুত্বপূর্ণ পরিবর্তনের জন্য 4 ঘন্টা এবং নিয়মিত পরিবর্তনের জন্য 24 ঘন্টা।

কীভাবে ভাল রিভিউ মন্তব্য লিখবেন

মন্তব্যের সুর কোড রিভিউ কার্যকারিতার জন্য গুরুত্বপূর্ণ। “এটি ভুল” এর মতো মন্তব্য প্রতিরক্ষামূলক প্রতিক্রিয়া সৃষ্টি করে এবং লেখককে দরকারী তথ্য দেয় না। আরও ভাল ফর্মুলেশন হল একটি প্রশ্ন-পরামর্শ: “এই পদ্ধতি সম্পর্কে আপনার কী মত?”, “এটি user == nil হলে NPE ঘটাতে পারে। সম্ভবত একটি গার্ড যোগ করবেন?”। প্রশ্নগুলি কম সংঘাতপূর্ণ এবং আলোচনাকে উদ্দীপিত করে।

একটি ভাল মন্তব্যে তিনটি অংশ অন্তর্ভুক্ত থাকে: কী ভুল, কেন এটি সমস্যা এবং কীভাবে এটি ঠিক করবেন। উদাহরণ: “এই লুপটি নেস্টেড contains-এর কারণে O(n²) ব্যবহার করে, যা 10k+ রেকর্ডের সাথে ধীর হতে পারে। O(1) লুকআপের জন্য Set দিয়ে প্রতিস্থাপন করার চেষ্টা করুন।” এই ফর্মুলেশন একসঙ্গে সমস্যা চিহ্নিত করে, এর গুরুত্ব ব্যাখ্যা করে এবং সমাধানের পরামর্শ দেয় — লেখককে অনুমান করতে হয় না।

GitHub এবং GitLab সাজেশন সমর্থন করে — ইনলাইন কোড পরিবর্তন প্রস্তাব। একজন পর্যালোচক লিখতে পারেন: “```suggestion Filter empty strings before processing```” এবং লেখক এক ক্লিকে পরিবর্তন প্রয়োগ করতে পারেন। এটি ছোট সংশোধনগুলি দ্রুত করে এবং পর্যালোচনা রাউন্ডের সংখ্যা হ্রাস করে। বড় পরিবর্তনের জন্য, সাজেশনে বড় ব্লক এম্বেড করার চেয়ে সাধারণ মন্তব্য লেখা ভাল।

# ভাল কোড রিভিউ মন্তব্যের টেমপ্লেট

# খারাপ: "This code is wrong"
# ভাল: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub suggestion সিনট্যাক্স:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

দলে কোড রিভিউ ওয়ার্কফ্লো

একটি কার্যকর পর্যালোচনা ওয়ার্কফ্লো চারটি ধাপে নির্মিত। প্রথম — লেখক PR প্রস্তুত করেন: একটি স্পষ্ট শিরোনাম লেখেন (যেমন, “feat: add password reset screen”), পরিবর্তনের বিবরণ, ট্র্যাকারে কাজের লিঙ্ক এবং পরীক্ষার নির্দেশনা যোগ করেন। দ্বিতীয় — লেখক অটো-অ্যাসাইন (CODEOWNERS-এর ভিত্তিতে) বা ম্যানুয়ালি পর্যালোচক নিয়োগ করেন।

তৃতীয় ধাপ — পর্যালোচক কোড পরীক্ষা করেন এবং মন্তব্য রাখেন। চতুর্থ — লেখক সংশোধন করেন, মন্তব্যের জবাব দেন এবং পুনরায় পর্যালোচনার অনুরোধ করেন। অনুমোদন না পাওয়া পর্যন্ত চক্র পুনরাবৃত্তি হয়। অনুমোদনের পরে, লেখক মার্জ করেন (বা বট এটি করে)। Mergify বা GitHub Auto-merge-এর মাধ্যমে অটোমেশন চূড়ান্ত ধাপটি দ্রুত করে।

একটি গুরুত্বপূর্ণ ওয়ার্কফ্লো উপাদান — অব্যবহৃত PR ব্যবস্থাপনা। যদি PR 3 দিনের বেশি পর্যালোচনা ছাড়া থাকে, প্রক্রিয়া ব্লক হয়ে যায়। সমাধান: পর্যালোচক রোটেশন (যদি নিযুক্ত পর্যালোচক অনুপলব্ধ হন), Slack/Teams-এর মাধ্যমে বিজ্ঞপ্তি, পর্যালোচনার সময় সীমা (SLA)। কিছু দলে, 7 দিনের বেশি পর্যালোচনা ছাড়া PR স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যায় এবং লেখক main-এর সাথে সিঙ্ক করার পরে একটি নতুন তৈরি করেন।

• PR তৈরি — স্পষ্ট শিরোনাম, বিবরণ, কাজের লিঙ্ক, UI পরিবর্তনের জন্য স্ক্রিনশট।
• নিয়োগ — CODEOWNERS-এর মাধ্যমে অটো-অ্যাসাইন বা 1–2 পর্যালোচকের ম্যানুয়াল নির্বাচন।
• পর্যালোচনা — ক্রমে পরীক্ষা: আর্কিটেকচার → যুক্তি → পরীক্ষা → নিরাপত্তা → শৈলী।
• সংশোধন — লেখক সমস্ত মন্তব্যের জবাব দেন, ব্লকিং সমস্যা ঠিক করেন, পুনরায় পর্যালোচনার অনুরোধ করেন।
• মার্জ — অনুমোদন এবং সবুজ CI-এর পরে, লেখক বা বট মার্জ করে।

সাধারণ কোড রিভিউ ভুল

প্রথম ভুল — ভাসা ভাসা পর্যালোচনা। পর্যালোচক যুক্তিতে গভীরভাবে না গিয়ে দ্রুত ডিফ স্ক্যান করে এবং Approve ক্লিক করেন। কারণ: বড় PR, সময়সীমা, ক্লান্তি। পরিণতি: বাগ প্রোডাকশনে পৌঁছে। সমাধান: যদি মানসম্পন্ন পর্যালোচনার সময় না থাকে — আনুষ্ঠানিক অনুমোদনের পরিবর্তে সৎভাবে লিখুন “আমি আজ পর্যালোচনা করতে পারছি না, এটি আগামীকালের জন্য স্থানান্তর করুন”।

দ্বিতীয় ভুল — অত্যধিক সমালোচনা (নিটপিকিং)। পর্যালোচক ফরম্যাটিং শৈলী, ভেরিয়েবল নামকরণ, তুচ্ছ বিবরণ সম্পর্কে ডজন ডজন মন্তব্য রাখেন। এটি লেখককে নিরুৎসাহিত করে এবং পর্যালোচনা দীর্ঘায়িত করে। সমাধান: StyleGuide এবং লিন্টারদের স্বয়ংক্রিয়ভাবে শৈলী পরীক্ষা করা উচিত। পর্যালোচনায় মানুষ যুক্তি, আর্কিটেকচার এবং নিরাপত্তা পরীক্ষা করে।

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

• পৃষ্ঠতল পর্যালোচনা — গভীর বিশ্লেষণ ছাড়া Approve। সমাধান: সময় না থাকলে পর্যালোচনা করবেন না।
• নিটপিকিং — লিন্ট-চেক করা উচিত এমন শৈলীর সমালোচনা। সমাধান: শৈলী পরীক্ষা স্বয়ংক্রিয় করুন।
• ব্যক্তিগত পছন্দ — “আমি এটি ভিন্নভাবে লিখতাম”। সমাধান: কোড কাজ করা উচিত, পর্যালোচককে খুশি করা নয়।
• বিলম্ব — 24 ঘন্টার বেশি পর্যালোচনা। সমাধান: পর্যালোচনায় SLA, লঙ্ঘনে এসকেলেশন।
• প্রসঙ্গ উপেক্ষা — কাজ না বুঝে কোড পর্যালোচনা। সমাধান: ডিফের আগে PR বিবরণ পড়ুন।