কোড পর্যালোচনা কর্মপ্রবাহ যেখানে পুল অনুরোধের লেখককে অবশ্যই মার্জ করতে হবে


16

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

  1. কোড লেখক একটি টান অনুরোধ জমা দেয়
  2. রিভিউয়ার কোডটি পরীক্ষা করেন
    • যদি পর্যালোচক অনুমোদিত হয় তবে তারা "দেখতে ভাল লাগছে, একীভূত হতে নির্দ্বিধায়" লাইন ধরে একটি মন্তব্য রেখে যান
    • যদি পর্যালোচকদের উদ্বেগ থাকে, তবে তারা দয়া করে "দয়া করে ছোটখাটো সমস্যা X এবং Y স্থির করুন, তারপরে মার্জ করুন" (বড় পরিবর্তনের জন্য, দ্বিতীয় ধাপে ফিরে যান) এর মতো একটি মন্তব্য রেখে যান leave
  3. কোড লেখক প্রয়োজনে পরিবর্তন করেন এবং তারপরে তার নিজের অনুরোধটিকে মার্জ করে

আমার নিম্নলিখিত উদ্বেগগুলি রয়েছে:

  • পদক্ষেপ 3 এ অনুমোদনের ক্ষেত্রে, এই কর্মপ্রবাহটি পুল অনুরোধ লেখকের কাছে আপাতদৃষ্টিতে-অপ্রয়োজনীয় রাউন্ডট্রিপ তৈরি করে। পর্যালোচক, যিনি ইতিমধ্যে কোডটি দেখছেন, কেবলমাত্র তা সঙ্গে সঙ্গে মার্জ করতে পারেন।

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

এই কর্মপ্রবাহের আরও কিছু সুবিধা বা অসুবিধা কী? এই কর্মপ্রবাহটি কি অন্যান্য ইঞ্জিনিয়ারিং দলগুলিতে সাধারণ?


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

1
আপনার সংস্থায় যখন পর্যালোচক লিখবেন "দয়া করে মেজর ইস্যুটি X ঠিক করুন" তখন কী ঘটে ?
ডক ব্রাউন

8
আমার অভিজ্ঞতা হিসাবে, একত্রীকরণ সংঘাতের সমাধানের ক্ষেত্রে মুলত লেখকের পক্ষে একীভূত হওয়া ভাল। মূল লেখক হলেন সাধারণত যিনি একত্রীকরণ বিরোধকে কীভাবে সমাধান করবেন তা নির্ধারণের জন্য সবচেয়ে বেশি সজ্জিত।
26

আমি এখানে যুক্তি হিসাবে কৌতূহলী হতে হবে। আপনার সহকর্মীদের জিজ্ঞাসা করা উচিত এবং এটি একটি স্ব-উত্তর হিসাবে লিখতে হবে - এখানে খুব ভাল চিন্তার প্রক্রিয়া বা যুক্তি থাকতে পারে। আমি শুধু একজনের সাথে দ্রুত আসতে পারছি না।
থমাস ওভেনস

উত্তর:


21

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

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

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

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


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

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

3

প্রাথমিক লেখককে তাদের নিজস্ব টানার অনুরোধটি মার্জ করা ছোট দলে আমার পছন্দের ওয়ার্কফ্লো। ইতিমধ্যে উল্লিখিত প্রযুক্তিগত সুবিধাগুলির পাশাপাশি (উদাহরণস্বরূপ, মার্জ সংঘাতের সমাধানের ক্ষেত্রে), আমি মনে করি এটি একটি সাংস্কৃতিক স্তরের মূল্য যুক্ত করে: এটি মালিকানার একটি ধারণা তৈরি করে।

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


2

আমার সংস্থায় আমরা পুল অনুরোধে বেশ নতুন এবং আপনার প্রশ্নটি আমি নিজেই ভেবে দেখেছি।

একটি পর্যবেক্ষণ আমি যুক্ত করতে চাই: কিছু সরঞ্জামগুলিতে (আমরা টিএফএস ব্যবহার করি) এর সাথে টান অনুরোধের সাথে কোনও কাজের আইটেম থাকতে পারে।

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

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


1

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

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