কীভাবে বিকাশকারীদের সময়মতো কোড রিভিউ করতে হয়


12

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

(আমরা গিট-এসএনএন ব্যবহার করি যাতে আমরা পর্যালোচনার জন্য অপেক্ষা করার সময় কোডিং চালিয়ে যেতে সক্ষম হয়েছি However তবে আমার কোড দেওয়ার আগে যখন দীর্ঘ সময় অপেক্ষা করতে হয়েছিল তখনও আমি হতাশাবোধ করি find)

উত্তর:


12

ফ্যাব্রিকেটর নামে পরিচিত তাদের নিজস্ব অ্যাপ্লিকেশন দিয়ে কীভাবে ফেসবুক এটি করে তা দেখুন: http://phabricator.org/

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

আমার ধারণা এটি এটিকে আরও মজাদার করে তুলেছে।

এছাড়াও, সম্ভবত দুটি লোককে একটি কোড বরাদ্দ করা উচিত: একজন এটি করেন এবং যিনি এটি পর্যালোচনা করেন।

তবে আপনার সতীর্থরা সম্ভবত এই পর্যালোচনাটি বিশ্বাস করেন না।

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

আমি সাধারণত কিছু ছোটখাটো অংশ অপসারণ করেছি, যেমন ব্লক / ফাংশন স্কোপ বন্ধনী, দৃশ্যমানতার নোটেশন, কখনও কখনও এমনকি প্রকারগুলিও, এবং এটি পরিচালকদের, ডোমেন বিশেষজ্ঞ, সাথীদের, যিনি কোডটির অনুরোধ করেছিলেন তাদের কাছে এটি দেখিয়েছি: "আপনি কি চান এটি?"

এছাড়াও, ব্যক্তিগতভাবে সেখানে যাওয়া এবং পর্যালোচনা শেষ না হওয়া পর্যন্ত না যাওয়া সহায়তা করে।

অথবা, যদি আপনি দলের সাথে ভাল না হন, বা তারা আপনার সাথে ভাল না হন, আপনি জানেন, "আপনি যদি 'সংস্থা পরিবর্তন করতে পারেন, সংস্থা পরিবর্তন করতে পারেন" ...


9

আমি এটি কয়েকটি অনুমানের ভিত্তিতে স্থাপন করছি:

  1. প্রত্যেকেই কোড লিখতে চায় বলে মনে হয় (যদি না হয় তবে আপনার এমন লোক আছে যাঁরা যেতে হবে need)
  2. প্রত্যেকে নিজের কোড চেক ইন করতে চায়।

যারা তাদের পর্যালোচনাগুলি সম্পন্ন করেন তাদের কোড চেক ইন করার অনুমতি দিন।

ব্যবস্থার সমস্যাটি এড়ানোর আশায় কোডের রিভিউগুলিতে সময়ের একটি নির্দিষ্ট ব্লক উত্সর্গীকৃত হতে পারে।

লক্ষ্যটি মানের কোডটি পরীক্ষা করা উচিত। আপনি পর্যালোচনাগুলিকে এমন বিন্দুতে শাস্তি / জোর করতে চান না যেখানে প্রত্যেকে একে একে "রাবার স্ট্যাম্প" অনুমোদন দেয়।

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


1

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

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

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

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


1

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

আপনি যদি মিশন সমালোচনামূলক সফটওয়্যার বা প্রোডাকশন রিলিজ প্রার্থী কোডের সমালোচনামূলক প্যাচ না করেন তবে নির্দিষ্ট ধরণের কোড রিভিউগুলির সাথে দৃ rig়তার সাথে দৃ stick়ভাবে আটকে থাকার কোনও বাধ্যতামূলক কারণ নেই।

  • আপনার সংস্থার প্রয়োজনীয়তার পিছনে ধারণাটি কোনও পৃষ্ঠের উপরে যুক্তিসঙ্গত মনে হয় (100% পর্যালোচিত কোড) তবে তারা যে উপায়গুলি ব্যবহার করার সিদ্ধান্ত নিয়েছে তা প্রতিবিজাতীয় - কারণ আপনি উল্লেখ করেছেন যে, বিকাশকারীরা হতাশ হওয়ার দিকে পরিচালিত করে।

আপনার জুতোয় হাঁটাচলা করে, আমি প্রথমে পরিচালনাটিকে নির্দেশ করব যে প্রতিশ্রুতি পোস্টের কোড পর্যালোচনাগুলি পূর্ব-প্রতিশ্রুতি হিসাবে সমানভাবে সম্মানিত বিবেচিত হয়। এই পদগুলি ওয়েবে অনুসন্ধানযোগ্য - যদি প্রয়োজন হয় তবে এটির ব্যাকআপের জন্য রেফারেন্সগুলি সন্ধান করুন। ১০০% পর্যালোচিত কোড পাওয়ার জন্য প্রি-কমিট রিভিউ প্রয়োজন হয় না ।

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


1
"যদি সংস্থা প্রোগ্রামারদের চেয়ে সংস্থা জানে তবে তারা কোডটি কেন নিজেরাই লিখবে না?": খুব ভাল মন্তব্য! তবে আমি আশা করব যে উন্নয়ন ব্যবস্থাপকরা নিজেরাই সাবেক বিকাশকারী are
জর্জিও

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

@ আডাম আপনার অভিজ্ঞতাটি অবশ্যই আমার থেকে পৃথক - কেবলমাত্র পোস্ট-কমিটের ক্ষেত্রে নয়, তবে (এবং বিশেষত) "প্রোগ্রামাররা অলস ..." এর আর্ট অংশটিও আমি বাস্তবসম্মত চিত্রের পরিচালকদের পক্ষে সম্মত যে বিষয়টি সাধারণত ছিল আমার দল; এটি শুধুমাত্র পরিচালকদের আমি কাজ কি ধরনের পর্যালোচনা বল সম্পর্কে অচেতন ধারণা সঙ্গে ব্যবহার নেতৃত্বে করা হয়নি
মশা

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

1

আপনার সমাধানের জন্য বেশ কয়েকটি সমস্যা রয়েছে - আপনাকে হৃদয় ও মন জয় করতে হবে এবং আপনাকে কোড পর্যালোচনার জন্য সময়টি উপলভ্য তা নিশ্চিত করতে হবে।

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

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

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

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


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

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

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

@ স্টেভ জেসোপ অবশ্যই আপনি সত্যই তাতে একমত হতে পারেন। এবং অবশ্যই ব্যতিক্রম হতে চলেছে (আমি মনে করি স্ক্রাম পর্যবেক্ষণটি নির্বোধ যদিও - বিশেষত উত্তরটি সুস্পষ্ট হিসাবে (-:)। আমি মনে করি মূলটি হ'ল "এক আকার সব সমাধান ফিট করে" আমি কেবল সহজ এবং সহজেই বোঝার জন্য এমন কোনও প্রস্তাব দেওয়া হয়েছে যা তার সময়সূচী (আবার পরিবেশের উপর নির্ভর করে) বাম্প করা তুলনামূলকভাবে শক্ত
মারফ

1

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


0

রিভিউ বোর্ডের মতো একটি সরঞ্জাম ব্যবহার করার বিষয়ে বিবেচনা করুন । এটি খুব সহায়ক, বিশেষত দীর্ঘ পর্যালোচনার জন্য।

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


0

যোগ করার জন্য কয়েকটি পয়েন্ট অন্য উত্তরগুলিতে নয়।

পর্যালোচনা করার কোডটি অবশ্যই চেক ইন করতে হবে

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

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

কোড রিভিউগুলি কখন এবং কীভাবে করা যায় তা আরও শক্ত প্রশ্ন।

একটি নিয়ম যা আমাদের জন্য সেই সময়ের জন্য কাজ করেছে তা হল ভাগ করা কোডটি অবশ্যই পর্যালোচনা করতে হবে কারণ এর একক প্রয়োগের কোডে (বিশেষত প্রদত্ত আমরা টেস্ট চালিত বিকাশ ব্যবহার করছি) এর কম গুরুত্বপূর্ণ code

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