Clean code ও code review অভ্যাস যা আপনাকে ভালো ডেভেলপার করে

চালু কোড হলো ন্যূনতম। ভালো কোড পড়া, বদলানো ও বিশ্বাস করা সহজ। ডেভেলপারের বেশিরভাগ সময় কাটে বিদ্যমান কোড পড়ে, তাই পরের পাঠকের (প্রায়ই ভবিষ্যতের আপনি) জন্য লেখা মূল দক্ষতা।

১. ভালো নাম দিন

নামই পাঠযোগ্যতার সবচেয়ে বড় অংশ।

• উদ্দেশ্য প্রকাশ করা বর্ণনামূলক নাম দিন: d বা tmp নয়, daysUntilExpiry।
• Function-এর নামে verb (calculateTotal, sendInvoice) এবং মানে noun ব্যবহার করুন।
• Boolean প্রশ্নের মতো পড়ুক: isActive, hasPermission।
• বিভ্রান্তিকর বা অস্পষ্ট নাম (data, info, manager, handleStuff) এড়ান।
• সামঞ্জস্য রাখুন: একই ধারণায় fetch, get ও retrieve মেশাবেন না।
• ছোট scope-এ ছোট নাম ঠিক (loop-এ i)। বড় scope-এ স্পষ্ট নাম লাগে।

২. Function ছোট ও কেন্দ্রীভূত রাখুন

Function এক স্তরের বিস্তারে একটি কাজ করবে।

• বর্ণনায় "এবং" লাগলে ভাগ করুন।
• কম parameter রাখুন। অনেক parameter গুচ্ছ করে object বানানো বা function ভাগের ইঙ্গিত।
• গভীর nesting-এর বদলে early return পছন্দ করুন।
• লুকানো পার্শ্বপ্রতিক্রিয়া এড়ান। getUser নামের function data বদলাবে না।

// পড়তে কঠিন
function process(o) {
  if (o) {
    if (o.items.length > 0) {
      if (o.paid) { ship(o); }
    }
  }
}

// স্পষ্ট
function shipIfReady(order) {
  if (!order || order.items.length === 0 || !order.paid) return;
  ship(order);
}

৩. মন্তব্য কেন বলে, কী নয়

• ভালো কোড কী তা নাম ও কাঠামো দিয়েই বলে।
• মন্তব্য ব্যবহার করুন কেন-র জন্য: business নিয়ম, workaround, bug বা standard-এর লিংক।
• Comment-out করা কোড মুছুন। Version control মনে রাখে।
• পুরোনো মন্তব্য না থাকার চেয়ে খারাপ, তাই কোডের সাথে হালনাগাদ করুন।

৪. পুনরাবৃত্তি এড়ান, তবে অতিরিক্ত abstract করবেন না

• DRY (don't repeat yourself): পুনরাবৃত্ত যুক্তি এক জায়গায় থাকুক।
• কিন্তু আগে থেকে abstract করবেন না। একই ধারণা তিনবার দেখে কী সত্যিই বদলায় বুঝে নিন। ভুল abstraction সামান্য পুনরাবৃত্তির চেয়ে খারাপ।
• মৃত কোড ও অব্যবহৃত variable সরান।

৫. ইচ্ছে করে error সামলান

• ফাঁকা catch দিয়ে নীরবে error গিলবেন না।
• ইনপুট অবৈধ হলে পরিষ্কার বার্তায় আগেভাগে ব্যর্থ হোন।
• Error-এ প্রসঙ্গ (কোন ID, কোন কাজ) যোগ করুন এবং সঠিক জায়গায় একবার log করুন।
• সাধারণ নিয়ন্ত্রণ প্রবাহে exception ব্যবহার করবেন না।
• শেষ ব্যবহারকারীকে কখনো ভেতরের error বিস্তারিত দেখাবেন না।

৬. Data ও state সরল রাখুন

• সম্ভব হলে immutable মান পছন্দ করুন।
• Global variable ও ভাগ করা mutable state সীমিত করুন।
• Magic number ও string নামযুক্ত constant দিয়ে বদলান।
• সম্পর্কিত data একসাথে রাখুন; স্পষ্ট type ব্যবহার করুন।

৭. Test লিখুন

• Test আচরণ নথিভুক্ত করে এবং refactor করার আত্মবিশ্বাস দেয়।
• ভেতরের বিস্তারিত নয়, আচরণ (ইনপুট ও আউটপুট) test করুন।
• Test ছোট, দ্রুত ও স্বাধীন রাখুন।
• Bug ঠিক করার সাথে এমন test থাকুক যা ঠিক করার আগে ব্যর্থ হয়।

৮. ছোট নিরাপদ ধাপে refactor করুন

Refactoring আচরণ না বদলে কাঠামো বদলায়।

• আগে test রাখুন।
• একবারে একটি ছোট বদল করুন ও test চালান।
• Boy-scout নিয়ম মানুন: কোড যেমন পেয়েছেন তার চেয়ে একটু পরিষ্কার রেখে যান।
• পর্যালোচনা পরিষ্কার রাখতে refactoring commit ফিচার বদল থেকে আলাদা রাখুন।

Code review: মতামত দেওয়া

পর্যালোচনা কোড উন্নত ও জ্ঞান ভাগ করার জন্য, মানুষকে বিচার করার জন্য নয়।

• আগে বিবরণ পড়ে লক্ষ্য বুঝুন।
• সঠিকতা ও প্রান্তিক ক্ষেত্র, নিরাপত্তা, পাঠযোগ্যতা, test এবং গরম পথে performance দেখুন।
• নির্দিষ্ট ও সদয় হোন: কেন ব্যাখ্যা করুন, বিকল্প প্রস্তাব করুন, প্রশ্ন করুন ("list ফাঁকা হলে কী হবে?")।
• অবশ্য-ঠিক বিষয় আর পরামর্শ বা ধরন পছন্দ আলাদা করুন ("nit:" প্রিফিক্স)।
• Formatting ও lint নিয়ম টুলকে সামলাতে দিন যাতে মানুষ যুক্তিতে মন দেয়।
• ভালো সমাধানের প্রশংসা করুন।
• ছোট বদল পর্যালোচনা করুন। বড় diff-এ অগভীর পর্যালোচনা হয়।

Code review: মতামত নেওয়া

• ব্যক্তিগতভাবে নেবেন না। পর্যালোচনা কোড নিয়ে।
• মন্তব্য না বুঝলে ব্যাখ্যা চান।
• নিজের যুক্তি ব্যাখ্যা করুন এবং মত বদলাতে রাজি থাকুন।
• পর্যালোচকদের ধন্যবাদ দিন। প্রতিটি মন্তব্য ঠিক বা আলোচনা করুন।
• Pull request ছোট, কেন্দ্রীভূত ও ভালোভাবে বর্ণিত রাখুন: কী, কেন, কীভাবে test করবেন।

নিজের কোডের জন্য পর্যালোচনার আগের checklist

• প্রান্তিক ক্ষেত্রসহ কাজ যা চেয়েছে তা কি করে?
• নাম কি স্পষ্ট, এবং সরানোর মতো মৃত কোড বা debug আউটপুট আছে কি?
• Test আছে কি, পাস করে কি?
• নিরাপত্তা দেখেছি কি: ইনপুট যাচাই, অনুমতি, secret?
• নতুন কেউ কি কয়েক মিনিটে এটি বুঝতে পারবে?

মূল কথা: পাঠকের জন্য লিখুন: পরিষ্কার নাম, ছোট function, "কেন"-র জন্য মন্তব্য, সামলানো error ও test। পর্যালোচনায় নির্দিষ্ট ও সদয় হোন, বদল ছোট রাখুন এবং ধরন টুলকে যাচাই করতে দিন।

---

প্রোগ্রামিং রোডম্যাপ সিরিজ, পর্ব ২ (ভাষা ও নকশা): 4 নম্বর (মোট 5)। আগের লেখা: REST API নকশার ভালো চর্চা: URL, status code ও error.