সম্পূর্ণ রিফ্যাক্টরিংয়ের সময় না থাকলে লিগ্যাসি কোডের জন্য পরীক্ষাগুলি লেখার কী অর্থ হয়?

Question

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

একজন সহকর্মী বলেন যে আমার এটি করা উচিত নয়। তাঁর যুক্তি:

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

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

Comments

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

— ডক ব্রাউন

কোডটির অন্যান্য অংশগুলি কোনও বৈশিষ্ট্যে রূপান্তরিত করে কোনও বাগ হিসাবে নির্ভর করা যেতে পারে

— ratchet freak

আমি ভাবতে পারি এর বিরুদ্ধে একমাত্র ভাল যুক্তি হ'ল আপনি যদি কিছু ভুল / ভুল লিখে ফেলে থাকেন তবে আপনার রিফেক্টরিং নিজেই নতুন বাগ প্রবর্তন করতে পারে। সেই কারণে আমি বর্তমানে বিকাশের অধীনে থাকা সংস্করণটিতে আমার হৃদয়ের সামগ্রীগুলিকে সংশোধন করতে এবং ঠিক করতে মুক্ত - তবে অতীতের সংস্করণগুলিতে যে কোনও সংশোধন করা হয়েছে তার চেয়ে অনেক বেশি বাধা রয়েছে এবং যদি তারা কেবল "কসমেটিক / স্ট্রাকচারাল ক্লিনআপ" হয় তবে তা অনুমোদিত হবে না may ঝুঁকিটিকে সম্ভাব্য লাভের চেয়ে বেশি বলে মনে করা হয়। আপনার স্থানীয় সংস্কৃতিটি সম্পর্কে জানুন - এটি সম্পর্কে কেবল একটি গরু-অর্কের ধারণা নয় - এবং অন্য কিছু করার আগে খুব দৃ strong় কারণ প্রস্তুত রয়েছে।

— কেশলাম

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

— ক্রিস্টোফার ক্রিউটজিগ

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

— জুলিয়া হ্যাওয়ার্ড

Answer 1

এখানে আমার ব্যক্তিগত অবৈজ্ঞানিক ধারণা: তিনটি কারণই বিস্তৃত তবে ভ্রান্ত জ্ঞানীয় মায়াজালের মতো শোনাচ্ছে।

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

Comments

+1 এর জন্য "কার্যত সমস্ত গুরুতর ত্রুটিগুলি প্রতিশ্রুতিবদ্ধ কারণ লোকেরা ভেবেছিল যে তারা বাস্তবে যা করেছে তার চেয়ে আরও ভাল কিছু তারা বোঝে"

— রিম

প্রথম পয়েন্ট - বিডিডি সহ , পরীক্ষাগুলি স্ব নথিভুক্ত হয় ...

— রবি ডি

@ গুইলিউম ৩১ হিসাবে উল্লেখ করা হয়েছে যে লেখার পরীক্ষার মানের একটি অংশটি কোডটি বাস্তবে কীভাবে কাজ করে তা দেখিয়ে দিচ্ছে - যা স্পেসিফিকেশন (গুলি) অনুসারে বা নাও হতে পারে। তবে এটি অনুমান হতে পারে যা "ভুল": ব্যবসায়ের চাহিদা পরিবর্তিত হতে পারে এবং কোডটি নতুন প্রয়োজনীয়তার প্রতিফলন করে তবে অনুমানটি তা করে না। কেবল কোডটিকে "ভুল" বলে ধরে নেওয়া মাত্রাতিরিক্ত সরলতর (পয়েন্ট 1 দেখুন)। এবং আবার পরীক্ষাগুলি আপনাকে জানায় যে কোডটি আসলে কী করে, কেউ কী ভাবেন / বলেন যা তা করে না (পয়েন্ট ২ দেখুন)।

— ডেভিড

এমনকি যদি আপনি একটি দৌড়ঝাঁপ করেন তবে আপনার কোডটি বুঝতে হবে। পরীক্ষাগুলি আপনাকে অপ্রত্যাশিত আচরণ ধরতে সহায়তা করবে এমনকি আপনি রিফেক্টর না দিয়ে পুনরায় লেখালেখি করুন (এবং যদি আপনি চুল্লী করেন তবে তারা নিশ্চিত করতে সহায়তা করে যে আপনার রিফেক্টরিং উত্তরাধিকার আচরণটি ভাঙ্গবে না - বা কেবল যেখানে আপনি এটি ভাঙতে চান)। নিখরচায় অন্তর্ভুক্ত করুন বা না - আপনার ইচ্ছানুসারে।

— ফ্রাঙ্ক হপকিন্স

Answer 2

কয়েকটি চিন্তা:

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

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

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

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

Comments

জন্য +1 "পরীক্ষার আপনি লিখতে প্রোগ্রামের পরীক্ষা বর্তমান আচরণ "

— ডেভিড

Answer 3

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

Comments

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

— কোডটিকে

Answer 4

কিলিয়ান এর উত্তর সর্বাধিক গুরুত্বপূর্ণ দিকটি অন্তর্ভুক্ত করে তবে আমি 1 এবং 3 পয়েন্টে প্রসারিত করতে চাই।

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

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

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

৩ য় পয়েন্টের কিছু চিন্তাভাবনাও: "বিগলিত সাফল্য" খুব কমই ঘটেছিল, এ ছাড়াও আরও একটি বিষয় রয়েছে: এটি আসলে সহজ নয়। আরও সহজ হতে, বেশ কয়েকটি শর্ত প্রয়োগ করতে হবে:

• রিফ্যাক্টর করার জন্য অ্যান্টিপ্যাটার্ন সহজেই খুঁজে পাওয়া দরকার। আপনার সমস্ত একক নামকরণ করা হয় XYZSingleton? তাদের উদাহরণ সবসময় বলা হয় getInstance()? এবং কীভাবে আপনি আপনার অতিরিক্ত গভীর শ্রেণিবিন্যাস খুঁজে পাবেন? আপনি কীভাবে আপনার godশ্বরের জিনিসগুলি অনুসন্ধান করবেন? এগুলির জন্য কোড মেট্রিক্স বিশ্লেষণ এবং তারপরে ম্যাট্রিকগুলি ম্যানুয়ালি পরিদর্শন করা দরকার। অথবা আপনি যেমন কাজ করেছিলেন ঠিক তেমনই তাদেরকে হোঁচট খাচ্ছেন।
• রিফ্যাক্টরিংটি যান্ত্রিক হওয়া দরকার। বেশিরভাগ ক্ষেত্রেই, রিফ্যাক্টরিংয়ের শক্ত অংশটি বিদ্যমান কোডটি কীভাবে এটি পরিবর্তন করতে হয় তা ভালভাবে বুঝতে পারে। আবার সিলেটলেটস: যদি সিঙ্গলটন চলে যায় তবে আপনি কীভাবে এর ব্যবহারকারীদের প্রয়োজনীয় তথ্য পাবেন? এর অর্থ প্রায়শই স্থানীয় কলগ্রাফ বোঝা হয় যাতে আপনি কোথা থেকে তথ্য পাবেন তা আপনি জানেন। এখন সহজ কী: আপনার অ্যাপে দশটি সিঙ্গেলন সন্ধান করা, প্রতিটিটির ব্যবহার বুঝতে (যা কোডবেজের 60% বোঝার প্রয়োজন হয়) এবং সেগুলি ছিঁড়ে ফেলা হয়? বা আপনি ইতিমধ্যে বুঝতে পেরেছেন এমন কোডটি গ্রহণ করছেন (কারণ আপনি এখনই এটিতে কাজ করছেন) এবং সেখানে ব্যবহৃত সিঙ্গলটগুলি ছিঁড়ে ফেলা হচ্ছে? যদি রিফ্যাক্টরিংটি এতটা যান্ত্রিক না হয় যে এর আশেপাশের কোড সম্পর্কে অল্প জ্ঞানের প্রয়োজন হয় তবে এটি গুছিয়ে দেওয়ার কোনও ব্যবহার নেই।
• রিফ্যাক্টরিংটি স্বয়ংক্রিয় করা দরকার। এটি কিছুটা মতামত ভিত্তিক, তবে এখানে যায়। কিছুটা রিফ্যাক্টরিং মজাদার এবং সন্তোষজনক। প্রচুর রিফ্যাক্টরিং ক্লান্তিকর এবং বিরক্তিকর। আপনি সবেমাত্র আরও ভাল অবস্থানে কাজ করেছেন এমন কোডের টুকরোটি ছেড়ে দেওয়া আপনাকে আরও আকর্ষণীয় স্টাফগুলিতে যাওয়ার আগে আপনাকে একটি সুন্দর, উষ্ণ অনুভূতি দেয়। একটি সম্পূর্ণ কোড বেসটি রিফ্যাক্টর করার চেষ্টা করা আপনাকে হতাশ এবং ক্ষুব্ধ ছেড়ে দেবে এমন ইডিয়ট প্রোগ্রামারগুলিতে যারা এটি লিখেছিল। আপনি যদি একটি বড় সাউপ রিফ্যাক্টরিং করতে চান তবে হতাশা হ্রাস করতে এটি বেশিরভাগ স্বয়ংক্রিয়ভাবে হওয়া দরকার। এটি একরকমভাবে প্রথম দুটি পয়েন্টের একটি মিশ্রণ: আপনি কেবলমাত্র বাজে কোডটি (যেমন সহজেই পাওয়া গেছে) সন্ধান করতে স্বয়ংক্রিয় করতে পারলে রিফ্যাক্টরিং স্বয়ংক্রিয় করতে পারেন এবং এটি পরিবর্তন করে (অর্থাত্ যান্ত্রিক) স্বয়ংক্রিয় করতে পারেন।
• ধীরে ধীরে উন্নতি আরও ভাল ব্যবসায়ের ক্ষেত্রে তৈরি করে। বড় জাল রিফ্যাক্টরিং অবিশ্বাস্যরূপে বাধাদানকারী। আপনি যদি কোনও কোডের টুকরোটি রিফ্যাক্টর করেন তবে আপনি এটিতে কাজ করা অন্যান্য ব্যক্তির সাথে অবিচ্ছিন্নভাবে বিভক্ত হয়ে পড়েন, কারণ আপনি কেবল সেই পদ্ধতিটি বিভক্ত করেছেন যে তারা পাঁচটি অংশে পরিবর্তিত হয়েছিল। আপনি যখন একটি যুক্তিসঙ্গত আকারের কোডের টুকরোটি রিফ্যাক্টর করেন তখন আপনি কয়েকটি লোকের সাথে দ্বন্দ্ব পান (600০০-লাইনের মেগাফ্যাঙ্কন বিভক্ত করার সময় 1-2, গড অবজেক্টটি ভেঙে ফেললে 2-4, মডিউল থেকে সিঙ্গলটনকে ছিটিয়ে দেওয়ার সময় 5 ), তবে আপনার মূল সম্পাদনাগুলির কারণে আপনার সেই দ্বন্দ্বগুলি হতে পারে। আপনি যখন কোনও কোডবেস-ওয়াইড রিফ্যাক্টরিং করেন তখন আপনি সবার সাথে বিরোধ করেন। এটি কয়েক বিকাশকারীকে কয়েক দিনের জন্য জুড়ে দেয় তা উল্লেখ করার দরকার নেই। ধীরে ধীরে উন্নতি প্রতিটি কোড সংশোধনকে কিছুটা বেশি সময় নেয়। এটি এটিকে আরও অনুমানযোগ্য করে তোলে এবং পরিষ্কার-পরিচ্ছন্নতা ব্যতীত আর কিছুই ঘটে না এমন দৃশ্যমান সময়কাল নেই।

Answer 5

কিছু সংস্থায় একটি সংস্কৃতি রয়েছে যেখানে তারা বিকাশকারীদের যে কোনও সময় কোড বাড়ানোর অনুমতি দেয় যা সরাসরি অতিরিক্ত মান যেমন নতুন কার্যকারিতা সরবরাহ করে না তাকে তত্পর করে।

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

আমি ব্যক্তিগতভাবে বয় স্কাউট নীতিটির সাবস্ক্রাইব করি তবে অন্যরা (যেমন আপনি দেখেছেন) তা করেন না।

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

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

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

Comments

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

— ওজ

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

— ওজ

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

— রবি ডি

Answer 6

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

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

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

Answer 7

উত্তর: "মূল কোডটি সঠিকভাবে কাজ না করে":

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

Comments

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

— সিএওও

Answer 8

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

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

যদি আমি মনে করি সঠিকভাবে রিফ্যাক্টরিং বইটি যেভাবেই হোক নিরন্তর পরীক্ষা করতে বলে। সুতরাং এটি প্রক্রিয়াটির অংশ part

Answer 9

স্বয়ংক্রিয় পরীক্ষার কভারেজ করুন।

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

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

আপনার বিনিয়োগের পরিমাণ সীমাবদ্ধ করা সম্ভবত উপযুক্ত।

Answer 10

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

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

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

IntegrationTestCase1()
{
    var input = ReadDataFile("path\to\test\data\case1in.ext");
    bool validInput = ValidateData(input);
    Assert.IsTrue(validInput);

    var processedData = ProcessData(input);
    Assert.AreEqual(0, processedData.Errors.Count);

    bool writeError = WriteFile(processedData, "temp\file.ext");
    Assert.IsFalse(writeError);

    bool filesAreEqual = CompareFiles("temp\file.ext", "path\to\test\data\case1out.ext");
    Assert.IsTrue(filesAreEqual);
}

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

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