Code Review — সারমর্ম, নিয়ম এবং দলে রিভিউ কীভাবে পরিচালনা করবেন

Code Review কী?

Code Review হল এক বা একাধিক ডেভেলপার দ্বারা সোর্স কোড পরীক্ষা করার প্রক্রিয়া, এটি প্রকল্পের মূল শাখায় একীভূত করার আগে। পর্যালোচনার উদ্দেশ্য কেবল বাগ খুঁজে বের করা নয়, বরং আর্কিটেকচার উন্নত করা, দলের মান মেনে চলা নিশ্চিত করা এবং জ্ঞান ছড়িয়ে দেওয়া। স্বয়ংক্রিয় বিশ্লেষণের (লিন্টার) বিপরীতে, কোড রিভিউ একজন মানুষ দ্বারা সম্পাদিত হয় এবং পঠনযোগ্যতা, যুক্তি এবং আর্কিটেকচারাল সিদ্ধান্তগুলি মূল্যায়ন করে।

Google Engineering Practices, 2024 অনুসারে, Code Review এর দুটি সমান গুরুত্বপূর্ণ লক্ষ্য রয়েছে: ত্রুটি থেকে কোডবেস রক্ষা করা এবং প্রতিক্রিয়ার মাধ্যমে ডেভেলপারদের শেখানো। মোবাইল প্রকল্পে, পর্যালোচনায় ফ্রেমওয়ার্ক (UIKit, SwiftUI, Jetpack Compose), মেমরি ব্যবস্থাপনা এবং নেটওয়ার্ক অনুরোধ পরিচালনা পরীক্ষা অন্তর্ভুক্ত থাকতে হবে।

Code Review GitLab এবং GitHub এ যথাক্রমে Merge Request এবং Pull Request এর মাধ্যমে সংগঠিত হয়। প্রতিটি MR/PR এ একটি diff, লাইন মন্তব্য, আলোচনা এবং পরীক্ষার অবস্থা থাকে। Microsoft Research (2023) অনুসারে, নিয়মিত রিভিউ অনুশীলনকারী দলগুলি প্রোডাকশনে 40% কম গুরুতর বাগ প্রকাশ করে।

Code Review এর ইতিহাস: আনুষ্ঠানিক পরিদর্শন থেকে অ্যাসিনক্রোনাস PR পর্যন্ত

প্রথম আনুষ্ঠানিক Code Review 1970-এর দশকে IBM-এ ধাপে ধাপে চেকলিস্ট এবং প্রোটোকল সহ "গঠনমূলক পরিদর্শন" হিসেবে আবির্ভূত হয়। 2000-এর দশকে, Git এবং বিতরণকৃত দলের প্রসারের সাথে, পর্যালোচনা Pull Request এর মাধ্যমে অ্যাসিনক্রোনাস ফর্ম্যাটে বিবর্তিত হয়। GitHub (2008) PR কে একটি মূলধারার অনুশীলনে পরিণত করে। আধুনিক Code Review একটি অনানুষ্ঠানিক, অ্যাসিনক্রোনাস প্রক্রিয়া যা আমলাতন্ত্রের পরিবর্তে গতি এবং শেখার উপর দৃষ্টি নিবদ্ধ করে।

Code Review এর ধরন: আনুষ্ঠানিক এবং অনানুষ্ঠানিক পদ্ধতি

Code Review প্রক্রিয়া এবং অংশগ্রহণের ভিত্তিতে চারটি প্রধান প্রকারে শ্রেণিবদ্ধ করা হয়। আনুষ্ঠানিক (অ্যাসিনক্রোনাস রিভিউ) — সিনক্রোনাস যোগাযোগ ছাড়াই MR/PR এর মাধ্যমে পরীক্ষা, বিতরণকৃত দলে সবচেয়ে সাধারণ। অনানুষ্ঠানিক — দ্রুত CR, যখন একজন ডেভেলপার আরেকজনের কাছে যায় এবং 5 মিনিটের জন্য কোড দেখতে বলে।

Microsoft Research, 2023 অনুসারে, পেয়ার প্রোগ্রামিং (Pair Programming) মানে দুজন ডেভেলপার একটি স্ক্রিনে কাজ করে, কোডের প্রতিটি লাইন রিয়েল টাইমে "উড়ন্ত" পর্যালোচনার সাথে লেখা হয়। ওভার-দ্য-শোল্ডার — একজন ডেভেলপার অন্যের স্ক্রিন দেখে এবং আনুষ্ঠানিক প্রক্রিয়া ছাড়াই কোড নিয়ে মন্তব্য করে। ওয়াকথ্রু — কোড লেখক ডেভেলপারদের একটি গ্রুপকে পরিবর্তনের মধ্য দিয়ে নিয়ে যায়, প্রতিটি সিদ্ধান্ত ব্যাখ্যা করে।

Code Review চেকলিস্ট: কোডে কী পরীক্ষা করবেন

Code Review চেকলিস্ট পর্যালোচককে গুরুত্বপূর্ণ দিকগুলি উপেক্ষা না করতে সাহায্য করে। প্রথম বিভাগ — সঠিকতা এবং আর্কিটেকচার: সমাধান কি কাজের সাথে মেলে, অপ্রয়োজনীয় জটিলতা আছে কি, প্যাটার্নগুলি কি সঠিকভাবে বেছে নেওয়া হয়েছে (MVP, MVVM, Clean Architecture)। দ্বিতীয় বিভাগ — শৈলী এবং বিন্যাস: কোড কি দলের কোড শৈলী (Kotlin Code Style, Swift Style Guide) অনুসরণ করে।

Thoughtbot Code Review Guide, 2024 অনুসারে, তৃতীয় ব্লক — পরীক্ষা: ইউনিট টেস্ট লেখা হয়েছে কি, তারা সীমান্তবর্তী ক্ষেত্রগুলি কভার করে কি, বিদ্যমান পরীক্ষাগুলি পাস করে কি। চতুর্থ — নিরাপত্তা: কোন হার্ডকোডেড টোকেন, API কী, SQL ইনজেকশন, মেমরি লিক নেই তো? পঞ্চম — কর্মক্ষমতা: coroutines/RxJava সঠিকভাবে ব্যবহার করা হয়েছে কি, UI থ্রেড ব্লক নেই তো, অতিরিক্ত বরাদ্দ নেই তো?

• যুক্তি — অ্যালগরিদমের সঠিকতা, সীমান্তবর্তী ক্ষেত্র এবং ত্রুটি পরিচালনা
• আর্কিটেকচার — Clean Architecture, MVVM মেনে চলা, দায়িত্ব পৃথকীকরণ
• কোড শৈলী — নামকরণ, বিন্যাস, প্রকল্পের সাথে সামঞ্জস্য
• পরীক্ষা — ইউনিট টেস্টের উপস্থিতি, তাদের সম্পূর্ণতা এবং সবুজ অবস্থা

Code Review কীভাবে করবেন: পর্যালোচকের জন্য নিয়ম

Code Review এর জন্য পর্যালোচককে পুঙ্খানুপুঙ্খতা এবং গতির মধ্যে ভারসাম্য রাখতে হয়। প্রধান নিয়ম হল ছোট ব্যাচে কোড পর্যালোচনা করা। সর্বোত্তম পরিমাণ — একটি সেশনে 200–400 লাইন পরিবর্তন। Google Research (2022) অনুসারে, 500 লাইনের বেশি পর্যালোচনা কার্যকারিতা হারায়: মিস করা ত্রুটির সংখ্যা পরিবর্তনের পরিমাণের সাথে রৈখিকভাবে বৃদ্ধি পায়। দ্বিতীয় নিয়ম — আর্কিটেকচার দিয়ে শুরু করুন, তারপর যুক্তি, তারপর বিবরণ।

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

Code Review কীভাবে গ্রহণ করবেন: লেখকের জন্য টিপস

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

LeadDev, 2024 অনুসারে, পর্যালোচনার জন্য পাঠানোর আগে, লেখকের নিজের কোড পরীক্ষা করা উচিত: পরীক্ষা চালান, চেকলিস্ট দেখুন, নিশ্চিত করুন যে কোন ডিবাগ লগ বা মন্তব্য করা কোড নেই। MR/PR এ পরিবর্তনের প্রসঙ্গ সহ একটি স্পষ্ট বিবরণ থাকা উচিত। বিবরণ যত ভাল, পর্যালোচনা তত দ্রুত এবং উত্পাদনশীল হবে।

Code Review এ মনস্তাত্ত্বিক নিরাপত্তা

Code Review এর একটি মূল দিক হল দলে মনস্তাত্ত্বিক নিরাপত্তা। যদি একজন ডেভেলপার কঠোর সমালোচনা বা উপহাসের ভয় পায়, তবে সে সমস্যাগুলি আলোচনা করার পরিবর্তে লুকিয়ে রাখবে। Google Project Aristotle (2017) দেখিয়েছে: উচ্চ মনস্তাত্ত্বিক নিরাপত্তা সম্পন্ন দলগুলি 25% বেশি উত্পাদনশীল। নিয়ম: কোডের সমালোচনা করুন, লেখকের নয়; অভিযোগের পরিবর্তে প্রশ্ন জিজ্ঞাসা করুন; ভাল সমাধানের জন্য ধন্যবাদ জানান।

মূল নিয়ম লেখকের জন্য — মন্তব্য বন্ধ করতে তাড়াহুড়ো করবেন না। যদি পর্যালোচক পরিবর্তনের অনুরোধ করে থাকে, সেগুলি করতে হবে, কেবল "ঠিক আছে" বলে না করে ঠিক না করেই ছেড়ে দেওয়া নয়। সংশোধন করার পরে — আবার পর্যালোচনার অনুরোধ করুন। GitLab এবং GitHub পর্যালোচককে জানানোর জন্য Re-request Review সমর্থন করে।

Code Review স্বয়ংক্রিয়করণ: লিন্টার এবং স্ট্যাটিক বিশ্লেষণ

Code Review স্বয়ংক্রিয়করণ আনুষ্ঠানিক নিয়ম পরীক্ষা দূর করে ডেভেলপারদের বোঝা কমায়। লিন্টার (ktlint, SwiftLint, ESLint) কোড শৈলী, বিন্যাস এবং মৌলিক ত্রুটি পরীক্ষা করে। স্ট্যাটিক বিশ্লেষক (Detekt, SonarQube, Infer) কোড মানুষের পর্যালোচনায় পৌঁছানোর আগে সম্ভাব্য বাগ, মেমরি লিক এবং নিরাপত্তা সমস্যা খুঁজে পায়।

detekt Documentation, 2024 অনুসারে, CI/CD পাইপলাইনে, MR/PR তৈরি করার সময় লিন্টার এবং বিশ্লেষক স্বয়ংক্রিয়ভাবে চলে। যদি পরীক্ষা ব্যর্থ হয় — MR মার্জ বাটন দ্বারা অবরুদ্ধ হয়। এটি নিশ্চিত করে যে মানুষের পর্যালোচনায় পৌঁছানো কোড ইতিমধ্যে মৌলিক পরীক্ষা পাস করেছে। পর্যালোচক আর্কিটেকচার, যুক্তি এবং পঠনযোগ্যতার উপর ফোকাস করে, স্পেস এবং ইন্ডেন্টেশনের উপর নয়।

// Android প্রকল্পের জন্য detekt কনফিগারেশনের উদাহরণ
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

মোবাইল প্রকল্পের জন্য Code Review টুল

Code Review টুল মোবাইল ডেভেলপমেন্টে প্ল্যাটফর্ম-ভিত্তিক (GitLab, GitHub, Bitbucket) এবং বিশেষায়িত (Gerrit, Reviewable, Crucible) এ বিভক্ত। GitLab এবং GitHub অন্তর্নির্মিত কার্যকারিতা প্রদান করে: diff তুলনা, লাইন মন্তব্য, থ্রেড, অনুমোদন/পরিবর্তন অনুরোধ অবস্থা, CI/CD একীকরণ। টুলের পছন্দ দলের আকার এবং পর্যালোচনা নীতির উপর নির্ভর করে।

GitLab Docs, 2025 অনুসারে, বড় দলের (50+ ডেভেলপার) জন্য, Gerrit কঠোর নিয়ন্ত্রণ প্রদান করে: মার্জের আগে বাধ্যতামূলক CI যাচাইকরণ, ওজনযুক্ত অনুমোদন (Verified + Code-Review) এবং বিস্তারিত অ্যাক্সেস অধিকার। ছোট এবং মাঝারি দলের জন্য, GitLab এবং GitHub সর্বোত্তম পছন্দ: Required Approvals, Code Owners এবং Merge Checks কনফিগার করতে মিনিট সময় লাগে।

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, অন্তর্নির্মিত CI/CD
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Mercurial/Git এর জন্য Pull Requests, Diff মন্তব্য সহ Approvals
• Gerrit — কঠোর যাচাইকরণ প্রক্রিয়া, ওজনযুক্ত মূল্যায়ন, Jenkins একীকরণ

Code Review এ সাধারণ ভুল

Code Review এ ভুল এর কার্যকারিতা হ্রাস করে এবং দলকে নিরুৎসাহিত করে। প্রথম — একসাথে খুব বড় পরিমাণ পরিবর্তন পর্যালোচনা করা। যখন MR এ 2000+ লাইন থাকে, পর্যালোচক 70% পর্যন্ত ত্রুটি মিস করে। দ্বিতীয় — কোড শৈলী বা আর্কিটেকচারের উপর ভিত্তি করে না এমন বিষয়ভিত্তিক মন্তব্য। "আমি এটি ভিন্নভাবে লিখতাম" এর মতো মন্তব্য ন্যায্যতা ছাড়া কোন মূল্য দেয় না।

Google Engineering Practices, 2024 অনুসারে, তৃতীয় ভুল — পরীক্ষা উপেক্ষা করা। যদি MR নতুন কার্যকারিতার জন্য পরীক্ষা অন্তর্ভুক্ত না করে — পর্যালোচকের সেগুলি অনুরোধ করা উচিত, "পরে" বলে অনুমোদন না করা। চতুর্থ — দিন বা স্প্রিন্টের শেষে পর্যালোচনা করা যখন মনোযোগ বিক্ষিপ্ত থাকে। পর্যালোচনার সেরা সময় হল দিনের প্রথমার্ধ, কাজের মধ্যে স্যুইচ না করে 30–60 মিনিট উত্সর্গ করা।

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

বিতরণকৃত দলে Code Review

দূরবর্তী দলের জন্য, Code Review জ্ঞান বিতরণের প্রাথমিক চ্যানেল। স্পষ্ট সময়সীমা সহ MR এর মাধ্যমে অ্যাসিনক্রোনাস ফর্ম্যাট সুপারিশ করা হয়: পর্যালোচনার জন্য সর্বোচ্চ 24 ঘন্টা। জটিল আর্কিটেকচারাল আলোচনার জন্য স্ক্রিন রেকর্ডিং (Loom) ব্যবহার করুন। বিতরণকৃত দলে, MR মন্তব্যে সিদ্ধান্তের লিখিত ডকুমেন্টেশন বিশেষভাবে গুরুত্বপূর্ণ যাতে সময় অঞ্চল পরিবর্তন করার সময় প্রসঙ্গ হারিয়ে না যায়।