পাঠ ৫২ · ৫৮-এর মধ্যে · মডিউল ১১
Home / Courses / Software Engineering Principles & Git / কোড কোয়ালিটি ও রিফ্যাক্টরিং

কোড রিভিউ বেস্ট প্র্যাক্টিস

Code review best practices
৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • কোড রিভিউ ঠিক কী, এবং এটি কেন সত্যিকারের বাস্তব সুবিধা দেয় — শুধু একটি আনুষ্ঠানিকতা নয়
  • bus factor — একটি গুরুত্বপূর্ণ, বাস্তব টিম-ঝুঁকি ধারণা
  • ভালো রিভিউয়ের নির্দিষ্ট, বাস্তব প্র্যাক্টিস — ছোট PR, substance বনাম style, গঠনমূলক ফিডব্যাক
  • একটি রিভিউ-কোয়ালিটি রিপোর্ট বানানো, যা প্রকৃতপক্ষে গণনা করে একটি রিভিউ অতিরিক্ত style-কেন্দ্রিক কিনা

১ · কোড রিভিউ কী ও কেন গুরুত্বপূর্ণ

কোড রিভিউCode Reviewপ্রস্তাবিত কোড পরিবর্তন শেয়ার্ড কোডবেসে মার্জ হওয়ার আগে অন্য একজন ডেভেলপার তা পরীক্ষা করার প্র্যাক্টিস। হলো M9/L40-এ শেখা পুল রিকোয়েস্ট ওয়ার্কফ্লোর রিভিউ ধাপের প্রত্যক্ষ, বিস্তারিত রূপ — একজন ডেভেলপার একটি ফিচার/ফিক্স শেষ করে PR খোলার পর, অন্তত একজন সহকর্মী সেই পরিবর্তন মনোযোগ দিয়ে পড়ে মতামত দেয়, প্রশ্ন করে, বা পরিবর্তন চায় — তারপরই সেটি মার্জ হয়।

রিভিউয়ের তিনটি বাস্তব, প্রমাণিত সুবিধা:

বাগ/ডিজাইন সমস্যা আগেই ধরা পড়ে
নিজের লেখা কোডে নিজে অন্ধ হয়ে যাওয়া স্বাভাবিক — একজন দ্বিতীয় ব্যক্তির চোখ প্রায়ই এমন সমস্যা ধরে যা মূল লেখক খেয়াল করেননি।
নলেজ শেয়ারিং
রিভিউয়ার নিজে না লেখা কোডবেসের অংশ সম্পর্কে জানতে পারে — এটি bus factorBus Factorকোনো গুরুত্বপূর্ণ অংশ বোঝা একজন ব্যক্তির উপর নির্ভরশীল থাকলে, সেই ব্যক্তি হঠাৎ অনুপলব্ধ হলে প্রজেক্ট আটকে যাওয়ার ঝুঁকি — যত কম মানুষ কোনো অংশ বোঝে, bus factor তত কম (ঝুঁকিপূর্ণ)। ঝুঁকি কমায়।
কনসিস্টেন্সি বজায় রাখা
রিভিউ হলো সেই জায়গা যেখানে টিম যৌথভাবে M4-M5-এর প্রিন্সিপল ও প্যাটার্ন বাস্তবে বজায় রাখে।

২ · রিভিউয়ের সেরা প্র্যাক্টিস

কয়েকটি বাস্তব, ব্যবহারিক নিয়ম ভালো কোড রিভিউ প্র্যাক্টিসকে সংজ্ঞায়িত করে। PR ছোট ও ফোকাসড রাখা — একটি বড় PR ভালোভাবে রিভিউ করা কঠিন (M9/L42-এর ট্রাংক-বেসড ডেভেলপমেন্টের ঘন-ঘন-ছোট-কমিট দর্শনের সাথে সরাসরি সম্পর্কিত)। substance-এ ফোকাস করা — সঠিকতা, ডিজাইন সিদ্ধান্ত, টেস্ট কভারেজ (M10-এর পুরো বিষয়বস্তু) এইসব বিষয় সত্যিকারের গুরুত্বপূর্ণ; শুধু style নিটপিক করা নয় — অনেক টিম style-চেক automated linter দিয়ে অটোমেট করে, যাতে মানুষ রিভিউয়ার সেই সময় substance-এ ব্যয় করতে পারে। নির্দিষ্ট, কার্যকরী ফিডব্যাক দেওয়া — অস্পষ্ট সমালোচনার বদলে ঠিক কী বদলাতে হবে তা বলা, এবং সবসময় গঠনমূলক ভঙ্গিতে কমেন্ট লেখা (M13/L57-এর টিম-কোলাবোরেশন থিমের প্রত্যক্ষ ভূমিকা)।

সূত্র · Formula

একটি রিভিউয়ের কমেন্ট কতটা style-কেন্দ্রিক তা মাপার সরল সূত্র (L46-এর কভারেজ-শতাংশ সূত্রের একই আঙ্গিকে): $$style\% = \frac{\text{style কমেন্ট সংখ্যা}}{\text{মোট কমেন্ট সংখ্যা}} \times 100$$ যদি এই শতাংশ অত্যধিক বেশি (যেমন ৮০%-এর উপরে) হয়, তার মানে রিভিউয়ার substance-এর বদলে style-এ বেশি সময় দিচ্ছেন — যা linter দিয়ে অটোমেট করা যেত।

৩ · একটি রিভিউ-কোয়ালিটি রিপোর্ট বানানো

নিচের কোড সেলে CodeReviewComment ও PullRequestReview ক্লাস দিয়ে একটি সত্যিকারের, সম্পূর্ণ কার্যকরী review_quality_report() ফাংশন লেখা হয়েছে — এটি প্রকৃতপক্ষে গণনা করে একটি রিভিউ substance-heavy না style-heavy, উপরের সূত্র ব্যবহার করে (হার্ডকোড করা কোনো ফলাফল নয়)।

Python
class CodeReviewComment:
    def __init__(self, line_number, category, text):
        self.line_number = line_number
        self.category = category  # "substance" অথবা "style"
        self.text = text

class PullRequestReview:
    def __init__(self):
        self.comments = []

    def add_comment(self, comment):
        self.comments.append(comment)

def review_quality_report(comments):
    total = len(comments)
    style_count = sum(1 for c in comments if c.category == "style")
    substance_count = total - style_count
    style_pct = (style_count / total) * 100 if total else 0
    flagged = style_pct > 80
    print(f"  মোট কমেন্ট: {total} | substance: {substance_count} | style: {style_count} ({style_pct:.1f}%)")
    if flagged:
        print("  ⚠ এই রিভিউ অতিরিক্তভাবে style-কেন্দ্রিক (৮০%+) -- এই ধরনের চেক automated linter দিয়ে")
        print("    করানো যেত, রিভিউয়ারের সময় substance-এ ব্যয় হওয়া উচিত ছিল।")
    else:
        print("  ✓ রিভিউটি যথেষ্ট substance-কেন্দ্রিক।")
    return {"total": total, "style_pct": style_pct, "flagged": flagged}

# উদাহরণ A -- substance-heavy রিভিউ
review_a = PullRequestReview()
for c in [
    CodeReviewComment(42, "substance", "এই ফাংশনটি নেগেটিভ quantity হ্যান্ডেল করছে না -- edge case মিস হচ্ছে।"),
    CodeReviewComment(58, "substance", "এই লজিক OrderService-এর দায়িত্ব, এখানে থাকা উচিত না (SRP লঙ্ঘন)।"),
    CodeReviewComment(70, "substance", "এই পাথের জন্য কোনো ইউনিট টেস্ট নেই।"),
    CodeReviewComment(12, "substance", "ম্যাজিক নাম্বার 86400 ব্যবহার হয়েছে, নামকরণ করা কনস্ট্যান্ট ভালো হতো।"),
    CodeReviewComment(5, "style", "এখানে একটা এক্সট্রা ব্ল্যাংক লাইন আছে।"),
]:
    review_a.add_comment(c)

print("রিভিউ A:")
report_a = review_quality_report(review_a.comments)

print()
print("রিভিউ B:")
review_b = PullRequestReview()
for c in [
    CodeReviewComment(3, "style", "ভেরিয়েবল নাম camelCase না snake_case হওয়া উচিত।"),
    CodeReviewComment(9, "style", "ইনডেন্টেশন ২ স্পেস, ৪ স্পেস হওয়া উচিত।"),
    CodeReviewComment(15, "style", "কোটেশন মার্ক ডাবল না সিঙ্গেল হওয়া উচিত।"),
    CodeReviewComment(20, "style", "লাইনের শেষে ট্রেইলিং স্পেস আছে।"),
    CodeReviewComment(1, "style", "ইম্পোর্ট অর্ডার ঠিক নেই।"),
    CodeReviewComment(30, "substance", "এখানে নাল-চেক মিসিং, crash হতে পারে।"),
]:
    review_b.add_comment(c)

report_b = review_quality_report(review_b.comments)

    
হাতে-যাচাই: রিভিউ A-তে ৫টি কমেন্টের ১টি style — 1/5 × 100 = ২০%, ৮০%-এর নিচে, তাই ফ্ল্যাগ হয় না। রিভিউ B-তে ৬টি কমেন্টের ৫টি style — 5/6 × 100 ≈ ৮৩.৩%, ৮০%-এর উপরে, তাই সঠিকভাবে ফ্ল্যাগ হয়। ফাংশনটি সত্যিই সূত্র অনুযায়ী গণনা করছে, কোনো ফলাফল হার্ডকোড করা নেই।
মূল কথা · Key takeaway

কোড রিভিউ শুধু একটি চেকবক্স নয় — সঠিকভাবে করা হলে এটি বাগ ধরে, নলেজ ছড়িয়ে দেয় (bus factor কমায়), এবং টিমের কোয়ালিটি স্ট্যান্ডার্ড বজায় রাখে। রিভিউয়ারের মনোযোগ substance-এ রাখা এবং ফিডব্যাক নির্দিষ্ট ও গঠনমূলক রাখা — এই দুটোই সময়ের সাথে টিমের রিভিউ কালচারকে সত্যিকারের কার্যকর রাখে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি ৫০০-লাইনের বিশাল PR বনাম পাঁচটি ১০০-লাইনের ছোট PR — কোনটা রিভিউ করা সহজ, এবং কেন?

পাঁচটি ছোট PR সাধারণত অনেক সহজ। একটি ৫০০-লাইনের PR-এ রিভিউয়ারের মনোযোগ ছড়িয়ে যায় — সূক্ষ্ম বাগ বা ডিজাইন সমস্যা সহজেই চোখ এড়িয়ে যায়, আর রিভিউটি প্রায়ই ভাসাভাসা হয়ে যায়। ছোট, ফোকাসড PR প্রতিটি পরিবর্তন গভীরভাবে বোঝা সহজ করে — M9/L42-এর ট্রাংক-বেসড ডেভেলপমেন্টের ঘন-ঘন-ছোট-ইন্টিগ্রেশন দর্শনের সাথে এই যুক্তি সরাসরি সম্পর্কিত।

প্র ০২ একটি টিমে যদি শুধু একজন ডেভেলপার পুরো পেমেন্ট সিস্টেম বোঝেন, এর bus factor কত, এবং এটি কেন ঝুঁকিপূর্ণ?

bus factor ১ — শুধু একজন মানুষ সেই অংশ বোঝেন। সেই ব্যক্তি হঠাৎ অসুস্থ হলে, ছুটিতে গেলে, বা টিম ছেড়ে দিলে, পেমেন্ট সিস্টেম-সংক্রান্ত যেকোনো বাগ ফিক্স বা ফিচার কাজ কার্যত থমকে যায়। কোড রিভিউ এই ঝুঁকি সরাসরি কমায় — প্রতিটি রিভিউয়ে অন্তত একজন দ্বিতীয় মানুষ সেই কোড দেখেন ও বোঝেন, ফলে ধীরে ধীরে bus factor বাড়ে।

প্র ০৩ একটি লিন্টার (automated tool) কেন style-সংক্রান্ত সমস্যা মানুষের চেয়ে ভালোভাবে ধরতে পারে, আর মানুষ রিভিউয়ারের আসল মূল্য তাহলে কোথায়?

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

অনুশীলন

  1. চিন্তা করুন: রিভিউ A-তে (৪টি substance, ১টি style) আরও ৩টি নতুন style কমেন্ট যোগ করা হলে মোট style% কত হবে, এবং এটি ৮০%-এর সীমা পার করবে কিনা হাতে-কলমে হিসাব করুন।

    নতুন মোট কমেন্ট = ৫ + ৩ = ৮টি, style কমেন্ট = ১ + ৩ = ৪টি। style% = 4/8 × 100 = ৫০% — এটি এখনও ৮০%-এর নিচে, তাই এখনও ফ্ল্যাগ হবে না। ৮০% পার করতে হলে অন্তত এমন সংখ্যক style কমেন্ট দরকার যেখানে style/total > 0.8 — যেমন মোট ৮টির মধ্যে ৭টি style হলে 7/8 = ৮৭.৫%, তখনই ফ্ল্যাগ হবে।

  2. পরীক্ষা করুন: উপরের কোড সেলে review_quality_report-এর ফ্ল্যাগিং সীমা 80-এর বদলে 50 করে Run চেপে দেখুন রিভিউ A-এর ফলাফল বদলায় কিনা।

    রিভিউ A-এর style% = ২০%, যা ৫০%-এর সীমার নিচেও থাকে, তাই এখনও ফ্ল্যাগ হবে না। তবে রিভিউ B-এর style% ≈ ৮৩.৩%, যা ৮০%-এর মতো ৫০%-এর সীমাতেও ফ্ল্যাগ হতেই থাকবে। সীমা কমালে টিম আরও কড়াকড়িভাবে "খুব বেশি style-heavy" রিভিউ শনাক্ত করবে — কিন্তু খুব কম সীমা দিলে স্বাভাবিক, যুক্তিসঙ্গত রিভিউও ভুলভাবে ফ্ল্যাগ হতে পারে।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
টেকনিক্যাল ডেট