এমন কোনও সফ্টওয়্যার ইঞ্জিনিয়ারিং নীতি আছে যা কোনও প্রোডাকশন সিস্টেমে পুনরায় ব্যবহার এবং রিগ্রেশন পরীক্ষার ব্যয় সম্পর্কিত?

Question

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

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

আমার প্রশ্নটি কি এমন কোনও সফ্টওয়্যার ইঞ্জিনিয়ারিং নীতি রয়েছে যা পুনরায় ব্যবহার এবং রিগ্রেশন পরীক্ষার ব্যয়ের মধ্যকার সম্পর্ককে বর্ণনা করে?

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

অনুমিতি:

1. 'রিগ্রেশন টেস্ট' এর অর্থ 'গ্রহণযোগ্যতা পরীক্ষা' - অর্থাত্ পরিবেশ ও ডেটা সেটআপগুলি সহ ব্যবসায়ের পক্ষে সিস্টেমের বিরুদ্ধে নতুন লিখতে এবং পুরাতন পরীক্ষাগুলির পুনরায় ব্যবহার করতে আরেকটি গ্রুপ ব্যয় করে।

2. আমি জানি একটি বড় রিগ্রেশন টেস্ট ব্যয়ের জন্য হাঁটু-ঝাঁকুনির প্রতিক্রিয়া হ'ল আরও বেশি স্বয়ংক্রিয় পরীক্ষা। এটি একটি ভাল নীতি। এই পরিবেশে বেশ কয়েকটি চ্যালেঞ্জ রয়েছে।

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

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

   (গ) স্বয়ংক্রিয় পরীক্ষাগুলি বজায় রাখার ব্যয় কোনও প্রকল্পে লুকানো থাকে এবং তাই এগুলি সহজেই প্রকল্প পর্যায়ে ফেলে দেওয়া হয়।

   (d) এটি কেবল একটি ব্যাংকে কাজ করার সাংস্কৃতিক বাস্তবতা।

   (ঙ) আমি এই সমস্যাটি অন্যভাবে (পচন) সমাধান করার জন্য কাজ করছি।

Comments

আপনি হাতের তরঙ্গ বিবৃতি দিয়েছেন যে " আমরা পর্যবেক্ষণ […] যে আমরা যত বেশি 'পুনরায় ব্যবহার' করব, তত বেশি [গ্রহণযোগ্যতা] পরীক্ষার ব্যয় আরও বাড়বে" - আপনি কি এটিকে প্রসারিত করতে পারবেন? কোনও গ্রহণযোগ্যতা পরীক্ষা উত্তরাধিকারক্রমের স্তরক্রমের মতো বাস্তবায়নের বিশদটির অজ্ঞেয়াদী হওয়া উচিত নয়, এবং পরিবর্তে ব্যবহারের পরিস্থিতিগুলির মধ্যে দিয়ে খেলা উচিত?

— আমন

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

— ডক ব্রাউন

ধন্যবাদ যে সহায়ক। আমি ওওর রেফারেন্সগুলি সরিয়েছি - এবং ভাগ করা কোড, (বা এমন কোড যা ভাগ করে নেওয়া কোড হয়ে যাবে) স্পর্শ করার ধারণাটি প্রসারিত করেছি।

— হক্কে

বর্তমান ফর্মটিতে, আমি অনুমান করি যে আমি আপনার প্রশ্নের ঠিক "না, আমি এটি মনে করি না" - যা আমার ধারণা আপনার পক্ষে খুব সন্তুষ্ট হবে না answer বা কিছু স্ব-তৈরি পুনঃব্যবহারযোগ্য উপাদানগুলির সাথে আপনার মতো একটি বৃহত সিস্টেম তৈরি করার সময় আপনি পরীক্ষার ব্যয় হ্রাস করার জন্য নীতি এবং রীতিগুলিতে আগ্রহী?

— ডক ব্রাউন

Answer 1

আমরা যে কোডটি ভাগ করে নিতে পারি তা সংশোধন করতে চাই না, কারণ এটির ফলে একটি বড় রিগ্রেশন পরীক্ষার প্রভাব পড়বে

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

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

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

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

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

---

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

কেবলমাত্র এই দুটি বিকল্পের সীমাবদ্ধ করা অপ্রয়োজনীয় এবং, আবার আপনি কীভাবে জেডিকে ব্যবহার করেন তাতে কীভাবে এটি আরও ভালভাবে করা যায় তার উদাহরণগুলি খুঁজে পেতে পারেন। কটাক্ষপাত java.util.concurrentপ্যাকেজ ( JSR 166 ) - পর্যন্ত জাভা 5 রিলিজ, এই একটি পৃথক গ্রন্থাগার, না কোর JDK রিলিজের একটি অংশ ছিল।

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

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

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

---

ভারী পুনঃব্যবহৃত কোড পরিবর্তনের ক্ষেত্রে কতটা প্রচেষ্টা (পরীক্ষাসহ) জড়িত থাকতে পারে তার একটি নিদর্শন উদাহরণ আবার জেডিকে পাওয়া যাবে can 7u6 প্রকাশে তারা অভ্যন্তরীণ Stringউপস্থাপনা পরিবর্তন করেছিল যা substringকার্য সম্পাদনের পরিবর্তে জড়িত । রেডডিট-এ কোনও বৈশিষ্ট্য বিকাশকারীর মন্তব্যগুলি এই পরিবর্তনের সাথে কতটা প্রচেষ্টা জড়িত তা রূপরেখা:

প্রাথমিক বিশ্লেষণ 2007 সালে জিসি গ্রুপ থেকে বেরিয়ে এসেছিল ...

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

আমার উত্তরটি নিখুঁত হওয়ার উদ্দেশ্যে নয় এটি প্রায় ছয় মাস উত্সর্গীকৃত কাজের একটি সংক্ষিপ্তসার ...

Comments

দেখে মনে হচ্ছে আমরা উভয় সমান্তরালে একটি উত্তরের উপর একই রকম চিন্তাভাবনা নিয়ে কাজ করেছি ...

— ডক ব্রাউন

@ ডকব্রাউন হ্যাঁ, এটি আকর্ষণীয় যে আমরা প্রায় একই সাথে উত্তরও দিয়েছিলাম, প্রশ্ন আকারে রূপান্তরিত হওয়ার প্রায় এক ঘন্টা পরে

— gnat

Answer 2

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

তবে আমি এর আগে আপনার মতো পুনঃব্যবহারের কারণে সৃষ্ট সমস্যাগুলি দেখেছি এবং এটি কীভাবে আরও ভালভাবে পরিচালনা করতে হয় সে সম্পর্কে আপনি কিছু চিন্তাভাবনায় আগ্রহী।

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

• এই উপাদানগুলি খুব পরিপক্ক এবং স্থিতিশীল

• এগুলি সম্পূর্ণ আলাদা সংস্থা দ্বারা বিচ্ছিন্ন ও সম্পূর্ণ পরীক্ষিত হয় tested

• (পুনরায়) এগুলি ব্যবহার করতে আপনাকে এগুলি পরিবর্তন করতে হবে না (বাস্তবে আপনি যদি এটি চান তা করতে পারেন না, যেহেতু আপনি উত্স কোডটি বজায় রাখেন না)

• আপনি প্রতিদিন কোনও নতুন সংস্করণ পান না, কেবলমাত্র সামান্য আপডেট (প্রতি মাসে সর্বাধিক), বা প্রতি বছর অন্তর অন্তর বড় আপডেটগুলি

• বেশিরভাগ আপডেটগুলি 100% নিচের দিকে সামঞ্জস্যপূর্ণ ডিজাইন করা হয়েছে, বিশেষত ছোট ছোট আপডেট

সুতরাং আপনার নিজের পুনঃব্যবহারযোগ্য উপাদানগুলিকে আরও সফল করতে আপনার নিজের বিকাশের জন্য উপরের দিক থেকে কিছুটিকে অভিযোজিত করা উচিত:

• যে কোনও পুনঃব্যবহারযোগ্য উপাদানগুলির জন্য, তার একটি পরিষ্কার দায়িত্ব রয়েছে যিনি রক্ষণাবেক্ষণ করেন এবং নিশ্চিত হন যে সমস্যাগুলি পুনরায় ব্যবহার করা সমস্ত লোক তত্ক্ষণাত কোনও বাগফিক্স পেয়েছে কিনা তা নিশ্চিত হতে পারে problems

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

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

• পুনরায় ব্যবহারযোগ্য উপাদানগুলির বিচ্ছিন্নভাবে তাদের পরীক্ষা করতে খুব সম্পূর্ণ টেস্ট স্যুট দরকার।

এই প্রচুর জিনিসগুলির অর্থ হবে যে উপাদানটি নিজেই তৈরি করার ব্যয়টি বাড়বে, তবে এটি ব্যর্থ আবেগের কারণে পরিবর্তিত ব্যয়ও হ্রাস পাবে।

Answer 3

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

এটি প্রত্যাশাজনকভাবে ভবিষ্যতের বাগগুলি হ্রাস করতে পারে এবং বিদ্যমান বৈশিষ্ট্যগুলিতে নতুন বৈশিষ্ট্য বা পরিবর্তনগুলি কার্যকর করা সহজ করা উচিত।

সহজেই, আমার অর্থ তাদের কম সময় নেওয়া উচিত এবং তাই কম ব্যয় করা উচিত।

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

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

এটি বিদ্যমান প্রকল্পের সদস্যদের মনোবলকে উন্নত করতে পারে এমন কর্মীদের টার্নওভারও হ্রাস করতে পারে।

এটি অবশ্যই গ্যারান্টিযুক্ত নয় যে আপনি এই সুবিধাগুলি পাবেন, তবে এগুলি এমন বিষয় যা পরিমাপ করা যেতে পারে এমন ব্যয়ের পাশাপাশি বিবেচনা করা উচিত (বর্ধিত পরীক্ষার মতো) যা মাপা যায় can

প্রকৃতপক্ষে, উন্নত কোডটি শেষ পর্যন্ত সময়ের সাথে পরীক্ষার ব্যয় হ্রাস করা উচিত, এমনকি যদি আপনি যা বর্ণনা করেন তার কারণে প্রাথমিক বৃদ্ধি হয়।