কোড পর্যালোচনা কার করা উচিত?

Question

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

তবে বর্তমান সিস্টেমের সাথে দুটি সমস্যা রয়েছে:

1. স্থপতি বাধা হয়ে যায়

2. বিকাশকারীরা কোডের মান এবং আর্কিটেকচারের (যা সব ধরণের সমস্যার দিকে পরিচালিত করে) দায়ভার গ্রহণ করে না।

কীভাবে আমরা এই সমস্যাগুলি সমাধান করতে পারি? কোডটি পর্যালোচনা করে কে আমাদের পরিবর্তন করা উচিত?

Comments

সম্ভাব্য সদৃশ এর নকলটি কি আপনার সেরা প্রোগ্রামারদের অন্যের কোডটি সোর্স নিয়ন্ত্রণে পরীক্ষা করতে হবে?

— জিনাত

আমি এটি সদৃশ হিসাবে দেখছি না। প্রশ্নগুলি সম্পর্কিত, তবে সম্ভাব্য সদৃশটি সামান্য ভিন্ন ইস্যুতে ফোকাস করে।

— বার্ট ভ্যান ইনজেন শেহানাউ

আপনি 'কোড পর্যালোচনার গুণমান' বলতে কী বোঝাতে চেয়েছেন আপনি তার প্রসারিত করতে পারেন? আপনি কি কোডটির গুণমান যা পর্যালোচনা শেষে উত্থিত হয়? আমার কাছে মনে হচ্ছে আপনার কাছে কেবলমাত্র একজন বিকাশকারী গ্রহণযোগ্য মানের কোড তৈরি করতে পারে,

— এক্ষেত্রে

Answer 1

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

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

Comments

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

— জেনসজি

@ জেনসজি: তবে এটি ওপি-র পরিস্থিতি পর্যালোচনা করছে না a

— jmoreno

এ কারণেই আমি এটিকে সাহসী করে তুলেছি।

— JensG

Answer 2

এই পরিস্থিতিতে আপনার যা প্রয়োজন তা এই অভিজ্ঞ বিকাশকারীদের জ্ঞানের জন্য যাতে দলের বাকি সদস্যদের বাড়াতে সহায়তা করা হয়। একটি দলের গুণমান সেরা বিকাশকারীদের দক্ষতা দ্বারা সংজ্ঞায়িত হয় না; এটি সবচেয়ে খারাপ দক্ষতা দ্বারা সংজ্ঞায়িত করা হয়। আপনি এই জাতীয় জিনিস চেষ্টা করতে পারেন:

• সহযোগী পর্যালোচনা। এটি আমার শেষ দলে সত্যই দুর্দান্ত কাজ করেছে। আমরা পুরো টিমটিকে একটি প্রজেক্টর সহ একটি ঘরে রেখেছিলাম এবং কিছু আইটেম পর্যালোচনা শুরু করি। সম্ভবত শুরুতে আর্কিটেক্টই সেই ব্যক্তি যা পর্যালোচনাটি গাইড করে তবে কয়েক সপ্তাহের মধ্যে (আমরা প্রতি শুক্রবার এক বা দুই ঘন্টা সংরক্ষণ করেছি) পুরো দলটি মূল ধারণাটি নিয়ে কথা বলতে ও বুঝতে শুরু করে যা বর্তমানে কেবল স্থপতি জানেন বলে মনে হয়।

• জোড় প্রোগ্রামিং। আমার জন্য এটি একটি দলে জ্ঞান ছড়িয়ে দেওয়ার সেরা হাতিয়ার।

Comments

জোড়া প্রোগ্রামিংয়ের জন্য +1 আসলে, এই প্রশ্নটি সম্পর্কে আমার প্রথমটি ছিল "সবাই", তবে জোড় প্রোগ্রামিংটি এটি আরও ভাল করে। আমি মনে করি যদি আমরা এটির গুণগত দিক ছাড়াও শিক্ষার উত্স তৈরি করি তবে আমরা এর থেকে বেশিরভাগটি অর্জন করব।

— জেনসজি

Answer 3

যদিও আমি সিস্টেম / সফ্টওয়্যার আর্কিটেক্ট সমস্ত পরিবর্তন / প্রতিশ্রুতি সাইন অফ করার বিষয়টি দেখতে পাচ্ছি, সফ্টওয়্যার বিকাশকারীদের স্থপতি ছাড়া জড়িত ছাড়াই পর্যালোচনা করতে সক্ষম হওয়া উচিত - সালিশ ব্যতীত।

আমার পছন্দসই [*] পর্যালোচনা পদ্ধতিগুলি হ'ল:

• প্রয়োজন / ইস্যু দ্বারা গ্রুপ পরিবর্তন।
• সমস্ত বিকাশকারী, সফ্টওয়্যার আর্কিটেক্ট এবং প্রয়োজনীয়তা / ইস্যুটির লেখককে পর্যালোচনা করার জন্য আমন্ত্রণ জানান। (তাদের সবারই একটি পর্যালোচনা করার প্রয়োজন হয় না))
• সমাপ্ত পর্যালোচনা বিবেচনা করুন যখন:
  • দু'জন বিকাশকারী পর্যালোচনা করেছেন।
  • সমস্ত মন্তব্য সাড়া দেওয়া হয়। (সম্ভবত সফ্টওয়্যার আর্কিটেক্টের সিদ্ধান্ত নেওয়ার দ্বারা।)
  • একটি কার্যদিবস আরও আলোচনা ছাড়াই কেটে গেছে (বা সমস্ত আমন্ত্রিত দলগুলি পর্যালোচনা করেছে)।

সুতরাং আপনার প্রশ্নের আমার সংক্ষিপ্ত উত্তর হ'ল: বিকাশকারীদের পর্যালোচনা পরিবর্তন করা উচিত।

[*] দুর্ভাগ্যক্রমে আমি যে প্রকল্পগুলিতে অংশ নিই তা সবসময় এটি হয় না।

Comments

এখন সবসময়, না সবসময়?

— মার্টিজন

আপনি যেমন অনুমান করতে পারেন: "সর্বদা নয়"। এটি সন্ধানের জন্য ধন্যবাদ। আমি উত্তর সংশোধন করেছি।

— জ্যাকব স্প্যারে অ্যান্ডারসন

Answer 4

আমি মাঝেমধ্যে টিম কোড পর্যালোচনার অনুশীলন পছন্দ করি যাতে পুরো দলটি স্থপতিদের অন্তর্ভুক্ত করে তবে দলের প্রচুর এবং তিন বা তিন সদস্যের মধ্যে প্রচুর কোড রিভিউ থাকে।

যদি এটি সত্যিই কৌতুকপূর্ণ বা সংবেদনশীল কোড হয় তবে স্থপতি বা দলের সিনিয়র সদস্যদের তালিকাভুক্ত করুন।

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

Answer 5

আমি একমত, যদি কেবল একজন ব্যক্তি পর্যালোচনা করে থাকেন, তবে বাকি লোকেরা সম্ভবত "আমি জানি না, এটি কাজ করে বলে মনে হচ্ছে, তবে সেই স্মার্ট লোকটি ঠিক আছে কিনা" তা নির্ধারণ করুন " আমি নিম্নলিখিত সম্পর্কে চিন্তা করতে পারি:

• আপনার কোডটি সর্বজনীন করুন যাতে প্রত্যেকে কী কী কাজ করছে তা দেখতে পান; কোড রয়েছে এমন প্রতিটি ফাইলের শুরুতে নাম লিখুন; সম্ভবত এগুলি মুদ্রণ করুন এবং উহ, বাথরুমে বা যেখানেই আপনি মনে করেন এটি কিছুটা নজর কেড়ে দেবে stamp
• জোড় প্রোগ্রামিং; আপনার পাশে অন্য মস্তিষ্কের সাথে, আপনি আপনার ভেরিয়েবলটির নামকরণের আগে দু'বার ভাবেনi
• আপনার দারোয়ানকে তুলে ধরুন এবং সেই উত্তরাধিকার কীভাবে কাজ করে তাকে ব্যাখ্যা করুন (ওঁ, হ্যাঁ, এটি কাজ করে না)। আপনার কোড অন্য কারও কাছে ব্যাখ্যা করা সহায়তা করে। সম্ভবত এটি সংকলন করে, সম্ভবত এটি সঠিক জিনিসগুলি করে তবে আপনি কেন এটি বুঝতে পারেন নি। এখন আপনার সুযোগ
• দিকনির্দেশগুলির একটি সেট আছে এবং সবাইকে সেগুলি অনুসরণ করতে বাধ্য করুন; গাইডলাইন যাই হোক না কেন এটি কোনও গাইডলাইন থেকে ভাল