কোড কমিট করার আগে বা পরে রিভিউ করুন, এর থেকে ভাল কে?

Question

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

প্রথমত, এখানে কিছু পটভূমি রয়েছে,

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

প্রতিশ্রুতিবদ্ধ হওয়ার আগে কোড পর্যালোচনার সুবিধাগুলি:

1. মেন্টর নতুন ভাড়া
2. উন্নয়নের চক্রের প্রথম দিকে ত্রুটি, ব্যর্থতা, খারাপ নকশা রোধ করার চেষ্টা করুন to
3. অন্যের কাছ থেকে শিখুন
4. কেউ ত্যাগ করলে জ্ঞান ব্যাকআপ

তবে আমার কিছু খারাপ অভিজ্ঞতাও হয়েছে:

1. স্বল্প দক্ষতা, কিছু পরিবর্তন কয়েক দিনের মধ্যে পর্যালোচনা হতে পারে
2. গতি এবং মানের ভারসাম্যপূর্ণ, বিশেষত newbies জন্য
3. দলের একজন সদস্য অবিশ্বাস অনুভব করেছেন

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

হালনাগাদ:

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

Comments

তারা কি তাদের নিজস্ব শাখায় প্রতিশ্রুতিবদ্ধ? এটি প্রতিশ্রুতি পোস্টের পর্যালোচনার জন্য আপনার সহকর্মীদের যুক্তি হতে পারে। ব্যক্তিগতভাবে আমি খুব অনভিজ্ঞ ডেভেলপারদের জন্য প্রাক-প্রতিশ্রুতিটি বলব।

— সাইমন হোয়াইটহেড

পরিবর্তে এটি সেরা বিকল্পটি পর্যালোচনা করুন

— shabunc

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

— HABO

এতে নকল হয়েছে: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জারওয়েজ /

— সেকশনস /

Answer 1

সাইমন হোয়াইটহেড যেমন তাঁর মন্তব্যে উল্লেখ করেছেন , এটি আপনার শাখা-প্রশাখার কৌশলের উপর নির্ভর করে।

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

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

Comments

যদি বিকাশকারীদের নিজস্ব শাখা থাকে এবং আপনার কাছে সঠিক কোড-পর্যালোচনা সরঞ্জাম থাকে, আপনি নিয়ন্ত্রণ বজায় রাখতে পারেন। পর্যালোচনাকারীরা পর্যালোচনাটি সম্পন্ন করেছেন কিনা তা সরঞ্জামটিতে রেকর্ড করতে হবে।

— মার্কজে

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

— vaab

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

— পঞ্চম

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

— ইজকাটা

@ থমাস ওভেনস: পার্ফোর্স শাখা প্রশাখাকে সমর্থন করে তবে এসভিএন, জিআইটি বা মারকুরিয়াল সহজেই নয়।

— কেভিন ক্লাইন

Answer 2

এমন একটি মন্ত্র রয়েছে যা এখনও কেউ উদ্ধৃত করেনি বলে মনে হয়: তাড়াতাড়ি এবং প্রায়শই দেখুন :

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

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

আমার থাম্বের নিয়মটি "প্রারম্ভিক এবং প্রায়শই চেক ইন" হয় তবে আপনার ব্যক্তিগত সংস্করণে অ্যাক্সেস থাকা সতর্কতার সাথে। যদি অন্য ব্যবহারকারীদের কাছে চেক-ইনটি তাত্ক্ষণিকভাবে দৃশ্যমান হয়, তবে আপনি অপরিণত পরিবর্তনগুলি প্রবর্তন এবং / বা বিল্ডটি ভাঙার ঝুঁকি চালান।

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

... আপনি যদি খুব তাড়াতাড়ি চেক করতে এবং প্রায়শই চেক করতে শিখেন তবে আপনার প্রতিক্রিয়া, সংহতকরণ এবং পর্যালোচনা করার জন্য পর্যাপ্ত সময় থাকবে ...

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

জেফ আতউডের বক্তব্যও রয়েছে: জিনিসগুলি ভাঙতে ভয় করবেন না :

সফ্টওয়্যার বিকাশকারী হিসাবে উন্নতির সর্বাধিক প্রত্যক্ষ উপায় হ'ল আপনার কোড পরিবর্তন করার ক্ষেত্রে একেবারে নির্ভীক হওয়া। ভাঙা কোড নিয়ে ভয় পাওয়া বিকাশকারীরা এমন বিকাশকারী যা পেশাদারদের মধ্যে কখনও পরিণত হবে না।

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

Comments

আমি এই উত্তরটি পছন্দ করি - আমি মনে করি এটি অনুগ্রহে বর্ণিত বাকী বিষয়গুলি বেশ ভালভাবে পূরণ করে।

— জোরিস টিমারম্যানস

বেশ কেন এটা গুরুত্বপূর্ণ VCS এড়ানোর জন্য একটি আকর্ষক ব্যাখ্যা দ্বারা পর্যালোচনার অবরুদ্ধ হচ্ছে করে

— মশা

এটা অনেক ভাল। এটি এন্টারপ্রাইজের মতো বিকাশের শব্দ তৈরি করা শুরু করে যা একটি যান্ত্রিক দোষ এড়ানোর সিস্টেমের বিরোধী দলের মধ্যে যোগাযোগকে গুরুত্ব দেয়।

— ইয়ান

Answer 3

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

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

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

Comments

এটি প্রস্তাব দেয় যে ছোটখাটো সমস্যা বা পরামর্শগুলি পর্যালোচক দ্বারা হয় "সংশোধন" করা হয়েছে, না মোটেও নয়? আমি আশা করব যে কোনও পর্যালোচনা মন্তব্য লেখককে সম্বোধনের জন্য ফিরে দেওয়া (বা প্রত্যাখ্যান)

— অ্যান্ড্রু

Answer 4

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

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

Comments

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

— পঞ্চম

আমরা সমস্ত কোড পর্যালোচনা করি না তবে কমপক্ষে মধ্যপন্থী জটিল everything

— guillaume31

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

— কুবি

Answer 5

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

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

Comments

আমি জুটি কোডিং পছন্দ করি তবে মাইক, একজন সিনিয়র এবং জুনিয়র জোড় কোডিং নয়, এটি পরামর্শদাতা। আমি দৃ ment়ভাবে পরামর্শদানের পরামর্শ দিচ্ছি, তবে এই দুটি বিষয়কে / বিপরীত কারণগুলির হিসাবে আলাদা করা উচিত এবং ফলাফলগুলি, পরামর্শদাতা এবং জোড় প্রোগ্রামিংয়ের মধ্যে সম্পূর্ণ আলাদা। চতুর্থ পোস্টটি দেখুন: c2.com/cgi/wiki?PairProgrammingDoubts এছাড়াও c2.com/cgi/wiki?PairProgrammingIsDoneByPeers

— জিমি হোফা

সর্বদা না। জুনিয়র ব্যক্তির ইনপুট থাকতে পারে। অথবা "বোকা ত্রুটি" লক্ষ্য করুন।

— জিনে বোয়ারস্কি

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

— জিমি হোফা

আপনি ঠিক বলেছেন ... তবে আমি মনে করি এটি জ্ঞান ভাগ করে নেওয়ার সবচেয়ে কার্যকর মাধ্যম।

— মাইকেল ব্রাউন 20

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

— Žড্রালো

Answer 6

দুজনেই কর :

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

Answer 7

কনফিগারেশন নিয়ন্ত্রণের অধীনে উত্স ফাইলগুলিতে কোনও আনুষ্ঠানিক পর্যালোচনা করা উচিত এবং ফাইলটির পুনর্বিবেচনাকে পরিষ্কারভাবে উল্লেখ করে পর্যালোচনা রেকর্ড করা উচিত।

এটি কোনও "আপনি সর্বশেষ ফাইলটি" টাইপ যুক্তিগুলি এড়াতে পারবেন না এবং নিশ্চিত করে যে প্রত্যেকে সোর্স কোডের একই অনুলিপিটি পর্যালোচনা করছে।

এর অর্থ হ'ল, যদি কোনও পর্যালোচনা-পরবর্তী সংশোধন করা দরকার, ইতিহাসটি সেই সত্য দিয়ে বর্নিত হতে পারে।

Answer 8

কোড পুনর্বিবেচনার জন্য, আমার ভোট কমিটের 'সময়কালের' জন্য।

জারিত বা ক্লোভারের মতো একটি সিস্টেম (আমি মনে করি) একটি পরিবর্তন আনতে পারে এবং তারপরে পর্যালোচক যদি এটি ভাল হয় তবে উত্স নিয়ন্ত্রণে (গিটকে ঠেলাও) এটি প্রতিশ্রুতিবদ্ধ করতে পারেন। এটি উভয় বিশ্বের সেরা।

যদি এটি ব্যবহারিক না হয়, তবে আমি মনে করি যে প্রতিশ্রুতি দেওয়ার পরে সবচেয়ে ভাল আপস। যদি নকশাটি ভাল হয় তবে কেবলমাত্র সবচেয়ে জুনিয়র বিকাশকারীদের এমন জিনিসগুলি খারাপ হওয়া উচিত যা আপনি তাদের প্রতিশ্রুতিবদ্ধ করতে চান না। (তাদের জন্য একটি প্রাক-প্রতিশ্রুতি পর্যালোচনা করুন)।

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

Answer 9

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

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

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

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

Answer 10

পর্যালোচনাগুলি প্রাক-পূর্ববর্তী এবং উভয়ই সমাহার থেকে উপকার করে।

প্রাক-পর্যালোচনা প্রতিশ্রুতিবদ্ধ

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

পর্যালোচনা চলাকালীন কোনও চলমান কমিটি নেই

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

পর্যালোচনা পোস্ট করুন

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

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

পোস্ট-রিভিউ কমিট

• মডারেটর এবং অন্যান্য পর্যালোচকদের প্রাক-পর্যালোচনা কমিটের তুলনায় একটি ডেটা পয়েন্ট দেয়।
• ত্রুটি অপসারণ এবং কোড উন্নতিতে পর্যালোচনাটির মান এবং সাফল্য উভয় বিচার করার জন্য মেট্রিক সরবরাহ করে।

Answer 11

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

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

Answer 12

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

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

এগুলি থেকে আমরা নিম্নলিখিত তাত্ত্বিক নিয়মগুলি পেয়েছি:

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

সম্পূর্ণ গবেষণা পত্রটি এখানে পাওয়া যায়: http://dx.doi.org/10.1145/2904354.2904362 বা আমার ওয়েবসাইটে: http://tobias-baum.de

Comments

এই মডেলটি কি কোনও বাস্তব বিশ্বের ডেটা দিয়ে যাচাই করা হয়েছে?

— পিটার

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

— টোবিয়াস বি।

ধন্যবাদ, এটি উত্তরটিকে দৃষ্টিভঙ্গিতে রাখে এবং এভাবে এটিকে আরও মূল্যবান করে তোলে। +1

— পিটার

Answer 13

আমার মতে, কোড পিয়ার পর্যালোচনা পোস্ট-কমিট হয়ে গেলে সবচেয়ে ভাল কাজ করে।

আমি আপনার শাখা কৌশলটি সামঞ্জস্য করার সুপারিশ করব। বিকাশকারী শাখা বা বৈশিষ্ট্য শাখা ব্যবহার করে বেশ কয়েকটি সুবিধা রয়েছে ... যার মধ্যে কমপক্ষে কমিট পোস্টের পর্যালোচনাগুলির সুবিধাদি করা সহজ নয়।

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

http://www.atlassian.com/software/crucible/overview

ব্যবহারকারী / বৈশিষ্ট্য শাখার কিছু অন্যান্য সুবিধা:

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

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

Comments

ক্রুসিবল চমত্কার, এবং এটি শুরু করতে কেবল ব্যয় হয় 10 ডলার। (যদিও $ 10 সংস্করণ মাত্র 5 ভান্ডার পরিচালনা করবে, যার মানে আপনি এটি দ্রুত কাটিয়ে ওঠা পারে, এবং সেখান থেকে পরবর্তী ধাপে আপ অনেক বেশি ব্যয়বহুল $ 1k IIRC ভালো কিছু।।)

— মার্ক ই Haase

Answer 14

উভয়। (ধরনের।)

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

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

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

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

Answer 15

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

Answer 16

কোডের বড় অংশগুলি সম্পন্ন হওয়ার আগে, চেক ইন (বন্ধু চেক) কোড কোড পর্যালোচনা তাত্ক্ষণিক প্রতিক্রিয়া।

চেক ইন কোড পর্যালোচনার অসুবিধা হ'ল এটি দীর্ঘ প্রসারিত কোড সম্পন্ন না হওয়া পর্যন্ত লোককে চেক ইন করা থেকে নিরুৎসাহিত করতে পারে। যদি এটি হয় তবে এটি সুবিধার সম্পূর্ণরূপে উপেক্ষা করে।

এটিকে কী আরও কঠিন করে তোলে তা হ'ল প্রতিটি বিকাশকারী এক নয়। সহজ সমাধানগুলি সমস্ত প্রোগ্রামারদের জন্য কাজ করে না । সহজ সমাধানগুলি হ'ল:

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

• বিকাশকারী শাখা, কোড কেবল পর্যালোচনা করা হয় এবং শেষ হয়ে গেলে মূল শাখায় চেক করা হয়। কিছু বিকাশকারী গোপনীয়তার সাথে কাজ করার ঝুঁকিপূর্ণ হয় এবং এক সপ্তাহ পরে তারা এমন কিছু কোড নিয়ে আসে যা পূর্বে চিহ্নিত হতে পারে এমন মৌলিক সমস্যার কারণে পর্যালোচনা পাস করতে পারে বা নাও পারে।

• প্রতিটি চেক ইন উপর পর্যালোচনা, যা ঘন ঘন পর্যালোচনা গ্যারান্টি দেয়। কিছু বিকাশকারী ভুলে যায় এবং খুব ঘন ঘন চেক ইনগুলিতে নির্ভর করে যার অর্থ অন্যদের প্রতি 15 মিনিটে কোড রিভিউ করতে হয়।

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

অনুশীলনে, আপনি একইসাথে আরও সহজ এবং আরও জটিল করে এই কাজটি করেন। আপনি সহজ নির্দেশিকা নির্ধারণ করেছেন, এবং প্রতিটি বিকাশকারী দলকে এই নির্দেশিকাগুলি অনুসরণ করতে তাদের কী করা দরকার তা একটি দল হিসাবে চিহ্নিত করতে দিন। এই ধরণের নির্দেশিকাগুলির একটি উদাহরণ:

• কাজের ক্ষেত্রে এক দিনের কম সময় নেওয়া উচিত in
• কোড (যদি থাকে তবে) চেক ইন না করা থাকলে কোনও কাজ শেষ হয় না।
• কোড (যদি থাকে তবে) পর্যালোচনা না করা থাকলে কোনও কাজ শেষ হয় না।

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

Answer 17

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

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

Answer 18

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

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

Answer 19

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

মানুষকে স্বয়ংক্রিয় প্রক্রিয়াগুলির সাথে জড়িত হওয়া কেবল অপচয় নয়।

Comments

দুর্ভাগ্যক্রমে, প্রশ্নটি ছিল আগে বা পরে পর্যালোচনাগুলি করা উচিত - সেগুলি করা বা করা উচিত নয়। যদি আপনার আগে / পরে সম্পর্কে মতামত থাকে তবে দয়া করে এটি যুক্ত করুন।

— মার্কো