আমি কীভাবে কোনও সম্ভাব্য প্রান্তের মামলা সম্পর্কিত কোনও কোড পর্যালোচনায় দ্বিমত পরিচালনা করব?


188

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

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

আমি একটি উদাহরণ প্রদান করব:

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

আমার আগে কখনও কোড পর্যালোচনা হয়নি এবং আমি নিশ্চিত নই যে আমি খুব যুক্তিযুক্ত হয়েছি কিনা; আমি কি শুধু চুপ করে থাকি এবং সে যা বলে? আমি সিদ্ধান্ত নিলাম যে আমার মাথা নিচু করে রাখা এবং কেবল পরিবর্তন করা সত্ত্বেও যদিও আমি দৃ .়ভাবে একমত নই যে এটি সময়ের সদ্ব্যবহার was


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

আমি অনুভব করি যে আমি যে উত্তরটি বেছে নিয়েছি তা জুনিয়াল বিকাশকারী কীভাবে কোনও কোড পর্যালোচনায় দ্বিমত সামাল দিতে পারে তা বোঝানোর এই মানদণ্ডে পূরণ করে।


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

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

38
@ সোনামান পয়েন্ট কোড রিভিউগুলিতে আরও কিছু অংশ হ'ল সেই একক-মিলিয়ন ত্রুটিগুলি যা ইউনিট পরীক্ষাগুলি এবং এমনকি এলোমেলোভাবে পরীক্ষা / ফাজিং খুঁজে পায় না তা ধরা catch
ডেরেক এলকিনস

11
এটা মনে রাখার মতো যে কোডের পর্যালোচনাগুলি কেবল সমস্যাগুলি ধরার জন্য নয় তবে তারা কীভাবে আরও ভাল করতে সক্ষম হতে পারে সেজন্য তাদের শেখার সুযোগ হিসাবে বিবেচনা করুন learn
স্টিভ বার্নস

72
আরে @ ক্লিক, মনে হচ্ছে এখানে মূল সমস্যাটি হ'ল আপনি "নিজের মনের কথা বলতে ভয় পান"। কখনই রাগ করবেন না, সবসময় আপনার মনের কথা বলুন - হাসি দিয়ে। আপনার সঙ্গে সঙ্গে লোকটিকে বলা উচিত ছিল, "হুঁ, আমাকে কমপক্ষে দুই দিন সময় লাগবে, এটি কি এই মূল্যবান, আসুন আমাদের বসকে জিজ্ঞাসা করুন?" এবং দ্বিতীয়ত আপনার বলা উচিত ছিল "মানুষটিকে ভুলে যাবেন না আমরা রোবোটিক্স নিয়ে কাজ করছি, বাম সংবেদকের পক্ষে ডান সেন্সরের ডানদিকে থাকা আসলে সম্ভব নয় - আসুন আমরা বসকে জিজ্ঞাসা করি যে অ্যান্টি-ফিজিক্যাল কর্নার কেস আমরা কতটা চাই ঢাকতে". আপনার সমস্যাটি আপনার , আপনার সমস্যাটি আলাপের জন্য রাগকে বদলাতে হবে
ফ্যাটি

উত্তর:


227

একটি অস্পষ্ট ঘটনা যা ঘটার পক্ষে অত্যন্ত সম্ভাবনা নেই - আসলে আমি নিশ্চিত না যে এটি ঘটানোও সম্ভব is

কোডে অনির্ধারিত আচরণ না করা খুব গুরুত্বপূর্ণ হতে পারে। যদি কোনও কোডের টুকরোটি যেমন সেকেন্ডে 50 বার চালানো হয় তবে মিলিয়ন সুযোগের মধ্যে একটি রানটাইমের প্রায় প্রতি 5.5 ঘন্টার মধ্যে ঘটবে। (আপনার ক্ষেত্রে, মতবিরোধগুলি কম মনে হচ্ছে))

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

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

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


9
@ 9000 উত্তরটি হ'ল হতাশাজনকও হতে পারে "কারণ জীবন সেইভাবে way" উদাহরণস্বরূপ, এটি হ'ল আমি সম্প্রতি যেতে হয়েছিল: "ট্যাবগুলিতে স্পেস ব্যবহার করুন।" "কেন?" "কারণ আমাদের স্টাইল গাইড বলেছেন।" "কেন?" "আমি জানি না; আমি এটি লিখিনি।" "হা, স্পষ্টতই আপনি ভুল এবং আমি সঠিক, এবং আমি আমার কোডটি ট্যাব সহ রেখে যাচ্ছি!" তারপরে একটি প্রতিশ্রুতি পোস্ট হুক যাইহোক এটি বদলেছে, তবুও - আপনি যদি 5 টি কৌশল ব্যবহার করেন তবে আপনি কোনও বুদ্ধিমান উত্তর না পাওয়া পর্যন্ত যান না, যতক্ষণ না আপনি অন্য ব্যক্তিকে হতাশ করেন।
নিক হার্টলি

111
@ কিপেইট্যাক্সস: ট্যাবগুলিতে ফাঁকা স্থান (বা স্পেসগুলির উপরে ট্যাবগুলি) যুক্তি প্রত্যেকেরই জানা উচিত: কারণ উভয়ই সঠিক তবে ধারাবাহিকতা আরও গুরুত্বপূর্ণ তাই কেবল একটি বেছে নিন, ধারাবাহিক হন এবং সময় নষ্ট করবেন না
বাইকশেডিং

30
Not having untested behaviors in code can be very important. If a piece of code is run e.g. 50 times a second, a one in a million chance will happen approximately every 5.5 hours of runtime. (In your case, the odds seem lower.)-- কি? না, যদি না আপনি মন্টে-কার্লো সিমুলেশন চালাচ্ছেন বা আপনার কোডটিতে কিছু এলোমেলো উপাদান রয়েছে। কম্পিউটারগুলি বেল কার্ভ বা স্ট্যান্ডার্ড বিচ্যুতি অনুযায়ী সফ্টওয়্যার চালায় না যতক্ষণ না আপনি তাদের বিশেষভাবে এটি করতে বলুন।
রবার্ট হার্ভে

10
টুইটার প্রবাহিত ডেটা প্রক্রিয়াকরণের সময় একটি ডেটা-নির্ভর বাগটিও বিবেচনা করুন; যদিও ডেটাটি এলোমেলো নাও হতে পারে তবে এটি অত্যন্ত পুনরাবৃত্ত না হলে বাইটের একটি নির্দিষ্ট সংমিশ্রণ বার বার ঘটতে পারে। এক মিলিয়নে এক = 20 টি বিটের নির্দিষ্ট সংমিশ্রণ দ্বারা ট্রিগার হওয়া, কোনও ভিডিও স্ট্রিম প্রসেসিং করা হলে এর মতো একটি ত্রুটি তত্ক্ষণাত দৃশ্যমান হবে; এমন কিছু ঘটে যা খুব কমই ঘটে তবে নিয়মিত 40 বিট জড়িত।
9000

7
@ রবার্টহারভে: বেশ সম্ভবত! আমি কেবল ইঙ্গিত করতে চেয়েছিলাম যে কোডের টুকরো রয়েছে যেগুলি একটি বিশেষ অনুরোধের আওতায় ভেঙে যাওয়ার জন্য 1e-6 সুযোগ (0 এবং 1 নয়) থাকতে পারে, case অস্পষ্ট মামলার উল্লেখ করে যা ঘটতে পারে না এমন সম্ভাবনা » এর মতো বাগগুলি সাধারণত পরীক্ষার অধীনে দৃশ্যমান হয় না তবে সেগুলি উত্পাদনে দৃশ্যমান।
9000

323

আমি আপনাকে এমন কোন কোণার উদাহরণ দিতে পারি যা কখনই ঘটতে পারে না যা বিপর্যয়ের সৃষ্টি করে।

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

বেশ কয়েক বছর পরে আরিয়েন 5 বিকাশ করা হয়েছিল এবং পার্শ্বীয় অ্যাক্সিলোমিটারগুলির স্কেলিং কোডটি ন্যূনতম পরীক্ষার সাথে পুনরায় ব্যবহার করা হয়েছিল কারণ এটি "ব্যবহারে প্রমাণিত" ছিল। দুর্ভাগ্যক্রমে বৃহত্তর রকেট বৃহত্তর পার্শ্বীয় ত্বরণের আশা করতে পারে তাই অ্যাক্সিলোমিটারগুলি আপগ্রেড করা হয়েছিল এবং বৃহত্তর -৪-বিট ভাসমান মান তৈরি করতে পারে ।

এই বৃহত্তর মান হল "আবৃত" রূপান্তর কোডে, মনে রাখবেন কোন পরিসীমা পরীক্ষণ এবং 1996 সালে প্রথম লঞ্চ এ ফলাফল ভাল ছিল না। এটি কোম্পানির কয়েক মিলিয়ন ব্যয় করেছে এবং প্রোগ্রামটিতে একটি বড় ব্যবধান ঘটেছে।

এখানে চিত্র বিবরণ লিখুন

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

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

শোধন

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

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


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

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

11
আমি মনে করি এমন বাস্তব বিশ্বের উদাহরণ রয়েছে যা প্রমাণ করে কেন প্রান্তের মামলাগুলি coveredেকে রাখা উচিত, তবে এটি তাদের মধ্যে একটি নয়। উদ্ধৃত উদাহরণটি কোনও কাজের জন্য ভুল লাইব্রেরি ব্যবহারের ক্ষেত্রে a একটি কলার কোডটি কমলাতে অন্ধভাবে ব্যবহার করা উচিত নয়। যে ব্যক্তি একটি কমলাতে কলার কোড ব্যবহার করেছিলেন, তার পক্ষে দোষ, যে কলাটি পরিচালনা করতে পারেন না এমন একটি কমলার জন্য কোড লিখেছেন সেই ব্যক্তির নয়। (আমি এই উপমা মধ্যে Banana জন্য অ্যাপল স্যুইচ করতে একটি বড় কারিগরি কোম্পানি কারণে সেখানে আউট ছিল ...)
আদি

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

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

84

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


19
আমি মনে করি এটিই মূল বিষয় although যদিও অতিরিক্ত কেসটি আবরণ করা একটি কার্যকর এবং বৈধ উন্নতি, তবে এটি বিভিন্ন কারণে কোনও বিদ্যমান পিআর-তে অন্তর্ভুক্ত হওয়ার দরকার নেই।
ডেড এমএমজি

6
এর আগে যতটা হ্যান্ডেল করা হয়েছে বা না এটি অপ্রাসঙ্গিক আইএমওও, এটি কেবল টাস্ক-বর্ণনায় আগে ছিল না।
জ্যাস্পার এন। ব্রাউয়ার

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

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

6
এই ভয়ানক পরামর্শ! Since it wasn't handled before, it's out of the scope for your effortপ্রতিটি বাগ রিপোর্ট হিসাবে চিহ্নিত করতে যথেষ্ট হবে wontfix, আপনার অনুমানটি ধরে নেওয়া যথেষ্ট যে আপনার প্রবণতাটি প্রান্তের মামলাগুলি বিবেচনা করে না, এটির পক্ষে যথেষ্ট খারাপ ছিল, যদি আপনার এমনকি যদি কোনও সঠিক অনুমান থাকে তবে।
ফিলিপ হাগলুন্ড

53

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

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

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


7
আপনি আপনার দ্বিতীয় অনুচ্ছেদে একটি খুব ভাল পয়েন্ট করেছেন। আমি এর আগেও অভিজ্ঞতা অর্জন করেছি, তবে তা স্পষ্ট করে বলা খুব সহায়ক।
ক্লিক

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

আমি ব্যতিক্রমগুলি লগ করতে চাই যা বলে "[ত্রুটির বর্ণনা] [স্পেসিফিকেশন অনুসারে [সংস্করণ] [স্বাক্ষরকারী ব্যক্তি] স্বাক্ষর করেছেন] অনুযায়ী এটি ঘটতে পারে না" say
পিটার জিতলেন

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

38

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

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


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

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

1
"এটি কোনও অসুবিধা নয়, এটি হ'ল!"
ব্যবহারকারী 1068

2
এটি সেরা উত্তর। প্রশ্নটি আসলে অগ্রাধিকার নির্ধারণ এবং ঝুঁকি পরিচালনা সম্পর্কে।
wrschneider

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

21

কোড পর্যালোচনাগুলি সম্পূর্ণরূপে কোডের সঠিকতার বিষয়ে নয়। বাস্তবে, এটি সুবিধার তালিকার তুলনায় জ্ঞান ভাগ করে নেওয়ার পিছনে এবং টিম স্টাইল / ডিজাইনের sensক্যমত্য তৈরির দিকে ধীর-স্থির প্রক্রিয়া being

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

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

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

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


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

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

@ টবিস্পাইট: আমি সম্মত হয়েছি এবং এটিকে উত্তরে অন্তর্ভুক্ত করার চেষ্টা করেছি।
নীল স্লেটার

1
2 ঘন্টা আমি যুদ্ধ না কি বেশি। 2 দিন এবং আমি সপ্তাহের জন্য প্রতিশ্রুতিবদ্ধ অন্যান্য সমস্ত কাজ শেষ করতে সক্ষম হব না।
ম্যাথু

15

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

এবং তারপরে, একটি পরীক্ষার কেস তৈরি করুন যা সেই ব্যর্থতাটিকে দৃ .় করে তোলে। এইভাবে, আচরণটি আরও ভাল নথিভুক্ত এবং ইউনিট পরীক্ষায় প্রদর্শিত হবে show

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


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

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

এই, আমি ঠিক একই জিনিস পোস্ট করতে যাচ্ছি। পর্যালোচক একটি সম্ভাব্য ব্যর্থতার দিকে ইঙ্গিত করছেন, কীভাবে এটি পরিচালনা করবেন এটি একটি আলাদা প্রশ্ন।
এসএইচ-

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

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

13

যেহেতু আপনি সেখানে নতুন বলে মনে করছেন, কেবলমাত্র একটি জিনিস আপনি করতে পারবেন - টিম লিডার (বা প্রকল্প নেতা) এর সাথে চেক করুন। 13 ঘন্টা একটি ব্যবসায়িক সিদ্ধান্ত; কিছু সংস্থার / দলের জন্য, অনেক; কিছু জন্য, কিছুই। এটি আপনার সিদ্ধান্ত নয়, এখনও নয়।

সীসা যদি "কেসটি কেস করুন" বলে, জরিমানা; যদি তিনি "নাহ, এটি স্ক্রু" বলেন, জরিমানা - তার সিদ্ধান্ত, তার দায়িত্ব।

সাধারণভাবে কোড পর্যালোচনার জন্য, এটি সম্পর্কে শিথিল করুন। আপনার কাছে একবার বা দুবার কোনও কাজ ফিরে আসা পুরোপুরি স্বাভাবিক।


7

আমি মনে করি না যে আমি দয়া করে সম্বোধন করেছি, যদিও এটি স্টিভ বার্নেসের জবাবের মধ্যে উত্থাপিত ছিল:

ব্যর্থতার ফলাফলগুলি কী কী?

কিছু ক্ষেত্রে একটি ব্যর্থতা একটি ওয়েব পৃষ্ঠায় ত্রুটি। একটি পিসি নীল পর্দা এবং রিবুটগুলি।

অন্যান্য ক্ষেত্রগুলিতে এটি জীবন বা মৃত্যু - স্ব-ড্রাইভিং গাড়ি লক হয়ে যায়। মেডিকেল পেস প্রস্তুতকারক কাজ বন্ধ করে দেয়। বা স্টিভের উত্তরে: স্টাফগুলি ফুটে উঠেছে যার ফলে কয়েক মিলিয়ন ডলারের ক্ষতি হয়।

এই চরমপন্থার মধ্যে একটি পার্থক্য বিশ্বের আছে ।

"ব্যর্থতা" কাভার করতে 13 ঘন্টা মূল্যবান কিনা তা শেষ পর্যন্ত আপনার উপর নির্ভর করে না। এটি পরিচালনা এবং মালিকদের উপর নির্ভর করে। বৃহত্তর ছবির জন্য তাদের একটি অনুভূতি থাকা উচিত।

আপনার মূল্য কী হবে সে সম্পর্কে আপনার ভাল ধারণা দেওয়া উচিত should আপনার রোবট কি কেবল ধীর হয়ে যাবে বা থামবে? ডিগ্রেড পারফরম্যান্স? অথবা রোবটের ব্যর্থতা আর্থিক ক্ষতি করতে পারে? জীবনের ক্ষতি?

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


1
তদতিরিক্ত, অস্পষ্ট হওয়া সত্ত্বেও কোনও জ্ঞাত ত্রুটির দায়বদ্ধতাগুলি কী কী স্থির নয়?
chux

5

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

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


5

মতবিরোধ পরিচালনার সর্বোত্তম উপায় হ'ল আপনি জুনিয়র বিকাশকারী বা সিনিয়র বিকাশকারী, এমনকি সিইও নির্বিশেষে is

কলম্বোর মতো কাজ করুন

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

আমি মনে করি এটি সক্রেটিক পদ্ধতির সাথেও সম্পর্কিত ।


আপনি সঠিক পছন্দগুলি করছেন তা নিশ্চিত করার জন্য সাধারণভাবে আপনি নিজের এবং অন্যদের প্রশ্ন জিজ্ঞাসা করতে চান। "আমি ঠিক আছি, আপনি ভুল," এর অবস্থান থেকে নয় বরং সৎ আবিষ্কারের অবস্থান থেকে। বা কমপক্ষে যতটা সম্ভব সেরা।

আপনার ক্ষেত্রে আপনার এখানে দুটি ধারণা রয়েছে তবে কোডটি আরও ভাল করার জন্য তাদের মূল লক্ষ্য একই।

আপনি এই ধারণাটির আওতায় রয়েছেন যে অন্যান্য বৈশিষ্ট্যগুলির বিকাশের পক্ষে কোনও সম্ভাব্য অসম্ভব (অসম্ভব?) কেসের জন্য কোড কভারেজের উপর ঝাঁপিয়ে পড়া এটি করার সর্বোত্তম উপায়।

আপনার সহকর্মী মনে করছেন যে কোণার কেসগুলি সম্পর্কে আরও সতর্ক হওয়া আরও মূল্যবান valuable

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

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

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


3

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

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

এছাড়াও যখনই তারা আপনাকে কিছু করতে বলবে, "অতিরিক্ত মাইল" এ যান এবং তারা উল্লেখ করতে ভুলে যাওয়া প্রচুর পরিমাণে বা এমন জিনিস যুক্ত করেন যা তাদের কথার চেয়ে আরও ভাল কাজ করবে work তবে অতিরিক্ত মাইল যেতে "ঠিক আছে" তা তাদের জিজ্ঞাসা করবেন না " এটি করার পরে এটি ঘটনাক্রমে তাদের সম্পর্কে বলুন them আপনি যা করছেন তা তাদের প্রশিক্ষণ দিচ্ছেন ..

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


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

1
ঠিক আছে আপনি একভাবে ঠিক আছেন। বিশেষত যদি প্রকৌশলী ক্লায়েন্টের দৃষ্টিভঙ্গি কী তা সম্পর্কে কোনও সংবেদনশীলতা ছাড়াই তার নিজের থেকে চলে যায়। তবে আমি যা বলেছিলাম তা সম্পূর্ণভাবে নাশকতা সৃষ্টি করবেন না - আমি কেবল "অতিরিক্ত মাইল" যেতে বলেছিলাম। সুতরাং এর অর্থ হল যে আপনি আপনার বস যা বলছেন তা গ্রহণ করুন এবং আপনি এটিতে প্রসারিত করুন। এবং সফ্টওয়্যারটিতে, এটি সফ্টওয়্যারগুলির মধ্যে পার্থক্য যা તુચ્છ ছিটে এবং সফ্টওয়্যারগুলির মতো দেখে মনে হয় এটি কোনও পেশাদার দ্বারা তৈরি করা হয়েছে। আমি অনেক বিকাশকারীকে জানি যারা তাদের যা বলা হয় তা পুরো আবর্জনা হলেও "তারা যা বলা হয় ঠিক" তা করে। এই বিকাশকারীরা কখনই কোনও কিছুর পরিমানের হয় না।

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

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

এছাড়াও নোট করুন যে আমার মন্তব্যটি নেতৃত্বের বা পরামর্শক পর্যায়ে স্থানান্তর করতে চান তাদের পক্ষে those সংস্থাগুলি আমার মতামতের জন্য বিশেষত আমাকে নিয়োগ দেয়।

3

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

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

তৃতীয় দিকটি হ'ল এটি যে কোনও পরিবর্তন করার আগেই বিদ্যমান সমস্যাগুলির একটি পর্যালোচনা সরবরাহ করতে পারে। বেশিরভাগ ক্ষেত্রেই, কারওর পরিবর্তনের পর্যালোচনা করার সময়, আমি আগের পুনরাবৃত্তিতে যা মিস করেছি তার কিছু খুঁজে পাব (প্রায়শই আমার নিজের কিছু)। "এখানে এটির চেয়ে আরও দৃ make়তর করার একটি সুযোগ এখানে রয়েছে" এর মত একটি বিবৃতি সমালোচনা নয় এবং একে একে গ্রহণ করবেন না!

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

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

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


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


পরিশেষে, কোড পর্যালোচনার মান সম্পর্কে একটি সাধারণ মন্তব্য হিসাবে (এবং আমি উপরে যা বলেছি তার একটি মর্মাহত সংক্ষিপ্তসার হিসাবে), ডেনিয়েল ভেটারের রক্ষণাবেক্ষণকারীদের স্ক্যান করার ক্ষেত্রে আমি এই বিবৃতিটি পছন্দ করি :

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


3

কোড সবসময় আরও ভাল হতে পারে।

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

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

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

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

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


3

এই প্রশ্নটি প্রতিরক্ষামূলক প্রোগ্রামিংয়ের গুণাবলী, কোণার মামলার ঝুঁকি বা শারীরিক পণ্যগুলিতে বাগগুলির বিপর্যয়কর ঝুঁকি সম্পর্কে নয়। আসলে এটি মোটেও সফটওয়্যার ইঞ্জিনিয়ারিং সম্পর্কে নয়

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

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

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

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

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


2

ক্রমাগত আমার কোডে মন্তব্য করে যা আমাকে প্রয়োজনের তুলনায় অনেক বেশি কাজ করার পরামর্শ দেয়।

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

তিনি পরামর্শ দিয়েছিলেন যে আমি এমন একটি অস্পষ্ট কেসটি পরিচালনা করি যা হওয়ার সম্ভাবনা খুব কম

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


2

আপনার কোড পর্যালোচনার ব্যবসায়ের উপযোগিতা বাড়াতে কোড পর্যালোচকদের পরামর্শ (আপনার যেমন ওপি হিসাবে এমন পরিবর্তন প্রস্তাব করা উচিত):

  • আপনার মন্তব্য টাইপ করে চিহ্নিত করুন। "সমালোচনা" / "করণীয়" / "ptionচ্ছিক" / "প্রস্তাবিত উন্নতি" / "ভাল লাগছে" / "আমি মুজ করছি" ing

    যদি এটি খুব সিডিও / পায়ুসংক্রান্ত / জটিল মনে হয় তবে কমপক্ষে 2 টি স্তর ব্যবহার করুন: "অবশ্যই পর্যালোচনা পাস করার জন্য ঠিক করতে হবে এবং আপনার পরিবর্তনকে মার্জ করার অনুমতি দেওয়া হবে" / "অন্য সমস্ত"।

কোড পর্যালোচনা পরামর্শগুলি পরিচালনা করার পরামর্শ যা এটিকে করা কম সমালোচনা বলে মনে হচ্ছে:

  • পরামর্শটি ট্র্যাক করে আপনার পছন্দের টিকিটিং সিস্টেমে একটি মুক্ত টিকিট তৈরি করুন (আপনার দলটি আশাবাদী একটি ব্যবহার করে?)

  • যদি আপনার প্রক্রিয়া ফিশে বা ইমেল পর্যালোচনার মতো মন্তব্যে প্রতিক্রিয়াগুলি মঞ্জুরি দেয় তবে কোড পর্যালোচনা আইটেমে প্রতিক্রিয়া হিসাবে টিকেট # রাখুন।

  • পর্যালোচনা করতে পৌঁছান এবং স্পষ্টভাবে জিজ্ঞাসা করুন যে আইটেমটি "অবশ্যই ঠিক করতে হবে বা মার্জ / প্রকাশ করা হবে না" প্রকারের।

    • যদি উত্তরটি "হ্যাঁ" হয় তবে আপনি একমত নন, প্রকল্প পরিচালনার জন্য দায়বদ্ধ ব্যক্তিকে (প্রধানমন্ত্রী, আপনার পরিচালক, ইত্যাদি ...) সিদ্ধান্ত নিতে দিন - মতবিরোধটিকে পুরোপুরি এবং সততার সাথে উপস্থাপন করুন। এটি আপনার মধ্যে কোনটি "সঠিক" সে সম্পর্কে নয় তবে এই প্রকল্পের জন্য আরও ভাল কী, তাই প্রধানমন্ত্রী / পরিচালকের কাজ।

এখন, টিকিটটিকে অন্য কোনও বিকাশের অনুরোধ হিসাবে বিবেচনা করুন।

  1. যদি এটি বাড়ার পরে জরুরি হওয়ার সিদ্ধান্ত নেওয়া হয় তবে এটি যেকোন জরুরি দেব অনুরোধ হিসাবে বিবেচনা করুন। অন্যান্য কাজকে অবচালিত করুন এবং এতে কাজ করুন।

  2. অন্যথায়, এটি নির্ধারিত অগ্রাধিকার অনুযায়ী তার উপর কাজ করুন এবং এর আরওআই (যা অন্যান্য ব্যবসায়ের উত্তর হিসাবে বর্ণিত আপনার ব্যবসায়ের লাইনের ভিত্তিতে পৃথক হতে পারে)।


2

আপনার এটি পরিচালনাতে বাড়ানো উচিত নয়

বেশিরভাগ সংস্থায় ম্যানেজমেন্ট লোকটি সর্বদা সেই অতিরিক্ত পরীক্ষাটি না লেখার জন্য কোডের মান উন্নত করার জন্য সামান্য সময় ব্যয় না করার জন্য, সময় রিফ্যাক্টরিং না হারাতে পছন্দ করে

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

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

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


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

1

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

যদি আপনি মনে করেন যে কোনও কিছু ভুল এবং আপনি যদি আপনার ক্ষেত্রে তুলনামূলকভাবে বিশেষজ্ঞ হন তবে সম্ভাবনা বেশি থাকে আপনি সঠিক

এখানে কিছু বিবৃতি যা আপনার পক্ষে কার্যকর হতে পারে:

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

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

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

সাধারণভাবে নিম্নলিখিত দুটি এড়ানোর চেষ্টা করুন:

  • আপনি যা যা অনুরোধ করা হয়েছে তা করছেন না
  • আপনি আপনার পর্যালোচককে বোবা মনে করেন

যদি সে আসলে আপনার কোডটি পর্যালোচনা করে থাকে, কারণ এটি পরিচালনা আপনার চেয়ে তার বেশি বিশ্বাস করে।


-1

সুযোগ সম্পর্কে কোড পর্যালোচনা চলাকালীন যখন মতবিরোধ হয়:

  1. প্রকৃতপক্ষে কোড দ্বারা আচ্ছাদিত সুযোগটি নথি করুন। কেউ বাজে চমক পছন্দ করে না।
  2. সুযোগটি ব্যবসায়ের সিদ্ধান্ত ize আপনি কোনও বৈশিষ্ট্যটিতে কাজ শুরু করার আগেই সুযোগটি ইতিমধ্যে জানা উচিত, তবে এটি যদি না হয় তবে আপনি পরে সবসময় স্পষ্টতার জন্য জিজ্ঞাসা করতে পারেন।

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


এই কিছু সারগর্ভ প্রস্তাব উপর পয়েন্ট হয়েছে এবং পূর্বে 20 উত্তর ব্যাখ্যা বলে মনে হচ্ছে না
মশা

-1

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

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

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

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

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


এই কিছু সারগর্ভ প্রস্তাব উপর পয়েন্ট হয়েছে এবং পূর্বে 21 উত্তর ব্যাখ্যা বলে মনে হচ্ছে না
মশা

-2

কোড পর্যালোচক রয়েছে যারা জানেন তারা কী করছেন এবং যদি তারা বলেন যে কোনও কিছু পরিবর্তন করা দরকার, তবে এটি পরিবর্তন করা দরকার, এবং যখন তারা কিছু বলে পরীক্ষা করার প্রয়োজন হয়, তখন এটি পরীক্ষা করা দরকার।

কোড রিভিউর রয়েছে যাদের অন্যের জন্য অকেজো কাজ তৈরি করে তাদের নিজের অস্তিত্বকে ন্যায্যতা দেওয়া দরকার।

কোনটি কোনটি আপনার সিদ্ধান্ত নেওয়ার জন্য, এবং দ্বিতীয় ধরণের কীভাবে পরিচালনা করবেন এটি কর্মক্ষেত্র.স্ট্যাকেক্সচেঞ্জের জন্য আরও প্রশ্ন।

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


6
দরকারী পরামর্শ হিসাবে এটি খুব অস্পষ্ট এবং সংবেদনশীল।
রবার্ট হার্ভে

এসসিআরইউএম সম্পর্কে মন্তব্য সম্পূর্ণ সঠিক, জাটগুলি ব্যাকলগে একটি নতুন কাজ করে। আপনার উত্তরের অভদ্র শুরু সরিয়ে ফেলুন এবং আপনি ইতিবাচক স্কোর পাবেন।
xmedeko
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.