কোড পর্যালোচনা সম্পাদন করার সবচেয়ে কার্যকর উপায় কী? [বন্ধ]

Question

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

কোড পর্যালোচনা সম্পাদনের জন্য আপনার পক্ষে সবচেয়ে কার্যকর উপায় কী?

উদাহরণ স্বরূপ:

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

Comments

স্মার্ট বিয়ার সফ্টওয়্যারটিতে পীর কোড রিভিউয়ের সেরা কেপট সিক্রেটস নামে একটি বিনামূল্যে বই রয়েছে এটি নিখরচায় শিপিংয়ের সাথে বিনামূল্যে। এবং তারা মাঝে মাঝে বিক্রয় ইমেলের সাথে অনুসরণ করে। তারা খুব কমই অনুপ্রবেশকারী ছিল। এবং যাইহোক ... বইটি বেশ ভাল।

— জন ম্যাকআইন্টির

Answer 1

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

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

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

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

Comments

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

— নিওনিগমা

Answer 2

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

যদি কোনও প্রজেক্টরের সাথে গোষ্ঠী হিসাবে সম্পন্ন হয় তবে সভার আগে এটি পৃথকভাবে পর্যালোচনা করা উচিত । অন্যথায় এটি সময়ের বিরক্তি মাত্র waste

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

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

আমি বিশ্বাস করি যে কোডের মালিকানা হ'ল একটি ভাল ধারণা কারণ এই ব্যক্তিটি কোডটি বুঝতে এবং সম্ভাব্য গেটকিপারের ভূমিকা পালন করতে তাদের অগ্রাধিকার তৈরি করতে পারে।

Comments

জন্য +1 "। যদি একটি প্রজেক্টর এর সাথে একটি গোষ্ঠী সম্পন্ন হয়েছে বলে, আসলেই স্বতন্ত্রভাবে সভার আগে পর্যালোচনা করা উচিত অন্যথায়, এটি ঠিক সময়ে একজন বিরক্তিকর নষ্ট হয়।"

— AShelly

"যদি একটি প্রজেক্টরের সাথে একটি গোষ্ঠী হিসাবে এটি করা হয় তবে এটি একটি বিরক্তিকর সময় অপচয়" .. সেখানে, এটি আপনার জন্য স্থির করে।

— gbjbaanb

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

— দিদিয়ার এ।

Answer 3

এ SmartBear আমরা না শুধুমাত্র একটি করতে কোড পর্যালোচনা টুল , আমরা এটা দিনের ভিত্তিতে একটি দিনে ব্যবহার করুন। এটি আমাদের উন্নয়ন প্রক্রিয়ার একটি অপরিহার্য অঙ্গ। চেক ইন করা প্রতিটি পরিবর্তন আমরা পর্যালোচনা করি।

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

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

Comments

নীচে লিংক করুন ...........

— পেসারিয়ার

লিঙ্ক পচা সম্পর্কে দুঃখিত। আমি বর্তমান ইউআরএল সম্পাদনা করেছি, কিন্তু এটি আবার ঘটতে বাধা দেয় না।

— ব্র্যান্ডন ডুরেট

Answer 4

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

Comments

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

— ডুবুর্ট

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

— ডাঙ্ক

Answer 5

আপনি যদি এমন প্রকল্পে কাজ করছেন যেখানে একাধিক লোক কোড বেজে অবদান রাখবে একটি মানক প্রতিষ্ঠিত হওয়া দরকার।

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

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

যদি কোনও ফাংশন সঠিক না হয় তবে আমরা মালিকের সাথে কথা বলি, শ্রেণির সাথে একই etc.

Answer 6

আমার সংস্থায় প্রতিটি টাস্ককে টাস্কটি পরীক্ষা করার জন্য একজন পরীক্ষক এবং কোড পর্যালোচনা করার জন্য একটি কোড পর্যালোচক নিয়োগ করা হয়।

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

যদি আপনার দলে সমস্ত প্রবীণ বিকাশকারী থাকে তবে পিয়ার পর্যালোচনা এখনও কার্যকর। সবাই মাঝে মাঝে ভুল করে mistakes যদি আপনার দলে কিছু সিনিয়র এবং কিছু জুনিয়র থাকে তবে সিনিয়র বিকাশকারীদের কোড পর্যালোচনা করতে দিন, তবে তারপরেও সিনিয়র কোডের জন্য কোড পর্যালোচনা থাকতে হবে।

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

Answer 7

আপনি যদি জোড় প্রোগ্রামিং না করে থাকেন তবে আমি কোড রিভিউগুলি ব্যবহার করার পরামর্শ দিচ্ছি।

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

Answer 8

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

YMMV

Answer 9

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

সমালোচনামূলক অবকাঠামো শিল্প নির্ভরযোগ্যতা এবং এর পুনরাবৃত্তিতে খুব আগ্রহী। :-)

Answer 10

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

এই সিস্টেমটি ভালভাবে কাজ করে - সময় অনুমতি হিসাবে পর্যালোচনাগুলি করা হয় এবং কয়েকটি সেট চোখের বল দ্বারা পর্যালোচনা করা যেতে পারে।

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

Comments

সিনিয়রদের জন্য স্বেচ্ছাসেবী পর্যালোচনা। আমি একাধিক প্রকল্পে কাজ করেছি যেখানে সিনিয়র প্রোগ্রামাররা অবশ্যই কোড রিভিউ ব্যবহার করতে পারে ...

— মিশেল

Answer 11

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

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

একটি পর্যালোচক হিসাবে, আপনাকে কেবলমাত্র কেবলমাত্র "// টুডো: আমার দ্বারা কোড পর্যালোচনা" এর জন্য পুরো কোডটি অনুসন্ধান করতে হবে , পরিবর্তনগুলি পর্যালোচনা করতে হবে এবং "টুডো ..." মন্তব্য ছাড়াই কোডটি আবার পরীক্ষা করে দেখুন to

যদি কোনও সমস্যা হয় তবে আমরা traditionalতিহ্যবাহী যোগাযোগ পদ্ধতিতে (মেল / চ্যাট / ইত্যাদি) ফিরে যাই।

এই পদ্ধতিটি আমাদের দুটি প্রধান গুণাবলী সরবরাহ করে যা আমরা একটি পর্যালোচনা সিস্টেমের সন্ধান করছি:

• খুব হালকা ওভারহেড
• traceability

Answer 12

আমরা শাখার পার্থক্যগুলি দেখানোর জন্য গিথুবটি ব্যবহার করে 1-অন-1 কোড পর্যালোচনাগুলি করার সবচেয়ে কার্যকর উপায়টি খুঁজে পাই।

---

• কোনও ব্যক্তিকে কি মানের জন্য দ্বাররক্ষক হিসাবে বিবেচনা করা হয় এবং কোডটি পর্যালোচনা করা হয়, না কি দলটি স্ট্যান্ডার্ডটির মালিক?

  • দলের আকারের উপর নির্ভর করে - 3 এর দলে 1 জন প্রবীণ থাকবেন যারা ভাল অনুশীলনের সর্বোত্তম জ্ঞান রাখবেন, যেখানে 12 এর একটি দলে 3 বা 4 জন ব্যক্তি থাকতে পারে যারা এই ভূমিকাটি সম্পাদন করবে।

• আপনি কি প্রজেক্টর ব্যবহার করে টিম এক্সারসাইজ হিসাবে কোডটি পর্যালোচনা করেন?

  • ব্যাক্তিগতভাবে. 1 এ 1 কম হুমকি হতে হবে। জ্ঞান ছড়িয়ে পড়ার জন্য কখনও কখনও সাম্প্রদায়িক অঞ্চলে করা হয়। সঠিক পরিস্থিতি, লোক, সময়সূচী ইত্যাদির উপর নির্ভর করে

• এটি ব্যক্তিগতভাবে, ইমেলের মাধ্যমে বা কোনও সরঞ্জাম ব্যবহার করে করা হয়েছে?

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

• কোড পর্যালোচনাগুলি নিশ্চিত করার জন্য আপনি কি জুড়ি প্রোগ্রামিং এবং সম্মিলিত কোডের মালিকানার মতো জিনিসগুলি পর্যালোচনাগুলি এচইউ করেন এবং ব্যবহার করেন?

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

সমস্ত কোডিং আইটেমের মতো, সঠিক উত্তরটিও আমলে নেওয়া উচিত:

• সংস্থার ধরণ (যেমন স্টার্টআপ বনাম বড় কর্পোরেশন)
• কোম্পানির আকার
• বিকাশকারীর সংখ্যা
• বাজেট
• সময়ের ফ্রেম
• কাজের চাপ
• কোডের জটিলতা
• পর্যালোচক (গুলি) এর ক্ষমতা
• পর্যালোচক (গুলি) এর উপলব্ধতা

Answer 13

আমি অনেক সংস্থায় কাজ করেছি এবং অনেক প্রক্রিয়া দেখেছি। আমার বর্তমান দলটি এ পর্যন্ত পরিচালনা করেছি best

আমরা একটি চৌকস বিকাশ প্রক্রিয়া ব্যবহার করি এবং এর অংশ হিসাবে আমাদের কাছে প্রতিটি গেটের মধ্য দিয়ে যেতে হবে এমন গেট রয়েছে। এই গেটগুলির মধ্যে একটি হল কোড পর্যালোচনা। কোড পর্যালোচনা না হওয়া পর্যন্ত গল্পটি পরীক্ষায় চলে না।

অতিরিক্তভাবে আমরা github.com এ আমাদের কোড সঞ্চয় করি। সুতরাং কোনও বিকাশকারী তাদের পরিবর্তন শেষ করার পরে, তারা গল্পটির প্রতিশ্রুতিগুলির লিঙ্ক পোস্ট করে।

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

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

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

পরীক্ষা করে যদি কিছু পিছনে ফিরে আসে তবে তা পুরো পথে ফিরে যায় এবং আরও যে কোনও পরিবর্তনগুলিও পর্যালোচনা করা হয়।