কোনও বিকাশকারীকে তার কাজের ধারাবাহিকভাবে অগ্রাহ্য করার সাথে মোকাবিলা করা

25

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

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

আমি জানি না তার সাথে কী করব এবং কীভাবে তাকে এই সমস্যাটি কাটিয়ে উঠতে সহায়তা করা যায়। সম্ভবত আরও অভিজ্ঞ কেউ পরামর্শ দিতে পারে?

code-quality

— অ্যালেক্স এন।
সূত্র

11

কাউকে তার কোডটি ইউনিট পরীক্ষাগুলির সাথে কভার করতে বলুন।

— চাকরী

8

কোডটি পরীক্ষার জন্য সর্বোত্তম যোগ্য ব্যক্তি এর লেখক।

16

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

— জেমস পি। রাইট

2

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

— মরগান হের্লোকার

19

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

— টমাস ওভেনস

29

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

কিছু বিবরণ:

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

— ম্যাথু রোডাটাস
সূত্র

আমেন, আরও ভাল, প্রত্যেকেরই তাদের কোড টেস্ট-প্রথমে লিখতে হবে। একটি বিডিডি কাঠামো ব্যবহার করে সাধারণত এর ব্যথা হ্রাস পায়

— জর্জ মাউয়ার

@ জর্জ ভাল ধারণা। টিডিডি এখানে আরও বেশি সাহায্য করবে।

— ম্যাথু রডাটাস

3

- ইউনিট টেস্টিং গবেষনার বাগ সম্পর্কে নয় blog.stevensanderson.com/2009/08/24/...

— Dainius

1

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

— ম্যাথু রোডাটাস

After some amount of feedback from his team about missed edge cases, he will probably learn to consider thoseবিকাশকারীদের যাদের খারাপ অভ্যাস রয়েছে তারা প্রায়শই ভাল অনুশীলনের জন্য প্রয়োজনীয় অতিরিক্ত প্রচেষ্টার অপ্রাসঙ্গিকতার তর্ক করেন (কারণ তারা এটি করার সুবিধা দেখেন না)। আপনি যখন অতিরিক্ত প্রান্তের কেসগুলি যুক্ত করবেন তখন বিকাশকারীরা তাদের সাথে পরিচিত হতে পারে, তার অর্থ এই নয় যে তিনি মনে করেন এটি প্রাসঙ্গিক বা তিনি নিজে সেগুলি যুক্ত করতে চলেছেন কিনা।

— ফ্ল্যাটার

23

তাকে একটি চেকলিস্ট দিন, যেমন

নাল ইনপুট
ব্যাপ্তির চূড়ান্ত বৃহত প্রান্তে ইনপুট
সীমার চূড়ান্ত ছোট প্রান্তে ইনপুট
সমন্বয়
অনুমিত আক্রমণকারীদের লঙ্ঘনকারী ইনপুট (উদাহরণস্বরূপ x = y)

কিউএ লোকেরা চেকলিস্টটি তৈরি করতে সহায়তা করতে পারে

সমস্ত বিকাশকারীকে চেকলিস্টটি দিন, কেবল এটিই নয়।

— স্টিভেন এ লো
সূত্র

1

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

— হতাশ

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

— অ্যালেক্স এন।

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

— স্টিভেন এ। লো

4

আপনার ডেভস চেকলিস্ট ব্যবহার করবে না? যদি একটি চেকলিস্ট জীবন বাঁচাতে পারে, তারা কি সেগুলি ব্যবহার করবে? অনেক ডাক্তার তা করেন না এবং রোগীরা ভোগেন। এটি পড়ুন: newyorker.com/reporting/2007/12/10/071210fa_fact_gawande

— ব্যারি ব্রাউন

1

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

— অ্যালেক্স এন।

17

ভাল ইঞ্জিনিয়ার।

ঠিক আছে.

তবে তার সাথে একটি সমস্যা রয়েছে - খুব প্রায়ই তিনি তার কোডটিতে এজ কেসগুলিতে সম্বোধন করতে ব্যর্থ হন।

এটি এমন একটি মানের যা ভাল ইঞ্জিনিয়াররা ভাগ করে না।

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

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

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

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

6

+1 এটি এমন একটি দক্ষতা যা কিছু লোকের কিছু লোক থাকে যাতে একটি ভাল প্রোগ্রামার হতে শিখতে হয়। তবে, আমি লক্ষ করব যে প্রান্তের দুই প্রকারের মামলা রয়েছে: ব্যবসায়ের প্রয়োজনীয় প্রান্তের কেসগুলি ("যদি আমরা ২ left টি বাম প্রশিক্ষক এবং ২৮ টি সঠিক প্রশিক্ষককে অর্ডার করি তবে সম্ভবত এটি ভুল") যা প্রকল্পের প্রয়োজনীয়তার সাথে মোকাবিলা করা উচিত actual এজ কোডগুলি (অবৈধ ইনপুটগুলির সাথে ডিল করা, ক্রমাগত তালিকার মাধ্যমে পুনরায় পুনরুক্তি করা যখন একটি হ্যাশসেট সেট এক্স এর চেয়ে বড় হয়ে ওঠে তখন আরও বোধগম্য হবে) যা আপনার সম্পর্কে শিখতে হবে এমন আরও কিছু something

— এড জেমস

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

— অ্যালেক্স এন।

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

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

— মাইক পার্টরিজ

5

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

— PSU_Kardi
সূত্র

4

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

— কেভিন ক্লাইন
সূত্র

3

বৈশিষ্ট্য বিকাশে প্রারম্ভিক পর্যায়ে QA জড়িত হওয়া কি তাকে কভার করার শুরুতে প্রান্তের মামলার একটি তালিকা সরবরাহ করতে সহায়তা করে? যদিও কেউ কেউ এটি বিকাশকারীকে সবকিছু coverেকে রাখার প্রত্যাশা না করে দেখছে, এটি যদি কোনও পরীক্ষক প্রাথমিকভাবে ভালভাবে ধরতে পারে তবে এই সীমানা কেস মিস করতে ঝোঁকেন তবে এটি এই আশপাশে কাজ করার একটি উপায় হতে পারে।

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

— জেবি কিং
সূত্র

3

অসীম সংখ্যক প্রান্তের কেস রয়েছে, তাদের সমস্তকে আচ্ছাদন করা অসম্ভব। কেউ যদি করে #define TRUE FALSE? এটি প্রান্তের কেস যুক্ত করে, আপনিও কি তা পরীক্ষা করে দেখবেন?

এছাড়াও, আমি কোনও ব্যক্তিগত শ্রেণি বা অভ্যন্তরীণ ফাংশনের প্রতিটি ফাংশন বোকা-প্রুফিং বিবেচনা করব না।

কোডের জন্য আমি যে পদ্ধতিটি বেছে নিচ্ছি তা হ'ল খুব শক্ত এবং স্থিতিশীল হতে হবে:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

এইভাবে আপনি কিউএতে দৃ application় অ্যাপ্লিকেশন ডাম্প পান এবং আপনি যখন একটি রিলিজ পেয়ে যাবেন তখন অ্যাপটি শক্ত এবং নিরাপদ safe

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

— সংকেতপদ্ধতিরচয়িতা
সূত্র

# সত্য সত্য মিথ্যা একটি প্রান্ত মামলা নয়, এটি একটি বরখাস্ত অপরাধ।

— gnasher729

1

যদি এটি একটি প্রান্তের কেস হয় তবে এটি কি বিবেচনা করাও দরকার? প্রান্তের মামলাগুলি যদি গুরুত্বপূর্ণ হয় তবে প্রান্তের কেসগুলি প্রয়োজনীয়তা / বৈশিষ্ট্য / ব্যবহারকারীর গল্পে খাওয়ানো দরকার।

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

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

— Bronumski
সূত্র

সর্বদা প্রান্তের মামলা রয়েছে। যদি কেউ দাবি করে যে প্রান্তের মামলাগুলি কখনও সম্মুখীন হবে না, তবে এটি সঠিক প্রান্তের মামলা নয় cases

— ব্যারি ব্রাউন

1

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

— ব্রোনমস্কি

1

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

— মরগান হের্লোকার
সূত্র

1

এটি সত্যই সঠিক উত্তর নয়। অর্ধ মানের কাজের আউটপুট দেওয়ার জন্য পুরস্কৃত হওয়া খারাপ অভ্যাস। উন্নয়ন দলের সামগ্রিকভাবে উচ্চমানের কাজের জন্য দায়বদ্ধ হওয়া উচিত।

— ডেভিড

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

— gnasher729

0

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

— বিল্লাল বেগেরাদজ
সূত্র