কোনও ট্রাঙ্কে প্রতিশ্রুতিবদ্ধ হওয়ার আগে কোনও কোড পর্যালোচনা করার সর্বোত্তম উপায় কী? (SVN)


14

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


2
আপনি ক্রুসিবিলের মতো কিছু সরঞ্জাম সন্ধান করতে পারেন যা প্রাক-প্রতিশ্রুতি পর্যালোচনাগুলির জন্য সমর্থন সরবরাহ করে।
জ্ঞান ওরফে গ্যারি বুইন

3
কোনও ট্রাঙ্কে প্রতিশ্রুতিবদ্ধ হওয়ার পরে কোনও কোড পর্যালোচনা করার কোনও কারণ নেই ?
gnat

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

আপনি কি অন্যভাবে চেষ্টা করেছেন বা এটি কেবল অনুমান করা হচ্ছে?
gnat

উত্তর:


12

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

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

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

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


1
অবিচ্ছিন্ন শাখা তৈরি এবং বার বার মার্জ করা এমন এক বিচ্ছিন্নতা যা দূষিত ট্রাঙ্কের সম্ভাব্য (এবং অকাট্যভাবে) ছাড়িয়ে যায়। সাধারণত সংস্করণ নিয়ন্ত্রণের প্রধান নির্দেশ হ'ল "বিল্ডটি ভাঙ্গবেন না"। যদি আপনি এটি করতে পারেন তবে চেক ইন করার কোনও সত্যিকারের ক্ষতি নেই এবং সমস্ত কিছু সত্যের পরে সামঞ্জস্য।
স্পেন্সার কোর্মোস

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

7
  1. কমিট করার আগে প্যাচ ফাইল তৈরি করতে 'এসএনএন ডিফার' চালান run
  2. প্যাচ ফাইলটি পর্যালোচককে প্রেরণ করুন যিনি এটি ট্রাঙ্কের একটি পরিষ্কার কপির জন্য প্রয়োগ করেন।
  3. পর্যালোচক পছন্দের পার্থক্য প্রদর্শক ব্যবহার করে পরিবর্তনগুলি অতিক্রম করে।
  4. পর্যালোচক বিল্ড সম্পাদন করে এবং পরীক্ষা চালায়।
  5. যদি সবকিছু ঠিকঠাক হয় তবে বিকাশকারীকে বলুন তারা তাদের পরিবর্তনগুলি পরীক্ষা করতে পারে। যদি
    সমস্যা থাকে তবে বিকাশকারী পদক্ষেপ 1 এ ফিরে যান।

5

আদর্শ পৃথিবী আছে, এবং তারপরে আসল বিশ্ব।

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

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

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


সাপ্তাহিক পর্যালোচনা ধারণার জন্য +1। আমার
জেমি টেলর

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

2

শাখাগুলি পূর্বের চাকরিতে প্রাক-কমিটির পর্যালোচনাগুলিতে সেগুলি ব্যবহারের আমার অভিজ্ঞতার ভিত্তিতে ঠিকঠাক কাজ করা উচিত।

তারপরে আবার নোট করুন, আমরা কেবলমাত্র প্রডাকশন রিলিজ প্রার্থী কোডের সমালোচনামূলক প্যাচগুলির জন্য প্রাক কমিট রিভিউগুলি ব্যবহার করছিলাম, সুতরাং খুব বেশি শাখা ছিল না (কমিট পোস্টের পরে পর্যালোচনার মাধ্যমে রুটিন পরিবর্তনগুলি পাস হয়েছিল)।

যেহেতু আপনি সমস্ত পরিবর্তনের জন্য প্রাক-প্রতিশ্রুতি পর্যালোচনা ব্যবহার করছেন বলে মনে হচ্ছে, আপনার প্রচুর পরিমাণে শাখা পরিচালনা করতে হবে। আপনি যদি বিকাশকারীকে প্রতি সপ্তাহে গড়ে একটি "পর্যালোচনাযোগ্য" পরিবর্তন করার প্রত্যাশা করেন, তবে আপনার দলে প্রতি বিকাশকারী হিসাবে প্রতি বছর প্রায় 50 টি শাখা থাকবে। আপনি যদি ছোট ছোট কাজগুলি ব্যবহার করছেন - যেমন 1, 2, 3 ... দিন যাচ্ছেন - 50 কে 2, 3, 5 দিয়ে গুন করুন ... সেই অনুযায়ী।

আপনি যদি সেরা উপায়ে চান তা বিবেচনায় নেওয়ার জন্য নীচে কয়েকটি অন্যান্য বিবেচ্য বিষয় রয়েছে ।

1. অন্যান্য দলের সদস্যদের জন্য বিলম্বিত পর্যালোচনা ব্লক কোডের প্রয়োজন হলে কেসগুলি পরিচালনা করা

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

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

২. পর্যালোচিত কোড জমা দেওয়ার সময় সংঘাতগুলি মার্জ করুন

কোড পর্যালোচনার অপেক্ষায় থাকাকালীন যদি পর্যালোচিত কোডের জন্য প্রতিশ্রুতিবদ্ধ অন্য কারও দ্বারা সংঘটিত বিরোধী পরিবর্তনগুলি দ্বারা অবরুদ্ধ করা হয় তবে কী করবেন?

কয়েকটি বিকল্প বিবেচনা করা হয়

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

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

৩. লোড বিকাশকারী যা পর্যালোচনার জন্য অপেক্ষা করছেন

যে বিকাশকারী পর্যালোচনা জমা দিয়েছেন তাদের নতুন কোনও কাজে স্যুইচ করা উচিত বা অন্য কিছু করা উচিত (যেমন উদাহরণস্বরূপ পর্যালোচককে তাড়ানোর) জন্য একটি সুস্পষ্ট নীতি প্রতিষ্ঠা করুন।

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


0

যে পর্যায়ের বিকাশের পর্যালোচনা দরকার তা পৃথক শাখায় থাকতে হবে। সুতরাং, পর্যালোচনা করার সময় আসার আগে শাখাটির ইতিমধ্যে উপস্থিত থাকা উচিত। তারপরে পদক্ষেপটি হওয়া দরকার:

  1. পুনঃমূল্যায়ন
  2. সংশোধন (সম্ভবত)
  3. লুপ পর্যালোচনা ফিরে (সম্ভবত)
  4. ট্রাঙ্কে মার্জ করুন

মার্জ করা কঠিন বিট। শাখাটি যত দীর্ঘ স্বাধীন থাকে, তত শক্ত করে তা আবার ট্রাঙ্কে মিশে যায়। (এটি পরীক্ষা করা আরও কঠিন হতে পারে))

ক্রস মার্জ করা একটি সম্ভাব্য সমাধান। ট্রাঙ্কে মার্জ হওয়ার আগে (পদক্ষেপ 4, বা তারও আগে, তৃতীয় 3 বা পদক্ষেপ 1 এর আগে বলুন), ট্রাঙ্কটি শাখায় মার্জ করুন। বিকাশকারী এটি করতে এবং এটি পরীক্ষা করতে পারে। তারপরে শাখাটি ট্রাঙ্কের সাথে ধরা পড়ে এবং ট্রাঙ্কে এটি একীভূত করা আরও সহজ হয়ে যায়। ট্রাঙ্কে মার্জ করা আপনার দ্বারা সেরা, বা যে ট্রাঙ্কের দায়িত্বে আছেন।

কিছু লোক ক্রস-সংযুক্তির পরিবর্তে রিবেস চেষ্টা করে। কিছু লোক যুক্তি দেয় যে রিবেসটি খারাপ। সেটা অন্য বিতর্ক।

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