আমি কীভাবে অজানাভাবে সদৃশ কোডটি প্রতিরোধ করব?


33

আমি বরং একটি বৃহত্তর কোড বেসে কাজ করি। কয়েকশ শ্রেণি, বিভিন্ন ফাইল, প্রচুর কার্যকারিতা, একটি তাজা অনুলিপি টানতে 15 মিনিটেরও বেশি সময় নেয় etc.

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

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

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

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

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


উত্তর:


30

এর সহজ উত্তরটি হ'ল আপনি আসলে কোড নকল রোধ করতে পারবেন না। তবে আপনি একটি কঠিন ক্রমাগত পুনরাবৃত্তিমূলক ক্রমবর্ধমান প্রক্রিয়া যা "দুটি ধাপে ফোটায়" এর মাধ্যমে "এটি ঠিক" করতে পারেন:

পদক্ষেপ 1. উত্তরাধিকার কোডে পরীক্ষাগুলি লিখতে শুরু করুন (পছন্দসই পরীক্ষার কাঠামো ব্যবহার করে)

পদক্ষেপ 2. আপনি পরীক্ষাগুলি থেকে যা শিখেছেন তা ব্যবহার করে নকল করা কোডটি পুনর্লিখন / রিফ্যাক্টর

সদৃশ কোড সনাক্ত করতে আপনি স্থিতিশীল বিশ্লেষণ সরঞ্জামগুলি ব্যবহার করতে পারেন এবং সি # এর জন্য এমন অনেকগুলি সরঞ্জাম রয়েছে যা আপনার জন্য এটি করতে পারে:

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

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

  1. পরিবর্তন পয়েন্টগুলি চিহ্নিত করুন
  2. পরীক্ষার পয়েন্টগুলি সন্ধান করুন
  3. নির্ভরতা বিরতি
  4. পরীক্ষা লিখুন
  5. পরিবর্তন এবং অশোধক করুন

আপনি যদি বাদামি-ক্ষেত্রের বিকাশ, অর্থাৎ পরিবর্তনের প্রয়োজন এমন লিগ্যাসি কোড নিয়ে কাজ করছেন তবে বইটি ভাল পড়ে।

এক্ষেত্রে

ও.পি. এর ক্ষেত্রে আমি কল্পনা করতে পারি অস্ট্রেশযোগ্য কোডটি "ইউটিলিটি পদ্ধতি এবং কৌশল" এর জন্য একটি মধু পাত্র দ্বারা সৃষ্ট যা বিভিন্ন ফর্ম গ্রহণ করে:

  • স্থির পদ্ধতি
  • স্থিতিশীল সম্পদ ব্যবহার
  • একক ক্লাস
  • যাদু মান

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

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

যেহেতু কোডটি কোডটিতে ওপিটি নতুন , আপনার কিছু করার আগে আরও কিছু করণীয় রয়েছে:

  • কোডবেস থেকে শিখতে সময় নিন, অর্থাত্ "সবকিছু" ভাঙ্গুন, "সবকিছু" পরীক্ষা করুন, প্রত্যাবর্তন করুন।
  • প্রতিশ্রুতি দেওয়ার আগে দলটির কাউকে আপনার কোডটি পর্যালোচনা করতে বলুন। ;-)

শুভকামনা!


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

@ এয়ারলজ: স্ট্যাটিক কোড বিশ্লেষণ দুর্দান্ত! ;-) এছাড়াও, যখনই আপনাকে এই পরিবর্তনটি করা দরকার, পরিবর্তনগুলি আরও সহজ করার জন্য সমাধানগুলি সম্পর্কে চিন্তা করুন (এর জন্য প্যাটার্ন ক্যাটালগের রিফ্যাক্টরটি পরীক্ষা করুন)
স্পোইক

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

2

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

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

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

ধারণাগত এবং প্রযুক্তিগত

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

অন্যান্য প্রাথমিক প্রযুক্তিগত অসুবিধা অন্তর্ভুক্ত

  • পুনরায় ব্যবহারযোগ্য উপাদানটি কী গঠন করে তাতে সম্মত।
  • কোন উপাদান কী করে এবং কীভাবে এটি ব্যবহার করবে তা বোঝা।
  • একটি ডিজাইনের বাকী অংশে কীভাবে পুনরায় ব্যবহারযোগ্য উপাদানগুলিকে ইন্টারফেস করতে হবে তা বোঝা।
  • পুনরায় ব্যবহারযোগ্য উপাদানগুলি ডিজাইন করা যাতে তারা নিয়ন্ত্রিত উপায়ে অভিযোজিত এবং সংশোধন করা সহজ হয়।
  • একটি সংগ্রহস্থল সংগঠিত করা যাতে প্রোগ্রামাররা তাদের প্রয়োজনীয় জিনিসগুলি খুঁজে পেতে ও ব্যবহার করতে পারে।

লেখকের মতে, কোনও সংস্থার পরিপক্কতার উপর নির্ভর করে বিভিন্ন স্তরের পুনরায় ব্যবহারযোগ্যতা ঘটে।

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

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


1

সম্ভাব্য 2 টি সমাধান রয়েছে:

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

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

আমি ব্যক্তিগতভাবে মনে করি না যে প্রতিরোধ সম্ভব। আপনি যত বেশি চেষ্টা করবেন, ইতিমধ্যে বিদ্যমান বৈশিষ্ট্যগুলি খুঁজে পেতে সমস্যা তত বেশি।


0

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

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

আমি সাধারণত বিদ্যমান কোডটির সদৃশ অপসারণ শুরু করি তবেই যদি নকল করা অংশগুলি থেকে বড় ত্রুটি দেখা দেয়।


0

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

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

একটি ভাল পন্থা হ'ল কোডটি পুনর্লিখন করা যা মনে হয় যে কোনও স্থির বাগের কারণে আপনাকে ঠিক করতে হবে এমন প্রথমটি পুনরায় লিখে লিখে অনেক জায়গায় নকল / আটকানো হয়েছে। জেনারিক্স ব্যবহার করতে এটি পুনরায় লিখুন এবং খুব কঠোর পরীক্ষার কোডও লিখুন।

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

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

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

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

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

এবং হ্যাঁ, আমি কোডটির স্বয়ংক্রিয় পরীক্ষার পক্ষে। এটি শুরুতে আরও বেশি ব্যয় করবে তবে এটি অবশ্যই আপনাকে সামগ্রিকভাবে অবিচ্ছিন্ন সময় সাশ্রয় করবে। এবং জেনেরিক কোডের জন্য কমপক্ষে 80% এবং 100% সামগ্রিকভাবে একটি কোড কভারেজ অর্জন করার চেষ্টা করুন।

আশা করি এটি সাহায্য করবে এবং সৌভাগ্য হবে।


0

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

যদি, বলুন, আপনি আমাকে ব্যবহারের বিকল্পটি দিন:

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

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

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

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

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


-2

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

এর তিনটি কারণ থাকতে পারে:

  1. উভয় মডিউলের জন্য এই টাস্কের কিছু থিম একইরকম। এই ক্ষেত্রে কোড সদৃশটি খারাপ এবং তরল করা উচিত। এই থিমটি সমর্থন করার জন্য একটি ক্লাস বা মডিউল তৈরি করা এবং উভয় মডিউলে এর পদ্ধতিগুলি ব্যবহার করা চালাক হবে।

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

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

এবং এই 3 য় কেস খুব প্রায়ই ঘটে। আপনি যদি "অজান্তে" নকল করে থাকেন তবে বেশিরভাগ ক্ষেত্রে এটি একই কারণে - এটি আসল সদৃশ নয়!

সুতরাং, এটি যখন প্রয়োজনীয় প্রয়োজন হয় তখন এটি পরিষ্কার রাখার চেষ্টা করুন এবং এটি প্রয়োজনীয় না হলে সদৃশ হওয়ার ভয় পাবেন না।


2
code duplication is not always harmfulএকটি দরিদ্র পরামর্শ।
তুলাইনস কর্ডোভা

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

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

আমি করেছি এখানে আর্গুমেন্ট করা। আপনি না। কর্তৃপক্ষের রেফারেন্স 16 শতকের পর থেকে কাজ করবে না। আপনি গ্যারান্টি দিতে পারবেন না যে আপনি সেগুলি সঠিকভাবে বুঝতে পেরেছেন এবং তারাও আমার পক্ষে কর্তৃপক্ষ।
গাংনাস

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