চতুর অভ্যাস: কোড পর্যালোচনা - পর্যালোচনা ব্যর্থ বা একটি সমস্যা উত্থাপন?

Question

2 সপ্তাহের স্প্রিন্টের শেষে এবং একটি কার্যটির একটি কোড পর্যালোচনা থাকে, পর্যালোচনায় আমরা একটি ফাংশন আবিষ্কার করি যা কাজ করে, পাঠযোগ্য, তবে এটি বেশ দীর্ঘ এবং এতে কয়েকটি কোডের গন্ধ রয়েছে। সহজ রিফ্যাক্টর কাজ।

অন্যথায় টাস্ক সম্পন্ন সংজ্ঞা ফিট করে।

আমাদের দুটি পছন্দ আছে।

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

আমার প্রশ্ন হ'ল: কোনও পর্যালোচনা পিছনে টিকিট ব্যর্থ করার পরিবর্তে টিকিট বাড়াতে কোনও সহজাত সমস্যা বা বিবেচনা আছে কি?

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

Comments

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

— VLAZ

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

— জোশ পার্ট

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

— VLAZ

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

— সেপ্টেম্বর

@ ভ্লাজ আপনার মন্তব্য থেকে একটি উত্তর দেওয়া উচিত

— ইস্টার

Answer 1

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

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

পর্যালোচনাতে আমরা একটি ফাংশন আবিষ্কার করি

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

আপনি যেখানে লাইনটি আঁকবেন, যদি আপনি ইতিমধ্যে এটি আঁকেন না তবে? আপনি স্পষ্টভাবে মনে করেন না যে এই কোডটি তার বর্তমান ফর্মের কোডবেজে থাকার জন্য যথেষ্ট পরিচ্ছন্ন; তাহলে আপনি কেন টিকিটকে পাস দেওয়ার বিষয়ে বিবেচনা করবেন?

কোড পর্যালোচনা ব্যর্থ করুন, যাতে টিকিটটি এই স্প্রিন্টে বন্ধ না হয় এবং আমরা মনোবলকে একটু আঘাত করি, কারণ আমরা টিকিটটি পাস করতে পারি না।

আমার কাছে মনে হচ্ছে আপনি অপ্রত্যক্ষভাবে বিতর্ক করছেন যে আপনি এই টিকিটটি কোডবেজের মান উপকারের পরিবর্তে দলের মনোবল উপকারের জন্য একটি পাস দেওয়ার চেষ্টা করছেন।

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

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

যদি মূল টিকিট প্রয়োগের ফলে কোডটির গন্ধ হয়, তবে এটি মূল টিকিটে সম্বোধন করা উচিত। আপনার কেবলমাত্র নতুন টিকিট তৈরি করা উচিত যদি কোড গন্ধটি সরাসরি মূল টিকিটে দায়ী করা যায় না (উদাহরণস্বরূপ, "উটের পিঠে ভেঙে যাওয়া খড়" দৃশ্যে)।

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

পাস / ব্যর্থতা সহজাতভাবে একটি বাইনারি অবস্থা , যা সহজাতভাবে সমস্ত বা কিছুই নয়।

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

কোডটি নিষ্কলুষ হওয়া উচিত নয়, এটি আপনার দল / সংস্থার দ্বারা নিযুক্ত পরিষ্কার-পরিচ্ছন্নতার যুক্তিসঙ্গত মান মেনে চলতে হবে। এই মানটি মেনে চলা একটি বাইনারি পছন্দ: এটি মেনে চলা (পাস) বা এটি (ব্যর্থ) হয় না।

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

অন্যথায় টাস্ক সম্পন্ন সংজ্ঞা ফিট করে।

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

Comments

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

— গ্রেগ বার্গার্ড্ট

দুর্দান্ত উত্তর - দৃ but় কিন্তু অভদ্র না। একটি স্পর্শকাতর বিন্দুটি এও হতে পারে: স্প্রিন্টে এত দেরিতে আমরা কোড পর্যালোচনাগুলি কীভাবে পেলাম যে পুরো স্প্রিন্টকে ব্যর্থ করে না দিয়ে একটি সহজে রিফেক্টরটি করা যায় না?

— ড্যানিয়েল

@ ড্যানিয়েল: বিকাশকারী অন্যথায় জড়িত থাকতে পারে, বা এটি কোনও পরিকল্পনার সমস্যা হতে পারে। কোনও কাজ শেষ করার এবং স্প্রিন্ট শেষ করার মধ্যে সময়টি সাধারণত ন্যূনতম হয় কারণ (আদর্শ বিশ্বের) লোকেরা স্প্রিন্টের সমাপ্তির সময়টির প্রায় শেষের দিকে স্প্রিন্টের শেষ কাজটি শেষ করবে। পর্যালোচনা / স্থির করতে আপনি কোনও বর্ধিত সময় নিতে পারবেন না; অথবা বিকল্পভাবে, সম্ভবত বিকাশকারী স্প্রিন্টের বাকি অংশের জন্য সহজভাবে উপস্থিত / উপলব্ধ নয়।

— ফ্ল্যাটার

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

— jpmc26

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

— তোলা

Answer 2

2 সপ্তাহের স্প্রিন্ট এবং একটি কার্য শেষে একটি কোড পর্যালোচনা আছে [...] সহজ রিফ্যাক্টর কাজ।

কেন স্প্রিন্ট শেষে পপ আপ? একটি কোড পর্যালোচনা কোডটি সম্পন্ন হওয়ার সাথে সাথেই হবে (বা এর আগেও)। আপনার সমাপ্ত প্রতিটি গল্পের সাথে আপনার সংজ্ঞাটি পরীক্ষা করা উচিত।

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

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

Comments

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

— ড্যানিয়েল প্রাইডেন

Answer 3

সাধারণ: আপনি পরিবর্তনটি পর্যালোচনা করুন । আপনি অন্যথায় প্রোগ্রামের অবস্থা পর্যালোচনা করবেন না। যদি আমি 3,000 লাইনের কার্যক্রমে কোনও বাগ ঠিক করি তবে আপনি পরীক্ষা করে দেখুন যে আমার পরিবর্তনগুলি বাগটি ঠিক করে দেয় এবং এটিই। এবং যদি আমার পরিবর্তনটি বাগটি ঠিক করে দেয় তবে আপনি পরিবর্তনটি গ্রহণ করুন।

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

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

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

Comments

আমি এই ক্ষেত্রে পরিবর্তন মনে ছিল মাত্রাতিরিক্ত দীর্ঘ ফাংশন - আপনি একটি 3000 লাইন ফাংশন যে পূর্বে ছিল না (বা পূর্বে 10 লাইন ফাংশন ছিল না) এনেছি।

— ব্যবহারকারী 3067860

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

— ডঙ্ক

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

— ফ্রেস 14

@ ব্যবহারকারী 3067860 আপনি যদি 10 লাইন ফাংশনটিকে 3000 লাইনের ফাংশনে পরিণত করেন - তবে স্পষ্টভাবে ব্যর্থ। যদি আপনি কোনও 3000 লাইনের ক্রিয়াটি 3010 এ পরিণত করেন - তবে সম্ভবত পাস করুন। তবে আপনি যদি 100 লাইনের ফাংশনটি (সাধারণত কিছুটা খুব বড়) 300 লাইনের ফাংশনে পরিণত করেন ( অবশ্যই খুব বড়)?

— মার্টিন বোনার 24:58

Answer 4

কোড পর্যালোচনা ব্যর্থ করুন, যাতে টিকিটটি এই স্প্রিন্টে বন্ধ না হয় এবং আমরা মনোবলকে একটু আঘাত করি, কারণ আমরা টিকিটটি পাস করতে পারি না।

এই সমস্যা মনে হচ্ছে।
তাত্ত্বিকভাবে আপনি জানেন যে আপনার কী করা উচিত, তবে এটি সময়সীমার কাছাকাছি যাতে আপনি যা করতে চান তা আপনি করতে চান না।

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

Comments

"প্রিয় গ্রাহক আপনার আরও ২-৩ সপ্তাহের জন্য আপনার বৈশিষ্ট্যটি রাখতে পারবেন না কারণ আমাদের কোডটি কার্যকর হয়েছিল তবে এটি কীভাবে দেখায় তা আমরা পছন্দ করি না", ... দয়া করে আমাদের প্রতিযোগীর কাছে যান না ... বা সিইওকে বলুন !

— র্যান্ডম ইউএস 1 ই

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

— VLAZ

@ র্যান্ডম ইউএস 1 আর: "" প্রিয় বিকাশকারী, বৈশিষ্ট্যটি কেন সম্পন্ন করা হয়নি? " - উত্তরটি" হওয়া উচিত কারণ আমাদের কাছে এটি একটি মানের কাছে একটি গ্রহণযোগ্য পর্যায়ে তৈরি করার পর্যাপ্ত সময় ছিল না ", সম্ভবত " আমরা এটি দিতে পারি " আপনি যদি মানের সাথে আপস করতে রাজি হন "

— ব্রায়ান ওকলে

@ র্যান্ডম ইউএস 1 আর তাই মূলত আপনি কোডের মানটি ত্যাগ করতে চান এখন সম্ভবত বৈশিষ্ট্যগুলি পরে প্রয়োগ করা আরও শক্ত হয়ে উঠবে। একটি 2 দিনের ফিক্স এখন আপনাকে 4 সপ্তাহের ফিক্সটি খুব ভালভাবে বাঁচাতে পারে। তাহলে এটি "প্রিয় গ্রাহক, আপনি আরও ২-৩ সপ্তাহের জন্য আপনার বৈশিষ্ট্যটি রাখতে পারবেন না কারণ এখন একটি ছোটখাট বৈশিষ্ট্যটি প্রয়োগ করতে এত বেশি সময় লাগে"। এছাড়াও এটি একটি স্প্রিন্টের শেষ বা এটি একটি বড় সময়সীমা? এটি যদি একটি বড় সময়সীমা থাকে তবে আমি এখনই মার্জ হতে দেখতে পেলাম, পরের 2 দিনের মধ্যে একটি ফিক্স লিখে এবং সময়সীমার ঠিক পরে পিআর বাড়াতে চাই।

— xyious

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

— xyious

Answer 5

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

কোড পর্যালোচনা সম্পর্কিত সমস্যাগুলির ক্ষেত্রে, আপনি এটি পরিচালনা করতে পারেন এমন কয়েকটি উপায় রয়েছে এবং সঠিক পছন্দটি কয়েকটি কারণের উপর নির্ভর করে।

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

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

Answer 6

কোড পর্যালোচনার সমস্যাগুলি বঞ্চিতকরণের সাথে অন্তর্নিহিত সমস্যা নেই তবে এটি একটি দল হিসাবে আপনাকে সম্মত করা দরকার এমন মূল সমস্যাগুলির মতো মনে হচ্ছে:

1. আপনার কোড পর্যালোচনার উদ্দেশ্য কী?
2. কোড পর্যালোচনার ফলাফল কীভাবে কোনও কাজের আইটেমের জন্য সম্পন্ন সংজ্ঞা দিয়ে সম্পর্কিত?
3. কোড পর্যালোচনা যদি কোনও গেইটিং টেস্ট হিসাবে প্রয়োগ হয়, তবে কোন সমস্যাগুলি 'ব্লকার' হিসাবে গণ্য হবে?

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

এটি ইউনিট পরীক্ষার সময় ইউনিট পরীক্ষা ব্যর্থ হওয়ার মতোই। ইউনিট পরীক্ষা পাস করা সম্পন্ন হওয়ার প্রয়োজনীয়তা থাকলে আপনি বাগটি ঠিক করতে পারবেন, ইউনিট পরীক্ষা উপেক্ষা করবেন না।

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

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

Answer 7

এখানে উচ্চ-ভোট প্রাপ্ত উত্তরগুলি খুব ভাল; এটি একটি রিফ্যাক্টরিং কোণে সম্বোধন করে।

বেশিরভাগ ক্ষেত্রে, রিফ্যাক্টরিংয়ের সময় বেশিরভাগ কাজ বিদ্যমান কোডটি বোঝা হয়; এর পরে এটি পরিবর্তন করা সাধারণত দুটি কারণে যে কোনও একটি কারণে কাজের ছোট্ট অংশ:

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

2. একটি নতুন বৈশিষ্ট্য তৈরি করা আপনার আরও সহজ করার জন্য আপনার ইতিমধ্যে একটি নির্দিষ্ট নকশা বা কাঠামো মনে রয়েছে। সেক্ষেত্রে সেই নকশা তৈরির কাজটি গল্পটির অংশ ছিল যা এর প্রয়োজনীয়তা তৈরি করেছিল; এটি আপনার স্বাধীন এটি সেই নকশায় উঠতে রিফ্যাক্টরিং করা দরকার।

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

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

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

এই ক্ষেত্রে আপনি রিফ্যাক্টরিংয়ের জন্য একটি পৃথক গল্প তৈরি করার কথা ভাবছেন তা বেশ কয়েকটি ফ্রন্টের একটি সতর্কতা চিহ্ন:

1. আপনি কোডিংয়ের অংশ হিসাবে রিফ্যাক্টরিংয়ের কথা ভাবছেন না তবে একটি পৃথক অপারেশন হিসাবে, যার ফলে এটি চাপের মধ্যে পড়ে যাওয়ার সম্ভাবনা তৈরি করে।

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

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

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

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

Answer 8

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

আপনার প্রশ্নটি স্পষ্টভাবে "চতুর অনুশীলনগুলিতে" আহ্বান জানায় তাই আসুন চতুর ইশতেহারটি পুনরায় দেখা যাক (আমার উপর চাপ দেওয়া):

আমরা সফ্টওয়্যারটি তৈরি করে এবং অন্যকে এটি করতে সহায়তা করে উন্নত করার আরও ভাল উপায় উদ্ঘাটিত করছি। এই কাজের মাধ্যমে আমরা মূল্যবান হয়েছি:

• প্রক্রিয়া এবং সরঞ্জামগুলির উপর ব্যক্তি এবং ইন্টারঅ্যাকশন
• বিস্তৃত ডকুমেন্টেশন ওভার সফ্টওয়্যার
• চুক্তি সমঝোতার উপর গ্রাহকের সহযোগিতা
• একটি পরিকল্পনা অনুসরণ করে পরিবর্তন সাড়া

এটি হ'ল ডানদিকে থাকা আইটেমগুলিতে মান থাকা সত্ত্বেও আমরা বামদিকে থাকা আইটেমগুলিকে আরও মূল্যবান করি।

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

সহযোগিতা শুরু করুন। ব্যর্থ কোডের পর্যালোচনা বন্ধ করুন।

Comments

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

— এরদরিক আয়রনরোজ

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

— পিপীলিকা

Answer 9

পর্যালোচনাতে আমরা একটি ফাংশন আবিষ্কার করি যা কাজ করে, পাঠযোগ্য, তবে এটি বেশ দীর্ঘ এবং এতে কয়েকটি কোডের গন্ধ রয়েছে ...

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

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

আমাদের যে বক্তব্য রয়েছে তার মধ্যে একটি হ'ল "মুলতবি পূর্ণতার চেয়ে অগ্রগতিমূলক উন্নতি চয়ন করুন"।

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

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

Answer 10

আমার মতে এই সমস্যাটি দেখার জন্য দুটি উপায় রয়েছে:

1. একাডেমিক উপায়
2. আসল বিশ্বের উপায়

একাডেমিকভাবে বলতে গেলে, কোড মানের মান পূরণ না হলে বেশিরভাগ কোড পর্যালোচনা প্রক্রিয়াগুলি একটি পিবিআই (পণ্য ব্যাকলগ আইটেম) মোতায়েন করতে ব্যর্থ হয়ে থাকে exist

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

Comments

আসল বিশ্বের কেউ টি - তে চটপটে অনুসরণ করে না - যদি আমাদের খুব কড়া নিয়ম থাকে, তাই না এটি "চতুর" হবে না?

— পাওলো ইবারম্যান

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

— VLAZ

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

— কর্ট জে সাম্পসন

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

— র্যান্ডম ইউএস 1 ই

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

— কর্ট জে সাম্পসন

Answer 11

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

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

1. "ফাংশনটি বেশ দীর্ঘ"। লিখুন: ফাংশনগুলি অবশ্যই এক্স লাইনের চেয়ে কম দীর্ঘ হতে হবে (আমি প্রস্তাব দিচ্ছি না যে কার্যের দৈর্ঘ্য সম্পর্কে নিয়মগুলি ভাল জিনিস)।

2. "কিছু কোডের গন্ধ আছে"। লিখুন: পাবলিক ফাংশনগুলির কার্যকারিতা এবং পারফরম্যান্সের জন্য ইউনিট পরীক্ষা থাকতে হবে, সিপিইউ এবং মেমরির ব্যবহার উভয়ই x এবং y এর মধ্যে থাকতে হবে।

আপনি যদি কোনও কোড পর্যালোচনা পাস করার জন্য বিধিগুলি মাপ দিতে না পারেন তবে মূলত 'আপনার পছন্দ নয় এমন কোড' যা রয়েছে তা আপনি পেয়ে যাবেন।

আপনি 'কোড পছন্দ না' ব্যর্থ করা উচিত? আমি বলব না। আপনি নন-কোড দিকের ভিত্তিতে স্বাভাবিকভাবেই পাস / ব্যর্থ হতে শুরু করবেন: আপনি কি সেই ব্যক্তিকে পছন্দ করেন? তারা কি তাদের মামলার জন্য দৃ strongly়তার সাথে তর্ক করে বা ঠিক যেমন বলা হয় তেমন করে? যখন তারা আপনাকে পর্যালোচনা করে তখন তারা কি আপনার কোডটি পাস করে?

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

আর কতক্ষণ যুক্ত হবে? একই পর্যালোচক পরবর্তী কোড পর্যালোচনা এবং প্রথম পর্যালোচকের সাথে সম্মত হবে বা তারা অতিরিক্ত পরিবর্তনগুলি খুঁজে পাবে? আমি যদি দ্বিতীয় মতামত সন্ধানের জন্য বা মামলার তর্ক করার সময় পরিবর্তনের সাথে একমত নই এবং তা করা বন্ধ রাখি তবে কী হবে?

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

Re: নিয়ম গুলো লেখা অসম্ভব !!

এটি আসলে এতটা কঠিন নয়। আপনার সত্যিকারের অর্থ "'ভাল' কোড দ্বারা আমি যা বোঝাতে চাইছি তা প্রকাশ করতে পারছি না" । একবার আপনি এটি শনাক্ত করার পরে, আপনি যদি দেখতে শুরু করেন যে কারও কাজটি স্ক্র্যাচ করার মতো নয় তবে আপনি কেন এটি বলতে পারবেন না এটি অবশ্যই এইচআর সমস্যা।

আপনি যে নিয়মগুলি করতে পারেন তা লিখুন এবং কোডটি কী 'ভাল' করে তোলে সে সম্পর্কে বিয়ারের সাথে আলোচনা করুন।

Comments

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

— ফ্ল্যাটার

"ফাংশনগুলি অবশ্যই এক্স লাইনের চেয়ে কম লম্বা হওয়া উচিত" এর মতো অসম্পূর্ণতা উত্তর নয়।

— 23:38

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

— ম্যাট মেসারস্মিত

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

— ব্যবহারকারী 3067860

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

— গ্রাহাম