পুলের অনুরোধগুলি বড় হলে কীভাবে আরও ভাল কোড পর্যালোচনা করা যায়?

Question

অস্বীকৃতি: এখানে কিছু অনুরূপ প্রশ্ন রয়েছে তবে একটি বড় টানার অনুরোধটি পর্যালোচনা করার সময় আপনি যে সমস্যার মুখোমুখি হয়েছিলেন তা স্পষ্টভাবে স্পর্শ করি নি।

সমস্যা

আমার কোড রিভিউগুলি আরও ভালভাবে করা যেতে পারে বলে আমি মনে করি। আমি বিশেষত 20+ ফাইল জুড়ে অনেকগুলি পরিবর্তন সহ বড় কোড পর্যালোচনার বিষয়ে কথা বলছি।

সুস্পষ্ট স্থানীয় কোড সমস্যাগুলি ধরা খুব সহজ। কোডটি ব্যবসায়ের মানদণ্ডে মেলে কিনা তা বোঝা যদিও আলাদা গল্প।

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

সম্ভাব্য সমাধান এবং কেন তারা আমার পক্ষে কাজ করে না

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

অবশ্যই, ছোট টানার অনুরোধগুলি তৈরি করা একটি প্রতিকারের মতো মনে হয় তবে এটি হ'ল, কখনও কখনও আপনি একটি বড় টানার অনুরোধ পান এবং এটি পর্যালোচনা করতে হবে।

আপনি সামগ্রিকভাবে কোডটির যৌক্তিক দিকটিকেও এড়িয়ে যেতে পারেন, তবে এটি বেশ ঝুঁকিপূর্ণ বলে মনে হয়, বিশেষত যখন কোডটি কোনও অনভিজ্ঞ প্রোগ্রামার থেকে আসে।

আরও ভাল সরঞ্জাম ব্যবহার করা সহায়ক হতে পারে তবে আমি একটিও পাইনি।

প্রশ্নাবলি

• আপনার কোড পর্যালোচনা নিয়েও কি একই সমস্যা রয়েছে? আপনি কিভাবে তাদের মুখোমুখি?
• আপনার কাছে আরও ভাল সরঞ্জাম থাকতে পারে?

Comments

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

— Jörg ডব্লু মিট্টাগ

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

— মিথ্যা রায়ান

Answer 1

আমাদের এই সমস্যাগুলি ছিল এবং নীচের প্রশ্নটি জিজ্ঞাসা করা আমাদের জন্য ভাল কাজ করে:

PR কি এমন এক কাজ করে যা একীভূত হতে পারে এবং স্বতন্ত্রভাবে পরীক্ষা করা যেতে পারে?

আমরা একক দায়িত্ব (এসআর) দ্বারা PRs ভাঙার চেষ্টা করি। প্রাথমিক ধাক্কা দেওয়ার পরে লোকেরা অবাক হয়ে জানতে পেরেছিল যে এমনকি একক ছোট কিছু হলেও বড় হতে পারে।

এসআর এটি পর্যালোচনা করা সত্যিই সহজ করে তোলে এবং প্রত্যাশিত বাস্তবায়নের জ্ঞানও ছড়িয়ে দেয়।

আরও যুক্ত হওয়ার সাথে সাথে পিআর টার্নআরাউন্ড সময় তাত্পর্যপূর্ণভাবে হ্রাস হওয়ায় এটি ইনক্রিমেন্টাল রিফ্যাক্টরদেরও অনুমতি দেয়!

আমি সম্ভব হলে এসআর দ্বারা তাদের বিচ্ছেদ করার পরামর্শ দিই এবং এটি আপনার পক্ষে কার্যকর কিনা তা দেখুন। সেভাবে এটি করার জন্য কিছু অনুশীলন নেয়।

Answer 2

কখনও কখনও আপনি বড় টানা অনুরোধগুলি এড়াতে পারবেন না - তবে কার কী দায় রয়েছে তা আপনি বুঝতে পারছেন।

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

যে কোনও যুক্তি হিসাবে এটির একটি একক পরিষ্কার ধারণা থাকা উচিত। এটি হয়:

• একটি চুল্লী,
• একটি অপ্টিমাইজেশন,
• বা নতুন কার্যকারিতা।

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

এখনও বড় টান অনুরোধ থাকবে, কিন্তু একটি সুস্পষ্ট যুক্তি দিয়ে এটি মাপসই করা যায় না এটি দেখতে এটি আরও সহজ।

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

Answer 3

সম্পূর্ণ টান অনুরোধ পর্যালোচনা করবেন না, কিন্তু প্রতিটি প্রতিশ্রুতিবদ্ধ। আপনি যেভাবেই টানুন অনুরোধটি এইভাবে করে আরও ভালভাবে বুঝতে পারবেন ¹

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

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

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

আপনি এটি করেন তবে এটি একটি সামান্য সমস্যা, এবং কোনও ফাইলের পর্যালোচনা করার সময় কেন কোডটি পরিবর্তন করা হয়েছিল তা নির্ধারণের চেষ্টা করার পরে আপনি যে সময়টি ব্যর্থ করেছেন তার চেয়ে কয়েকটা কমিট পরে পূর্বাবস্থায় ফিরে যাওয়া কোডটি পর্যালোচনা করা উচিত।

"প্রায়শই" অস্পষ্ট, তবে যদি আপনি নিজেকে খুব বেশি সময় ব্যয় করতে কোডের পুনর্বিবেচনার চূড়ান্ত পুনর্বিবেচনার উপায় খুঁজে পাইনি তবে আপনি দুটি কৌশল ব্যবহার করতে পারেন:

• একবারে সমস্ত কমিটের মাধ্যমে দ্রুত যান, কেবল প্রতিশ্রুতি বার্তাগুলি পড়ে। এইভাবে, কোনও বিশেষ প্রতিশ্রুতি অধ্যয়ন করার সময়, আপনি মনে করতে পারেন যে কোনও প্রতিশ্রুতি বার্তা পরে বলেছিল যে আপনি যে পরিবর্তনটি দেখছেন তা আবার ফিরে গেছে।

• ফাইলের সর্বশেষ সংস্করণটির পাশাপাশি-পাশাপাশি দেখুন (যদিও অনেক ক্ষেত্রে বড় কমিটের জন্য, (1) ফাইলগুলি মূলত আলাদা হতে পারে এবং (২) ফাইলগুলির নাম পরিবর্তন করা যেতে পারে বা কোডের বৃহত ব্লকগুলি হতে পারে ম্যাচিং ফাইলটি খুঁজে পেতে অসুবিধা বোধ করে অন্য কোথাও চলে যান)।

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

---

^{Instance উদাহরণস্বরূপ, কল্পনা করুন আপনি এমন একটি ফাইল খুঁজছেন যেখানে কিছু ভেরিয়েবলের নাম পরিবর্তন করা হয়েছে। এটা কি বলে? আপনার এই পরিবর্তনটি কীভাবে পর্যালোচনা করা উচিত? আপনি যদি প্রতিশ্রুতিবদ্ধ হয়ে এটি প্রতিশ্রুতিটি পর্যালোচনা করে দেখেন তবে আপনি দেখতে পাবেন যে একটি একক কমিট বিশটি ফাইলে একই পরিবর্তনশীলটির নাম পরিবর্তন করেছে এবং মন্তব্যটি নির্দেশ করে যে সঠিক ব্যবসায়ের শব্দটি ব্যবহার করার জন্য নামটি পরিবর্তন করা হয়েছিল। এই পরিবর্তনটি সঠিক ধারণা দেয় এবং পর্যালোচনা করা সম্ভব।}

Comments

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

— আর্সেনী মোরজেনকো

Answer 4

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

উদাহরণস্বরূপ আপনি চাইবেন

• নিশ্চিত করুন মান অনুসরণ করা হয়
• কার্যকারিতা চেক করুন
• একাধিক ব্যক্তি কোডটি বোঝে তা নিশ্চিত করুন
• ট্রেন জুনিয়র

ইত্যাদি ইত্যাদি

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

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

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

আপনার যতক্ষণ না QA তে স্তরযুক্ত পদ্ধতির ব্যবস্থা রয়েছে ততক্ষণ প্রতিটি পিআর-তে সমস্ত জিনিস পরীক্ষা করার দরকার নেই