কোড পর্যালোচনা খুব শক্ত হয়ে গেলে আপনি কী করবেন?


144

ঠিক আছে তাই প্রচুর কোড পর্যালোচনা মোটামুটি রুটিন। তবে মাঝে মধ্যে এমন কিছু পরিবর্তন ঘটে যা বিদ্যমান জটিল, ভঙ্গুর কোডকে বিস্তৃতভাবে প্রভাবিত করে। এই পরিস্থিতিতে পরিবর্তনের সুরক্ষা যাচাই করতে যে পরিমাণ সময় লাগবে, প্রতিরোধের অনুপস্থিতি ইত্যাদি অত্যধিক। সম্ভবত এমনকি উন্নয়ন নিজেই করতে সময় ব্যয় করেছে।

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

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

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


91
আপনি কিছু ভঙ্গ করলেন না তা নিশ্চিত করতে আপনার টেস্ট স্যুটটি চালানোর বিষয়ে কী?
ভিনসেন্ট সাভার্ড

130
what if there is no pre-existing test suite?- কিভাবে লিখতে হবে?
রবার্ট হার্ভে

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

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

21
Merge and hope nothing slips through?এটি একটি কুখ্যাতভাবে খারাপ ধারণা।
মাস্ত

উত্তর:


306

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

তাহলে কীভাবে এই পরিস্থিতি মোকাবেলা করতে হবে? এটি প্রথম দিকে না পেয়ে শুরু করুন:

  • জটিলতার উত্সগুলি শনাক্ত করুন এবং সাবধানতার সাথে প্রয়োগ করুন, ভারী পর্যালোচনা করুন, বিমূর্তির স্তর বাড়ানোর জন্য সঠিক রিফ্যাক্টরিংগুলি। আপনার কলেজের ব্যবসায়িক ডোমেন সম্পর্কে কিছু জানেন এমন কলেজের একজন নতুন কর্মচারী কোডটি বোঝা উচিত।

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

  • স্বয়ংক্রিয় পরীক্ষার একটি স্যুট লিখুন। একথাও ঠিক যে।

  • বিস্তৃত পরিবর্তন করবেন না। ছোট, লক্ষ্যযুক্ত পরিবর্তনগুলির একটি সিরিজ তৈরি করুন, যার প্রতিটি সঠিক হতে দেখা যায়।

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


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

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

14
@ জুলিয়াহ্যাওয়ার্ড আপনি সঠিক, কিন্তু তবুও, লুক যে পরিস্থিতি বর্ণনা করেছেন তা সাধারণ, বিশেষত এমন কোডে যা ইতিমধ্যে আয় উপার্জন করে। সত্যিই এটি কাজ করা আপনার পক্ষে মূল্যবান কিনা তা আপনার উপর নির্ভর করে।
ওপেন

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

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

96

কোড পর্যালোচনার প্রাথমিক লক্ষ্যগুলির মধ্যে একটি হ'ল মান বৃদ্ধি এবং শক্তিশালী কোড সরবরাহ করা । দৃ Rob়, কারণ 4 চোখ সাধারণত 2 এর চেয়ে বেশি সমস্যা দেখায় And

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

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

উপসংহারের একটি উদ্ধৃতি:

"আপনি যদি দ্রুত যেতে চান তবে একা যান you আপনি যদি আরও বেশি যেতে চান, একসাথে যান"


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

11
আমি আরও যোগ করব যে এই মুহুর্তে কোডটি পর্যালোচনা করা না হলে এটি এখন থেকে 6 মাস ধরে রাখা যায় না .....
কর্সিকা

3
@ করসিকা এটি অনিবার্য হওয়ার জন্য 6 মাস কেন অপেক্ষা করবেন?
ক্রিলগার

2
@ ক্রিলগার এটি হুম না ... আপনি কোডটি সেট করার সময় এবং আবার এটি বাছাইয়ের মধ্যবর্তী সময়কালের প্রতিনিধিত্ব করার জন্য আমি আমার মাথার উপরের অংশটি টেনে নামিয়েছি মাত্র ... তাই, হ্যাঁ ...
কর্সিকা

16
@ ক্রিলগার: আমি কিছু "নতুন কোড" লিখি, আমি এটিকে পরীক্ষা করে দেখি, আমি মধ্যাহ্নভোজ করতে যাই এবং যখন ফিরে আসি, আমার "নতুন কোড" ম্যাজিকালি "লিগ্যাসি কোড" তে পরিণত হয়েছে। কীভাবে এমন হত? :)
এরিক লিপার্ট

35

উত্তরাধিকার সফ্টওয়্যার বিকাশের বিশ্বে স্বাগতম।

আপনার কাছে কয়েকশো, লক্ষ লক্ষ, কোডের লক্ষ লক্ষ লাইন।

কোডগুলির এই লাইনগুলি মূল্যবান, এতে তারা একটি উপার্জন প্রবাহ উত্পাদন করে এবং তাদের প্রতিস্থাপন অপরিহার্য।

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

নিখুঁত বিশ্বে আপনার বিশাল কোড বেসটি ওয়াজুর একক পরীক্ষিত। আপনি নিখুঁত বিশ্বে বাস করেন না।

একটি নিখুঁত নিখুঁত বিশ্বে আপনার প্রযুক্তিগত youণ ঠিক করার জন্য আপনার কাছে বাজেট রয়েছে - আপনার কোডটি ইউনিট টেস্টেবল টুকরো টুকরো টুকরো করে ফেলুন, এক্সপেরিয়েন্স ইন্টিগ্রেশন টেস্টিং করুন এবং পুনরাবৃত্তি করুন।

এটি অবশ্য নতুন বৈশিষ্ট্য তৈরি না করে debtণ পরিশোধ করছে। যা "আপগ্রেড করার প্রণোদনা উত্সাহিত করার জন্য এটি সংশোধন করার সময় বিদ্যমান কোড থেকে মুনাফা অর্জনের ব্যবসায়ের ক্ষেত্রে মেলে না"।

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

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

তারপরে বাকি অ্যাপগুলির অংশগুলি সন্ধান করুন যা মূলত এটির সাথে ইন্টারঅ্যাক্ট করে এবং একবারে তাদের আক্রমণ করে।

আপনি এটি করার সাথে সাথে আপনি সাবসিস্টেমটি উন্নত করতে পারবেন এবং গ্রাহকরা যে অর্থ প্রদান করতে ইচ্ছুক সেগুলি যুক্ত করুন।

সংক্ষেপে, এটি সম্ভাবনার শিল্প - কোনও ব্যবসায়ের ক্ষেত্রে সরবরাহকারী জিনিসগুলি না ভাঙ্গিয়ে পরিবর্তন করা without

তবে এটি আপনার প্রশ্ন নয়। আপনার প্রশ্নটি হ'ল, "আমি এমন কিছু করছি যা বিশাল, এবং জিনিস ভাঙ্গার সম্ভাবনা রয়েছে এবং আমি কীভাবে সেরা অনুশীলনগুলি অনুসরণ করব?"

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

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

আপনার যদি ক্ষমতা এবং বাজেট থাকে তবে আসলে আত্মবিশ্বাস তৈরির প্রচেষ্টাটি ব্যয় করুন যে পরিবর্তনটি কাজ করে, বা কেবল পরিবর্তনটি প্রত্যাখ্যান করে। এটি ডিগ্রির বিষয় হতে চলেছে, সদয় নয়।

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

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

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


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

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

25

কোড পর্যালোচনা অত্যধিক শক্ত হয়ে উঠছে এমন বড় সমস্যাগুলি সমাধান করুন।

আমি এখন পর্যন্ত যেগুলি স্পট করেছি:

  1. কোনও ইউনিট পরীক্ষার স্যুট নেই
  2. জটিল কোড মার্জ যা আরও বুদ্ধিমান কোড কাঠামো এবং কোডিং দায়িত্বের প্রতিনিধি দ্বারা এড়ানো যেতে পারে
  3. প্রাথমিক স্থাপত্যের একটি আপাত অভাব

15
  1. আপনি কোড পর্যালোচনাটি আবার পাঠাতে পারেন এবং বিকাশকারীকে এটিকে আরও ছোট, আরও বাড়ানো পরিবর্তনসেটে বিভক্ত করতে এবং একটি ছোট কোড পর্যালোচনা জমা দেওয়ার জন্য বলতে পারেন।

  2. আপনি কোডের প্রতিটি বিবরণ অগত্যা ছাড়াই কোড গন্ধ, নিদর্শন এবং অ্যান্টি-প্যাটার্নস, কোড ফর্ম্যাটিং মান, সোলিড নীতি ইত্যাদির জন্য এখনও পরীক্ষা করতে পারেন।

  3. অবিচ্ছিন্নভাবে পুরো পরিবর্তনের সামগ্রিক উদ্দেশ্য বুঝতে না পেরে আপনি বিশদ স্তরে যথাযথ ইনপুট বৈধতা, লকিং / থ্রেড পরিচালনা, সম্ভাব্য অপরিশোধিত ব্যতিক্রম ইত্যাদির জন্য কৌশলগত কোড পরিদর্শন করতে পারেন।

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


14

এই পরিস্থিতিতে পরিবর্তনের সুরক্ষা যাচাই করতে যে পরিমাণ সময় লাগবে, প্রতিরোধের অনুপস্থিতি ইত্যাদি অত্যধিক।

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

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

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


2
সম্মত, কিন্তু: কোড পর্যালোচনাগুলির আসলে একটি 0 তম উদ্দেশ্য রয়েছে যা কোড পাঠযোগ্যতা, রক্ষণাবেক্ষণযোগ্যতা ইত্যাদির চেয়ে আরও গুরুত্বপূর্ণ They তারা দলের মান কী তা দলকে শিক্ষিত করার জন্য। কোড পর্যালোচনার ফলস্বরূপ যদি কোনও সম্পাদনা সম্পাদিত না হয়, তবুও তারা তাদের উদ্দেশ্যটির 75% পূরণ করেছিল, কারণ পর্যালোচনাটি কোড লেখককে সেই একই ধরণের ভুলগুলি বারবার, বারবার, দীর্ঘ ভবিষ্যতের আজীবন জুড়ে এড়াতে শিক্ষিত করবে would এই প্রকল্প, এবং পরবর্তী ...
জোনাথন হার্টলি

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

2
@ জোনাথান হার্টলি: সেক্ষেত্রে, কোড পুনর্বিবেচনার (মাইনাস প্রথম) কারণটি বিকাশকারীদের কোড লিখতে হবে যে কোনও কোড পর্যালোচনাতে অন্য কাউকে দেখাতে তারা লজ্জা পাবে না :-)
gnasher729

উপরের গিলাওম 31 এবং gnasher729 উভয়ের সাথে একেবারে সম্মত।
জনাথন হার্টলি

11

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

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

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

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


3
কঠোর অংশটি ব্যবসায়ের ব্যাখ্যা দিচ্ছে যে, "হ্যাঁ, আমরা কিছু বাগ প্রবর্তন করব, তবে আমরা সেগুলি ঠিক করব এবং দ্রুত এটি সংশোধন করব A সামান্য ধৈর্য এখনই আপনাকে ভবিষ্যতে নতুন বৈশিষ্ট্য এবং বাগ ফিক্সগুলি দ্রুত এনে দেবে।"
রাবারডাক

3

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


3

আপনি যদি বগি / অ-কার্যক্ষম সফ্টওয়্যার সহ প্রেরণ করতে এবং পরে এটিকে ঠিক করার বিষয়বস্তু না হন তবে ভিএন্ডভি প্রচেষ্টা উন্নয়নের চেষ্টার চেয়ে দীর্ঘতর হওয়া উচিত !

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


1

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

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

সরঞ্জাম উপলব্ধ, তাদের ব্যবহার করুন! :)


1

এখনও কেন এটি উল্লেখ করা হয়নি তা আমি জানি না, তবে এই 2 টি সবচেয়ে গুরুত্বপূর্ণ টুকরো:

  • আপনি চেঞ্জলিস্টটিকে একাধিক ছোট চেঞ্জলিস্টে বিভক্ত করেছেন, যা আপনি একে একে একে একে পর্যালোচনা করছেন।
  • চেঞ্জলিস্টের পর্যালোচনা যদি এমন সিদ্ধান্তে আসে না যে চেঞ্জলিস্টটি ভাল বলে মনে হচ্ছে, আপনি অবশ্যই পরিবর্তনটি প্রত্যাখ্যান করবেন।

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


1

সেরাটি কি কেবল কোনও স্পষ্ট ত্রুটিগুলি চিহ্নিত করার চেষ্টা করতে পারে (সম্ভবত এটি সবচেয়ে কোড পর্যালোচনাকে যাইহোক লক্ষ্য করা উচিত)?

কোড পুনরুদ্ধারের সম্ভাব্য মানটিকে হ্রাস করবেন না। এগুলি বাগগুলি সনাক্তকরণে ভাল হতে পারে:

  • পরীক্ষার পরেও সনাক্ত করা কঠিন এমন বাগগুলি সন্ধান করুন
  • পরীক্ষার পরেও সনাক্ত করতে বা ঠিক করা কঠিন হবে এমন বাগগুলি সন্ধান করুন

এগুলি অন্যান্য কারণেও কার্যকর:

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

এই পরিস্থিতিতে কি করবেন?

সর্বোত্তম / আদর্শ ক্ষেত্রে, কোড পরিদর্শন পাস করার অর্থ কেবল "কোনও সুস্পষ্ট বাগ নেই" নয়: এর অর্থ "স্পষ্টতই কোনও বাগ নেই" (যদিও আপনি এটিও পরীক্ষা করতে চান)।

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

খণ্ডিত কোডের জন্য ইউনিট পরীক্ষার কোনও বিস্তৃত স্যুট উপলব্ধ নয় বা ইউনিট পরীক্ষাগুলি কার্যকর হবে না

ইন্টিগ্রেশন-, সিস্টেম- এবং গ্রহণযোগ্যতা-পরীক্ষা সম্পর্কে কী?

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

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


0

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

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

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

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

কোনও সফ্টওয়্যার বিকাশের সেরা অনুশীলন কোনও ব্যবসায়ের প্রয়োজনকে বোঝায় না।

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

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

এর উত্তর হ'ল অগত্যা একটি সুনির্দিষ্ট কেস দৃশ্য। কোনও কয়েন টস মাথা বা লেজ হবে কিনা তা ভবিষ্যদ্বাণী করার চেষ্টা করার মতো। সেরা অনুশীলনগুলি এটিকে 100 বার ফ্লিপ করতে বলে এবং প্রত্যাশাটি প্রায় 50 টি মাথা এবং 50 টি লেজ হবে তবে আপনার কাছে 1 বার এটি ফ্লিপ করার সময় নেই। আপনার পরিস্থিতি বিশদটি এখানেই গুরুত্বপূর্ণ। আপনি কি জানেন যে একটি মুদ্রা প্রায় একই সময়ে প্রায় 51% সময় থেকে একই নীতিতে অবতরণ করে? মুদ্রাটি টস করার আগে কোন পথে ছিল তা পর্যবেক্ষণ করতে আপনি কি সময় নিয়েছিলেন? এটি একটি পার্থক্য করতে পারে।

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

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

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

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

* ঠিক আছে, প্রায়: এল 4 মাইক্রোকার্নেল একটি অটোমেটেড প্রুফ সিস্টেম দ্বারা একটি কোড রিভিউ পেয়েছিল যা এর কোড প্রমাণ করে, যদি একটি কনফর্মেন্ট সি ++ সংকলক দ্বারা সংকলিত হয়, তবে ডকুমেন্টেশন যা বলে ঠিক তাই করবে।


2
আপনার উত্তরটি পরামর্শ দেয় যে 'স্বয়ংক্রিয় প্রুফ সিস্টেম' L4 এর উত্স কোডটি স্বয়ংক্রিয়ভাবে পর্যালোচনা করেছে। আসলে এটি এল 4-এর সঠিকতার মানব-লিখিত প্রমাণ পর্যালোচনা করেছে । প্রমাণটি সম্পূর্ণ হতে কয়েক বছর সময় নিয়েছিল। তবুও সঠিক কোড কীভাবে লিখবেন সে সম্পর্কে এই প্রচেষ্টা থেকে অনেক কিছুই শিখতে হবে। (স্পষ্টরূপে, এটি কোনও কলম-কাগজের প্রমাণ নয় বরং একটি মেশিন-পঠনযোগ্য প্রমাণ যা সম্পূর্ণ উত্স কোড এবং এটি সম্পর্কে কারণগুলি 'আমদানি' করে। Ssrg.nicta.com.au/pferences .pdf )
আর্টিলিয়াস

0

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

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

0

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

কোড পর্যালোচনাগুলি "খুব শক্ত" হলে কী করবেন?

  1. মূল লাইন কোড শাখায় ফিরে যান
  2. আপনি যে কার্যকারিতাটি পুনরুদ্ধার করেছেন তার পরীক্ষা করুন (যেমন কার্যকরী পরীক্ষা)
  3. পরীক্ষা পাস করতে
  4. "টেস্ট করা কঠিন" কোডগুলিতে পরীক্ষাগুলি মার্জ করুন
  5. পরীক্ষা কি এখনও পাস হয়?

হ্যাঁ

আপনার বিকাশকারীরা দুর্দান্ত ছিলেন! বিড়াল সবার জন্য ফিরে!

(বা মার্কিন টেলিভিশনে যারা " দ্য সিম্পসনস " দেখে বড় হয়েছেন না তাদের জন্য : পরীক্ষাগুলি যদি পাস হয় তবে পার্থক্যগুলি দেখার চেষ্টা করতে এড়িয়ে যান এবং বিকাশকারীকে পরিবর্তনের একটি সফরে আপনাকে নেতৃত্বদান করুন)

না

পরীক্ষাগুলি পাস না হওয়া অবধি রিফ্যাক্টরিং এবং পরীক্ষার কভারেজ যুক্ত করুন


7
কী বিড়াল ফিরে মানে?
জেডিগোগস

@ জেডিগোগস ইজ সিম্পসনস রেফারেন্স এখন।
রাইময়েড

আমি পাই না।
জেডিগোগোস

জিমন্যাস্টিক্সের প্রশিক্ষক লুগাশের তার ছাত্রদের বিড়াল এবং কুকুরকে বাজেয়াপ্ত করার অভ্যাস রয়েছে, কেবল যখন ছাত্র কোনও শারীরিক কাজ সম্পাদন করে তখন তাদের ফিরিয়ে দেয়। simpsons.wikia.com/wiki/Lugash
মার্ক ম্যাকলারেন

-1

একটি গুনের মতো, কোড পর্যালোচনা শূন্য প্রয়োগ করা হলে শূন্য ফলাফল দেয়। এটি এ জাতীয় ক্ষেত্রে মান বাড়ায় না, অন্য বেশিরভাগ ক্ষেত্রে এটির ক্ষেত্রে।

আপনার যে কোডটির সাথে কাজ করতে হবে তা পরবর্তী বিকাশের সময় কোড পর্যালোচনা প্রক্রিয়াটি থেকে উপকৃত হওয়ার জন্য খুব খারাপভাবে ডিজাইন করা হয়েছে। কোডটি পর্যালোচনা প্রক্রিয়াটি রিফ্যাক্টর বা পুনরায় বিকাশের জন্য ব্যবহার করুন।

এটি এমনও হতে পারে যে কোডটি এখনও বহনযোগ্য তবে কার্যটি ভাল নয়। এটি খুব বিস্তৃত এবং ছোট ইনক্রিমেন্টে করা উচিত ছিল।


2
@ ডাউনভোটার, কোড পর্যালোচনাটি খারাপ ডিজাইনের প্রতিস্থাপন নয় এবং যাইহোক এটি প্রয়োগ করার চেষ্টা করার ফলে সাধারণত পরিবর্তনগুলি কখনও অনুমোদিত হয় না, কারণ পর্যালোচক জাঙ্কের এই জঞ্জাল পরিবর্তনগুলি বুঝতে পারে না। আপনার দৃষ্টি নষ্ট করার জন্য দুঃখিত।
এইচ 22
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.