সমস্ত বিকাশকারীদের কোড পর্যালোচনা করা


13

আমি একটি 7-8 বিকাশকারী দলে একটি সফ্টওয়্যার বিকাশকারী। আমরা বেশ কিছুদিন ধরে কোড পর্যালোচনা করছি এবং সময়ের সাথে সাথে কোডের মান উন্নত হয়েছে।

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

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

আপনি কীভাবে আপনার দলে এই সমস্যাটি মোকাবেলা করবেন?

আপনি কোড পর্যালোচক বাছাই করার জন্য নিয়ম স্থাপন করেছেন?

আপনি কি মনে করেন যে কোড পর্যালোচনাকারীরা (ভাল) কোড পর্যালোচনা করে ব্যয় করার জন্য তাদের পুরস্কৃত করা উচিত? এবং তাদের কীভাবে পুরস্কৃত করা উচিত?

আপনার উত্তর / ধারণা জন্য ধন্যবাদ।


7
আপনি কি রাউন্ড রবিন সিস্টেম তৈরির বিষয়টি বিবেচনা করেছেন যেখানে কোডার উভয়ই অন্ধকারের মধ্যে পর্যালোচনা করছেন এবং পর্যালোচক অন্ধকারে রেখেছেন কে কোডার?
নিল

1
আমার নেই, তবে আমি এই ধারণাটি পছন্দ করি! ধন্যবাদ!
guillaumegallois

1
কে দায়িত্বে আছেন এবং কেন তারা তাদের কাজটি করেন না যা নিশ্চিত হওয়া উচিত যে প্রত্যেকে প্রত্যেকে তাদের কাজ করে?
জেফো

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

উত্তর:


12

আমরা পর্যালোচক নির্বাচন করি না।

আমাদের দলে:

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

কোড পর্যালোচনাগুলি বরাদ্দ করা হয় না, লোকেরা যখন তাদের জন্য কাজ করে তখন তাদের সেগুলি গ্রহণ করে। বোঝাপড়াটি হ'ল আমরা পাইপলাইনের মাধ্যমে গল্পগুলিকে ঠেলাতে পারি না। উপলক্ষ্যে কেউ উল্লেখ করবেন যে তারা স্ট্যান্ডআপে কোনও সিআরের অপেক্ষায় রয়েছে তবে এটি প্রায়।

আমি এই মডেলটি পছন্দ করি, এটি লোকেরা যা পারে তা চয়ন করতে দেয় এবং "লোকদের চাকরি দেওয়া" এড়ায়।


6

একটি নিয়ম প্রবর্তন করুন যে কোনও ত্রুটি ঠিক করার জন্য নির্ধারিত হতে পারে, যারা এই পরিবর্তনটি করেছিলেন কেবল তাদের জন্যই নয়, যারা কেবল এটি পর্যালোচনা করেছেন তাদেরও। এটি কোড পর্যালোচনার জন্য সঠিক দৃষ্টিকোণ তৈরি করা উচিত।

এর জন্য,

আপনি কি মনে করেন যে কোড পর্যালোচনাকারীরা (ভাল) কোড পর্যালোচনা করে ব্যয় করার জন্য তাদের পুরস্কৃত করা উচিত?

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


2
এটি একটি আকর্ষণীয় ধারণা, তবে অনেক সময় যখন ত্রুটি আসে, 90% কাজ ঠিক কী কারণে বাগটি সৃষ্টি করে তা নির্ধারণ করে এবং 10% কাজ এটি ঠিক করে চলেছে। ত্রুটিটি কী ঘটেছিল তা ঠিক কীভাবে ঘটেছিল তা নির্ধারণের জন্য একটি ময়না তদন্ত করা, যদি না এটি কী ঘটছে বা কীভাবে নিরাপদ স্থির করতে হয় তা নির্ধারণ করতে সহায়তা না করে।
ডেভজি

কোড পর্যালোচকদের যে ক্রেডিট দেওয়া উচিত তা সম্পর্কে আপনি একটি ভাল বক্তব্য রেখেছিলেন। এটি অবশ্যই একটি সমস্যা যা মোকাবেলা করা উচিত। আপনার উত্তরের জন্য ধন্যবাদ!
guillaumegallois

আমি মনে করি লোকেরা কোড রিভিউগুলি একেবারেই না করার চেষ্টা করতে পারে বা হতে পারে আপনার কোনও কাজ করা হবে না কারণ লোকেরা নিটপিক করা শুরু করবে।
ম্যাটিউজ

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

বাগগুলি রোধ করতে এবং বাগের ভবিষ্যতের ফিক্সটি দ্রুত হবে তা নিশ্চিত করার জন্য @ ডকব্রাউন (অন্য বিকাশকারীকে কোডের সাথে পরিচিত করে এবং কোডটি ভালভাবে লেখা আছে তা নিশ্চিত করে)
সর্বোচ্চ 630

4

আপনার প্রধান সমস্যাটি প্রযুক্তিগত নয়, তবে কিছু সরঞ্জাম কোড পর্যালোচনাগুলির যে পরিমাণ প্রচেষ্টা করে তা হ্রাস করতে পারে। কাটিয়ে উঠতে কয়েকটি চ্যালেঞ্জ রয়েছে:

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

এটি বলার অপেক্ষা রাখে না যে আপনি সাহায্যের জন্য সাবভিশন বা অন্যান্য সরঞ্জামগুলি (ফিশেয়ের মতো) ব্যবহার করতে পারবেন না, তবে গিটার পাইপলাইনে বৈশিষ্ট্যযুক্ত শাখাগুলির সাথে অন্তর্নির্মিত সংস্থাগুলি সত্যিই কাজকে কম-বেশি করে তোলে।

সরঞ্জামদানের বাইরে আপনার আরও সামাজিক চ্যালেঞ্জগুলি দেখতে হবে:

  • আপনার বিকাশকারীদের সাইন আপ করার জন্য কোনও খোলা পুল অনুরোধ পর্যালোচনা করে তাদের দিন শুরু করুন।
  • আপনার বিকাশকারীদের কোনও নতুন কাজ শুরু করার আগে কোনও খোলা টান অনুরোধগুলি পর্যালোচনা করতে বলুন
  • আপনার টানার অনুরোধের জন্য একাধিক ব্যক্তির অনুমোদনের প্রয়োজন।

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


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

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

2

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

স্পষ্টতই ছুটির মতো মাঝে মাঝে ব্যতিক্রম থাকবে যেখানে সেখানে শৃঙ্গ এবং খাত থাকবে।

জুনিয়র এবং সিনিয়র / সীসা মধ্যে কোনও পার্থক্য থাকা উচিত। কোড পর্যালোচনাগুলি প্রত্যেকের কোডের জন্যই করা উচিত - তারা যত উর্ধ্বতনই হোক না কেন। এটি ঘর্ষণ হ্রাস করে এবং বিভিন্ন পদ্ধতি ভাগ করতে সহায়তা করে।

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

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


0

দেখে মনে হচ্ছে দলের কোড পর্যালোচনার জন্য একটি আনুষ্ঠানিক প্রক্রিয়া নেই।

আমি একটি 350 পৃষ্ঠার ওয়ার্ড ডকুমেন্ট তৈরি করার কথা বলছি না, তবে প্রক্রিয়াটিতে কী রয়েছে তা সম্পর্কে কিছু সাধারণ বুলেট পয়েন্ট।

গুরুত্বপূর্ণ বিট:

  1. পর্যালোচকদের একটি মূল সেট সংজ্ঞা দিন। কোন সাধারণ বিবৃতি। নাম মানুষ।

    এগুলি আপনার সিনিয়র বিকাশকারী হওয়া উচিত।

  2. পর্যালোচনায় সাইন আপ করতে 1 টির বেশি মূল পর্যালোচক প্রয়োজন।

  3. প্রতিটি স্প্রিন্ট বা রিলিজ কমপক্ষে অন্য 1 টি নন-কোর রিভিউয়ার সনাক্ত করুন বা কে অস্থায়ী কোর পর্যালোচক। এই সময়ে সমস্ত কোড পর্যালোচনাগুলিতে তাদের সাইন অফ প্রয়োজন।

আইটেম # 3 অন্যান্য ডেভগুলিকে মূল পর্যালোচক গোষ্ঠীতে ঘোরানোর অনুমতি দেয়। কিছু সপ্তাহ তারা অন্যদের তুলনায় পর্যালোচনায় বেশি সময় ব্যয় করবে। এটি ভারসাম্যপূর্ণ কাজ act

মানুষের পুরষ্কার হিসাবে? পুরো দলটির সামনে কোড পর্যালোচনা চলাকালীন কোনও ব্যক্তি যে প্রচেষ্টা করছেন তা স্বীকার করে নেওয়া অনেক সময় কাজ করতে পারে তবে নিজেকে এ নিয়ে চাপ দেবেন না।

সন্দেহ হলে, প্রক্রিয়াটি সংজ্ঞায়িত করুন এবং তাদেরকে এটির সাথে লেগে থাকার প্রয়োজন বলুন।

এবং একটি শেষ জিনিস আপনি চেষ্টা করতে পারেন - এটি বিতর্কিত হিসাবে যেমন হতে পারে: @ # $% অনুরাগীর উপর আঘাত হানুন, যদি আমি কোনও প্রতিমা ব্যবহার করতে পারি।

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

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

কখনও কখনও আপনাকে কেবল টাইটানিককে আইস বার্গে আঘাত করতে দেওয়া উচিত।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.