কোড পর্যালোচনাগুলিতে, পর্যালোচকদের কি সবসময় সমস্যার সমাধান সমাধান করা উচিত? [বন্ধ]

Question

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

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

আর একটি সাধারণ ঘটনা যা আমি অনেকবার অভিজ্ঞতা পেয়েছি তা হ'ল আমি একটি স্পষ্টত অর্থহীন বা এমনকি বিভ্রান্তিমূলক কার্য, শ্রেণি বা পরিবর্তনশীল নামটি পাই তবে আমি নিজে একটি ভাল নাম নিয়ে আসতে সক্ষম নই।

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

Comments

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

— মশা

@gnat: কোন কোড খুব জটিল নয়। এবং এটি কেবল একটি উদাহরণ। আমি সাধারণত জিজ্ঞাসা করছি যে কোনও সমাধান উপস্থাপনের জন্য পর্যালোচক দায়বদ্ধ কিনা।

— ফ্র্যাঙ্ক পাফার

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

— মশা

"এটি সমাধানের আদর্শ উপায় হ'ল শ্রেণি বিভক্ত করা এবং উত্তরাধিকার ব্যবহার করা" " আমি নিশ্চিত আপনি আমার কোড পর্যালোচনা করছেন না আশা করি!

— উদ্যানক্ষেত্র

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

— মার্টিন মাট

Answer 1

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

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

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

অন্যদিকে, কেবল লেখককে বলা "এটি ত্রুটিযুক্ত। এটি ঠিক করুন" দলে সাধারণত একটি ইতিবাচক পরিবেশ তৈরি হয় না। ইতিবাচক পরিবেশের জন্য, আপনার চোখে কেন কিছু ত্রুটি রয়েছে তা অন্তত নির্দেশ করা ভাল এবং আপনার যদি এটি থাকে তবে আরও ভাল বিকল্প সরবরাহ করা ভাল।
তদতিরিক্ত, যদি আপনি এমন কোনও কিছু যা "ভুল" বলে মনে হচ্ছে তবে আপনার কাছে এর চেয়ে ভাল বিকল্প না থাকে তবে আপনি "এই কোড / ডিজাইনটি আমার সাথে ভালভাবে বসেন না," এর লাইন ধরে একটি মন্তব্যও দিতে পারেন I সুস্পষ্ট বিকল্প নেই don't আমরা কি এটি নিয়ে আলোচনা করতে পারি? " এবং তারপরে একসাথে আরও ভাল কিছু করার চেষ্টা করুন।

Comments

একসাথে আলোচনার জন্য আলোচনার জন্য +1

— dj18

+1 টি। প্রতিক্রিয়া দেওয়ার সময়, যখনই সম্ভব সম্ভাব্য গঠনমূলক সমালোচনা করা ভাল ।

— হতাশ

আমি বিশেষত শেষ বিট সঙ্গে একমত। এটি বলা পুরোপুরি ঠিক আছে, "এই সমাধানটি ভুল অনুভব করছে কারণ ...," বা "আমি আশঙ্কা করছি যে এই অংশটি সমস্যা হতে পারে কারণ ..." সমাধান না দিয়েই।

— ড্যানিয়েল টি।

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

— বার্ট ভ্যান ইনজেন শেনৌ

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

— candied_orange

Answer 2

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

Answer 3

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

দুজনের কেউই আদর্শ আইএমও নয়। করণীয় সবচেয়ে ভাল কাজটি লেখকের সাথে কথা বলা এবং সমস্যাটি যৌথভাবে সমাধান করা।

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

Comments

"আমলাতান্ত্রিক প্রক্রিয়া" এটি রাখার একটি ভাল উপায়!

— frnhr

Answer 4

কোড পর্যালোচনাগুলিতে, পর্যালোচকদের কি সবসময় সমস্যার সমাধান সমাধান করা উচিত ?

না, যদি আপনি এটি করছেন যে আপনি কোনও পর্যালোচক নন তবে আপনি পরবর্তী কোডার।

কোড পর্যালোচনাগুলিতে, পর্যালোচককে কি কখনও সমস্যার সমাধান সমাধান করা উচিত নয় ?

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

পর্যালোচনা করা উচিত কখন সমস্যার সমাধান?

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

Comments

ভ্যাকুয়ামে কোড করবেন না কারণ এটি সফল হয়।

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

— jpmc26

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

— jpmc26

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

— candied_orange

"কোড বানর কফি পেতে উঠুন Code কোড বানর চাকরীতে যান Code বিরক্তিকর ম্যানেজার রবের সাথে কোড বানরের বিরক্তিকর সভা হয় Rob রব বলে কোড বানরকে খুব পরিশ্রমী, তবে তার আউটপুট দুর্গন্ধ ..."

— বাল্ড্রিক ১৮

Answer 5

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

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

Comments

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

— রাবারডাক 23'17

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

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

— ইমিবিস

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

— gnasher729

Answer 6

দু' রকমের খারাপ প্রোগ্রামার রয়েছে: যারা মানক অনুশীলনগুলি অনুসরণ করে না এবং যারা "কেবল" মানক অনুশীলনগুলি অনুসরণ করে।

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

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

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

আমি বুঝতে পারি যে এটি একটি সুস্পষ্ট সমাধানের চেয়ে সমস্যার আরও বেশি উপায়। সমস্ত পরিস্থিতি কভার করার জন্য খুব বেশি পরিবর্তনশীলতা রয়েছে।

Comments

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

— ওয়াইল্ডকার্ড

কখনও কখনও নিয়মের কোনও ব্যতিক্রম থাকে না তবে সাধারণত তারা তা করে না।

@ উইল্ডকার্ড - এটি নির্ভর করে এমন লোকের ক্ষমতা এবং পছন্দ / মতামতের উপর।

— JeffO

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

— আইএমএসওপি 24'17

Answer 7

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

Answer 8

আমার মতামত বেশিরভাগ ক্ষেত্রে কোড না দেওয়ার দিকে দৃ stronger়তর হতে চলেছে, বিভিন্ন কারণে:

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

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

তারপরেও, তৃতীয় কারণে, কোনও নমুনা দেওয়ার সময় এটি x.foo()একটি সম্পূর্ণ সমাধানের চেয়ে উদাহরণস্বরূপ "ব্যবহার করা এটিকে আরও সহজ করে তুলবে " - বলার অপেক্ষা রাখে - এবং লেখক এটি লিখতে দিন। এটি আপনার সময় সাশ্রয় করে।

Comments

আপনার 5 তম পয়েন্টটি আমাকে হাসিয়ে দিয়েছে, কে প্রথমে দুর্দান্ত সমাধান পেতে পারে তা দেখার জন্য আমি "দ্বৈত কীবোর্ডগুলি" ভাবছিলাম। কে জানত যে পেয়ার প্রোগ্রামিং সেই দুটি রেসকার আরকেড গেম, বা একটি সম্পূর্ণ যোগাযোগের স্পোর্টসের মতো হতে পারে? " স্টিভ পেনাল্টি বাক্সের 2 মিনিটের মধ্যে

Answer 9

আমি মনে করি কোড পর্যালোচনার মূল চাবিকাঠিটি পর্যালোচনার আগে নিয়মের সাথে একমত হওয়া।

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

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

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

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

Comments

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

— ফ্র্যাঙ্ক পাফার

কোডিং মান নথিতে বিধিগুলি লিখুন এবং নতুন দেবগুলিকে দিন

— ইভান

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

— ফ্র্যাঙ্ক পাফার 11

Answer 10

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

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

Answer 11

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

লিখিত যোগাযোগ বিপুল পরিমাণ সময় নষ্ট করার পাশাপাশি অসন্তুষ্টি এবং ভুল বোঝাবুঝির দিকে নিয়ে যায়।

সামনাসামনি, ব্যান্ডউইদথ অনেক বেশি এবং শত্রুতা রোধে ইমোশনাল পার্শ্ব-চ্যানেল রয়েছে।

যদি আপনি আসলে লোকটির সাথে কথা বলেন তবে তা অনেক দ্রুত এবং আপনি একটি নতুন বন্ধু তৈরি করতে পারেন এবং আপনি উভয়ই নিজের কাজটি আরও উপভোগ করতে পারেন।

Comments

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

— মশা