আপনার সেরা প্রোগ্রামারদের কি অন্যদের কোড উত্স নিয়ন্ত্রণে পরীক্ষা করা উচিত?


29

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

এই প্রশ্নটি কোথাও কোনও সংস্থায় একটি দলের জন্য কেন্দ্রীভূত সংগ্রহস্থল হিসাবে গিট ব্যবহার করার বিষয়ে। ধরে নিন যে দলের সদস্যরা বিভিন্ন স্কিলের স্তরের, বেশিরভাগ সংস্থায় যেভাবে তারা থাকেন।

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


5
"সেরা প্রোগ্রামার" সংজ্ঞায়িত করেন? সেরা কি? নির্বিচারে বিধি অনুসরণ করছেন? কোড ক্র্যাঙ্ক আউট? শূন্য-ত্রুটি কোড লিখছেন?
টিমো গিউশ

3
দুঃখিত, আমি এখনও অনিয়ন্ত্রিত (যেমন- চেকড না হওয়া) কোডটি পর্যালোচনা করার ধারণাটি সম্পর্কে আমার মস্তিষ্ককে পাওয়ার চেষ্টা করছি ... অবশ্যই এসসিএস ব্যবহারের অন্যতম প্রধান সুবিধা হ'ল পর্যালোচনাটি পরিচিত / নিয়ন্ত্রিতের বিরুদ্ধে করা যেতে পারে কোডটির পুনরাবৃত্তি?
অ্যান্ড্রু

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

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

4
আমি বিশ্বাস করি যে এখানে @mattz ঠিক আছে। এটি সম্পূর্ণরূপে গিটের উপর শক্তিশালী ওপেন সোর্স প্রভাবের ফলস্বরূপ যেখানে একটি কোর দেব দল রয়েছে যা রেপোর অবস্থা নিয়ন্ত্রণ করে, তবে অন্যরাও এতে অবদান রাখতে স্বাগত।
স্টিভেন এভার্স 21

উত্তর:


53

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

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

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

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

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


10
+1: এর জন্য ... ভাল প্রোগ্রামাররা যেভাবেই অন্য প্রোগ্রামারদের ভাঙা কোড নিয়ে ডিল করতে প্রচুর সময় ব্যয় করে।
জিম জি।

3
+1 সেরা উত্তর। বিশেষত এটি নির্দেশ করে যে কোনও দেব-বান্ধব বাগটি নেতিবাচকভাবে সকলকে প্রভাবিত করে।
ইভান প্লেস

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

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

40

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

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

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

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


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

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

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

1
@ হুবার্টকারিও - আপনি আমার চেয়ে ভাল জানেন I
তেলস্তিন

5
@ টেলাস্টিন আমি জানি না যে আমি আপনার উত্তরটি আমার মতো আক্ষরিক অর্থে ব্যাখ্যা করার কথা বলছি কিনা তবে এর অন্য দিকটি হ'ল টীকা / দোষ ইতিহাস সব ভুল হবে। যদি আপনি এমন কোনও কোড খুঁজে পেয়েছেন যা আপনি বুঝতে পারেন নি, তবে আপনি যে পর্যালোচনাটি লিখেছিলেন তা জিজ্ঞাসা করবেন, প্রোগ্রামার যিনি এটি লিখেছেন তা নয়।
ড্যানিয়েল কাপলান

28

না। কারও প্রতিশ্রুতিবদ্ধ হওয়া উচিত।

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

আর একটি দুর্দান্ত জিনিসকে ইউনিট টেস্ট বলা হয়;)

যদিও বিকল্প আছে।

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

খ) বিবর্তন এবং অনুরূপভাবে আপনি এমন শাখা ব্যবহার করতে পারেন যেখানে প্রতিটি দেবকে প্রধান শাখায় প্রবেশের জন্য প্যাচ তৈরি করতে হয়।


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

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

2
ইউনিট পরীক্ষাগুলি ইউনিট কোড হিসাবে একই <আপনার পছন্দের 4 টি অক্ষর এখানে সন্নিবেশ করান) দ্বারা লিখিত থাকলে সহায়তা করে না।
অট--

@ ব্রায়ানকনোব্লাচ: যে কেউ তর্ক করতে পারে যে এর বিপরীতটিও সত্য। আদর্শভাবে, আপনার উভয় থাকা উচিত।
ডক ব্রাউন

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

8

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

যদি তারা খুশি না হন তবে তারা কোডের একটি লাইনের পাশে মন্তব্যগুলি রাখতে পারবেন, আপডেট প্যাচ ইত্যাদি চাইতে পারেন

এইভাবে কোনও পরিবর্তন মুলতুবি থাকা যে কেউ এটি প্রস্তুত হওয়ার সাথে সাথেই তা বের করে আনতে পারবেন এবং কেবলমাত্র যোগ্য ব্যক্তিরা (জেরিটের সঠিক +2 সুবিধাসমূহের সাথে) এই কোডটি পরীক্ষার জন্য এবং পরবর্তীকালে উত্পাদনে চাপ দিতে সক্ষম হবেন।


2
আমরা বড় সাফল্যের সাথে জীবাণু ব্যবহার করি। প্রতিটি ইস্যু সমাধান করে ওপিতে একটি সমস্যা আছে এমনকি কিছু কিছু এমনকি তিনি জানেন না যে তার কী আছে।
mattnz

8

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

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

  1. কিছুই নয় - আপনি কোডটি পরীক্ষা করে নেওয়ার আগে আমি প্রতিটি লাইন দেখতে চাই।
  2. কিছু - আপনি কী করছেন তা আমাকে জানান এবং আমি প্রতিক্রিয়া জানাব
  3. সর্বাধিক - আপনার কাজটি করতে যান এবং যখন প্রয়োজন হয় কেবল তখনই সাহায্য চান।

আপনার প্রতিভা মুক্ত করার সুবিধা:

  • নকশায় ফোকাস করুন
  • কোডিং মান এবং প্রয়োগের কৌশল স্থাপনে জড়িত (ম্যানুয়ালি এগুলি নিজেরাই না করে)
  • শক্ত কোডিং সমস্যাগুলি মোকাবেলা করুন
  • পরামর্শদাতা সরবরাহ করুন (কোডের প্রতিটি লাইনের অনুমোদন ছাড়াই)

এমন একটি বিকাশকারীদের পরিচালনা পন্থায় আগ্রহী যারা সারা দিন কোড না দেওয়া পছন্দ করতে পারেন; অন্যকে ছেড়ে দাও


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

5

পর্যালোচনা মূল্য উত্পাদনশীল হিট?

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

যদি ভুল হয়ে থাকে তবে উত্পাদনশীলতা হিট অবশ্যই পর্যালোচনার কোনও সুবিধা হ্রাস করবে; উত্তরটি যদিও পর্যালোচনাগুলির ধারণা বাদ দেয় না তবে এটি সঠিকভাবে কীভাবে করা যায় তা খুঁজে বের করার জন্য

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


যদি দলের "সেরা" প্রোগ্রামাররা ক্রেপি কোডারদের দ্বারা উত্পাদিত বোধগম্য আবর্জনা দিয়ে খনন করতে ঘন্টা ব্যয় করতে বাধ্য হয়, তবে সমাধানটি হ'ল ক্রেপ প্রস্তুতকারীদের, ভিসিএস প্রযুক্তির কাছে আবেদন করার জন্য নয় fire

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

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


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

  • - ওহ এই পরিবর্তনের একীকরণ অনেক বিলম্বিত হয়েছিল কারণ পর্যালোচক হঠাৎ অসুস্থ হয়ে পড়েছিলেন, কী দুর্ভাগ্য।
    - হ্যালো! হেল-লো-ওও, আপনি কি কখনও এরকম ক্ষেত্রে মোকাবেলা করার জন্য ব্যাকআপ রিভিউর থাকার কথা ভেবেছিলেন ?

4

হ্যাঁ। তবে আপনি যদি বিতরণ উত্স নিয়ন্ত্রণের কথা বলছেন তবেই। কেন্দ্রীভূত - এটি নির্ভর করে।

যদি মাত্র কয়েকটি প্রোগ্রামার থাকে তবে এতে খুব কম সময় লাগে। অবশ্যই পরে বাগ এবং প্রযুক্তিগত debtণ অপসারণের জন্য প্রয়োজনীয় হবে এমন ফিক্সগুলির চেয়ে কম।

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

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


2

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

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

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


0

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

ব্যক্তিগতভাবে, আমি যদি অন্য লোকের কোড পরীক্ষা করে দেখতে পারি তবে আমি খুব ভালই হতাশ হব।

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


0

হ্যাঁ, পর্যালোচনা এটি মূল্যবান। আমি নিশ্চিত না যে যদি নিম্নলিখিত কারণে পর্যালোচনা প্রক্রিয়াটি সমানুপাতিক হয় তবে উত্পাদনশীলতা হিট হয়েছে:

  • এটি প্রোগ্রামারদের সৎ রাখে - যদি আপনি জানেন তবে এটি পর্যালোচনা করা হবে, লোকেরা কম শর্টকাট নেবে
  • এটি নতুন প্রোগ্রামারদের আরও অভিজ্ঞ প্রোগ্রামারদের থেকে শিখতে সহায়তা করে
  • এটি ডোমেন নির্দিষ্ট জ্ঞান স্থানান্তর করতে সহায়তা করে
  • পর্যালোচনা অন্য গেট যেখানে বাগ এবং সম্ভাব্য সমস্যাগুলি খুঁজে পাওয়া ও ঠিক করা যায় fixed

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

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

রিলিজ শাখায় মার্জ করা "সেরা" প্রোগ্রামাররা করতে পারেন, বা পর্যাপ্ত পর্যালোচনা হওয়ার পরে সম্ভাব্য ব্যক্তিরা সম্ভবত আরও কিছু করতে পারেন।


1
-1: এটি প্রোগ্রামারদের সৎ রাখে - আপনি যদি জানেন তবে এটি পর্যালোচনা করা হবে, লোকেরা কম শর্টকাট নেবে। - হুম ... আমি নৈতিক বিপদ প্রবর্তনের বিষয়ে উদ্বিগ্ন। এটি হল, বিকাশকারীরা অলস বা slালু পেতে পারে কারণ তারা জানে যে আরও একজন প্রবীণ বিকাশকারী সর্বদা কোড পর্যালোচনার আকারে তাদের কোডের জন্য দায়িত্ব নেবেন।
জিম জি।

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

-1

যদি তাদের কাজের একটি উল্লেখযোগ্য অংশ অন্য লোকের কোডটি পর্যালোচনা করে থাকে তবে কি ভাল প্রোগ্রামাররা ছেড়ে দেয়?

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

আপনার সেরা প্রোগ্রামারদের কি অন্যদের কোড উত্স নিয়ন্ত্রণে পরীক্ষা করা উচিত?

আসলেই না. এটা কিছু সমালোচনামূলক যুক্তিবিজ্ঞান যা করা প্রয়োজন ছাড়া তাদের সময় নিশ্চিত বর্জ্য জন্য, শিলা-কঠিন অবস্থা

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

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