কোড পর্যালোচনা এবং ইউনিট পরীক্ষার অনুশীলন অগ্রগতি


15

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

আপনি কীভাবে এমন একটি উপায় তৈরি করতে যাচ্ছেন যাতে কোড পর্যালোচনা এবং ইউনিট পরীক্ষাটি স্বাভাবিকভাবে বিকাশকারীর প্রবাহের সাথে খাপ খায়?

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

কোড পর্যালোচনার জন্য আরেকটি প্রতিরোধ হ'ল আমরা বর্তমানে এটি কীভাবে করব তা জানি না। আমাদের প্রতিটি চেক-ইন করে কোডটি পর্যালোচনা করা উচিত, বা নির্দিষ্ট তারিখে কোডটি পর্যালোচনা করা উচিত?


নির্ধারিতভাবে একটি মজাদার প্রশ্ন - এখানে অন্যান্য অবিস্মরণীয় প্রশ্ন রয়েছে, তবে তারা সবাই প্রোগ্রামারের পক্ষ থেকে জিজ্ঞাসা করেছে, নেতৃত্ব / প্রধানমন্ত্রী নয় not
মাইকেল কে

উত্তর:


17

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

অথবা তারা কেবল এই অজুহাত দিয়ে ধারণাটি প্রত্যাখ্যান করার চেষ্টা করছেন?

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

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

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


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

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

'এখনই শুরু করুন' বলার জন্য +1। বিলম্বকে পরাজিত করার একমাত্র উপায় আইএমই।
মাইকেল কে

5

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

কোড পর্যালোচনার মূলটি হ'ল আপনি যত তাড়াতাড়ি সম্ভব যতটা সম্ভব কোডটি পর্যালোচনা করতে চান। এইভাবে পর্যালোচনা করার জন্য সময় পাওয়া সহজ, কোডটি মানুষের মনে সতেজ, এবং প্রস্তাবিত উন্নতিগুলি কার্যকর করা সহজ হবে। চূড়ান্তভাবে আপনি প্রতিটি একক চেক-ইন পর্যালোচনা করতে চান। এটি স্বয়ংক্রিয় করার একটি ভালো সরঞ্জাম হ'ল http://code.google.com/appengine/articles/rietveld.html । এটি গুগল অভ্যন্তরীণভাবে কোড পর্যালোচনাটিকে প্রতিটি চেক-ইন করার সাথে জোর করতে ব্যবহার করে এমন একটি সরঞ্জামের বৈকল্পিক।

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

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


প্রকৃত গবেষণার ফলাফলের জন্য +1। আপনার আইবিএম পৃষ্ঠাগুলির কোনও লিঙ্ক আছে?
l0b0

তাদের সাথে আমার কোনও লিঙ্ক নেই, তবে কোড কমপ্লিট
btilly

3

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

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

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


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

বেশ কঠোর উত্তর!
মার্সি

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

1

বিকাশকারীদের ইচ্ছার বিরুদ্ধে টিডিডি প্রবর্তন করা হ'ল দুর্বল। টিডিডি ভালবাসা শেখা একটি কঠিন উপায়।

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

এই টিডিডি বিকাশ একটি কোডরিউভের জন্য একটি ভাল সূচনা পয়েন্ট। কীভাবে টিডিডি প্রোগ্রামের আর্কিটেকচারকে প্রভাবিত করেছিল এবং কীভাবে এটি সফ্টওয়্যারমেট্যান্যান্সকে সহজ করে দেয় Disc

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