ডিআরওয়াই কেন গুরুত্বপূর্ণ?

Question

একদম সহজ, আমি কেন এমন কোড লিখতে চাই যা সমস্ত ক্ষেত্রে এবং স্কেলযোগ্য ডেটার জন্য কাজ করে যখন আমাকে কিছু করতে হবে কিছু ক্ষুদ্র টুইটের সাথে একই প্রক্রিয়াটি কয়েকবার পুনরাবৃত্তি করতে হবে?

খুব শীঘ্রই এটিকে আবারও সম্পাদনা করার দরকারের সম্ভাবনা আমার নেই।

দেখে মনে হচ্ছে কেবল যেতে অনেক কম কাজ হচ্ছে ...

function doStuff1(){/*.a.*/}
function doStuff2(){/*.b.*/}
function doStuff3(){/*.c.*/}

এবং যদি আমাকে কখনও কিছু যুক্ত করার প্রয়োজন হয় ...

function doStuff4(){/*.d.*/}

এবং যদি আমার এটি অপসারণের প্রয়োজন হয় তবে আমি এটি সরিয়ে দেই।

এই সমস্তগুলিকে কীভাবে সরাসরি-ফরোয়ার্ড প্যাটার্নে পরিণত করা যায় তা যে আমি কেবল ডেটা খাওয়াতে পারি এবং সমস্ত ক্ষেত্রে মোকাবেলা করতে পারি তা বোঝা শক্ত হয়ে যায় এবং এমন একগুচ্ছ পরিবর্তন ঘটায় যা আমি কখনও অনুভব করি না বলে মনে করি না করতে.

যখন তাত্ক্ষণিক কাট + পেস্ট এত কম কাজ হতে চলেছে তখন কেন ডিআরওয়াই হবে?

Comments

কারণ আপনি যখন এটি সঠিকভাবে করেন তখন শুষ্কটি আরও দ্রুত হয়, আপনি যদি একটিতে কোনও ভুল করে থাকেন তবে তাও। যা অন্য সকলকে প্রভাবিত করে

— ড্যানিয়েল লিটল

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

— 9000

আমি মনে করি আপনি এটির সাথে সমষ্টি করতে পারবেন: পরিবর্তনের একক পয়েন্ট বজায় রাখা সহজ easier

— ফ্যালকন

যদি আপনি নিজেই এর উত্তর দিতে না পারেন তবে আপনার বিকাশ এবং প্রধানত্ব সম্পর্কে আরও কিছু বাস্তব বিশ্বের অভিজ্ঞতা নেওয়া দরকার।

— ডেভিড হেফারনান

@ ওয়াইনে আমি উত্সটিতে এক বিরাট ব্যাঘাত অনুভব করেছি, যেন লক্ষ লক্ষ প্রোগ্রামার হঠাৎ সন্ত্রাসে ডেকে উঠলেন।

— ছদ্মবেশে

Answer 1

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

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

আমি সর্বদা ডিআরওয়াইয়ের পক্ষে ভ্রান্ত হই, বিরল ক্ষেত্রে নিজেকে পুনরাবৃত্তি করে যখন আমি মনে করি যে পাঠযোগ্যতার সুবিধাগুলি একাধিক স্থানে বাগ ফিক্স করতে ভুলে যাওয়ার ঝুঁকির পক্ষে মূল্যবান।

সেই পরামর্শটি আমলে নিলে এটি আপনার ক্ষেত্রে মনে হচ্ছে

কয়েকটি ছোটখাটো টুইট দিয়ে একই প্রক্রিয়াটি কয়েকবার পুনরাবৃত্তি করুন

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

যখন তাত্ক্ষণিক কাট + পেস্ট এত কম কাজ হতে চলেছে তখন কেন ডিআরওয়াই হবে?

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

Comments

তবুও, স্পষ্টতই বলতে চাই, আমি শুকনোকে খারাপ প্রস্তাব দিচ্ছি না, এই প্রশ্নটি শয়তানের পক্ষে বেশি। আমি সত্যিই একটি যৌক্তিক প্রতিক্রিয়া খুঁজছি যাঁরা কাট + পেস্ট + টুইঙ্ক কোডটি ভাল বলে মনে করেন তাদের সাথে আমি লিঙ্ক করতে পারি।

— ছদ্মবেশে

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

— ছদ্মবেশে

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

— ম্যাথিউ এম।

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

— সুপারক্যাট

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

— বেনিয়ামিন হজসন

Answer 2

কারণ পরে ডিআরওয়াই কম কাজ করবে।

---

DRY: (নিজেকে পুনরাবৃত্তি করবেন না)

একটি যুক্তি গ্রহণ একটি ফাংশন।

def log(arg):
    print(arg)

সিএন্ডপি: (অনুলিপি করুন এবং পেস্ট করুন)

26 গাজিলিয়ন ফাংশন মূলত একই জিনিসটি করে তবে 2 টি পার্থক্য সহ।

def logA():
    print('a')

def logB():
    print('b')

...ad infinitum...

---

ঠিক কী মুদ্রণ তা নির্দিষ্ট করতে আমরা কীভাবে আমাদের মুদ্রণ আপডেট করব?

শুকনো:

def log(arg):
    print(arg + "Printed from process foo")

সম্পন্ন.

ক & পি:

আপনাকে ফিরে যেতে হবে এবং প্রতিটি একক ক্রিয়াকলাপ পরিবর্তন করতে হবে ।

---

আপনার মনে হয় কোনটি ডিবাগ করা সহজ হবে?

Comments

এছাড়াও, ডুপ্লিকেট ফাংশন হিসাবে আপনাকে অনেকগুলি অনুরূপ পরীক্ষার স্যুট লিখতে হবে।

— 9000

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

— রবার্ট হার্ভে

@ রবার্ট আমি আশা করি না! ধারণাটি আরও ভালভাবে বর্ণনা করার চেষ্টা করার জন্য আমি একটি খুব সাধারণ কাজটি বেছে নিয়েছি এবং কেন এটি ভাল জিনিস হতে পারে।

— জন

@Robert - আপনি এ প্রবন্ধ যে কোন পড়া আছে thedailywtf.com ;) - এখানে এমন কিছু যারা তা করতে যাবে

— HorusKol

@ 9000 আপনার যদি কোনও পরীক্ষার স্যুট না থাকে তবে নয়: পি (যা সাধারণত বেশিরভাগ প্রকল্পের ক্ষেত্রে হতে পারে ... দুর্ভাগ্যক্রমে ...)

— অবিশ্ব

Answer 3

কারণ , আপনার উদাহরণটিতে প্রয়োগ করা হয়েছে:

• + পঠনযোগ্যতা

  কম কোড প্রায়শই কম শব্দে অনুবাদ করে । _{(সর্বদা না ...)}

• নমনীয়তা

  আপনার যদি কখনও এর আচরণ পরিবর্তন করতে হয় তবে doStuffXআপনি নিজেকে বা যে কেউ এটি লিখেছিলেন হত্যা করতে চাইবেন,

• + এক্সটেনসিবিলিটি

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

• + ব্যয় দক্ষতা

  এখানে কম কোডের অর্থ:

  • => কম বিকাশ => ব্যয় হ্রাস
  • => বাগের জন্য কম সম্ভাবনা => কম সমর্থন সময় => হ্রাস খরচ

• + (সম্ভব) পরিচালিত অপ্টিমাইজেশন

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

• + পরীক্ষা এবং মান

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

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

Answer 4

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

বেশিরভাগ প্রোগ্রামিংয়ের জন্য আপনাকে কেবল তাত্ক্ষণিক বর্তমান নয়, ভবিষ্যতের বিষয়ে চিন্তা করা প্রয়োজন। আপনি ঠিক বলেছেন এখনই অনুলিপি এবং পেস্ট করা সহজ, তবে বিবৃতি, খুব শীঘ্রই এগুলি আবার সম্পাদনা করার দরকার নেই " আপনি সঠিকভাবে চিন্তা করছেন না তা দেখায় Yes হ্যাঁ, আপনি নিজের সাথে কিছুটা সময় কিনতে পারেন দ্রুত এবং নোংরা অনুলিপি / পেস্ট করুন, তবে এটি করে আপনি দেখিয়ে দিচ্ছেন যে আপনি আপনার তাত্ক্ষণিক সমস্যার বাইরে দেখতে পারেন না এবং আগামীকাল সম্পর্কে চিন্তা করতে পারেন you আপনি কি ইতিবাচক হন আপনার এই কোডটি পুনরায় দেখার দরকার নেই? আপনি কি জানেন যে এখানে কিছু রয়েছে এটিতে কোনও বাগ নেই? আপনার পরবর্তী বৈশিষ্ট্যগুলির সেটটি কার্যকর করার দরকার হলে আপনি কী এটির পুনর্বিবেচনার প্রয়োজন হবে না 100% গ্যারান্টি দিতে পারেন? সেগুলি আগামীকালের বিষয়, এবং আপনি যখন আজ ডিজাইন করছেন তখন বিবেচনা করা দরকার।

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

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

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

Comments

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

— ছদ্মবেশে

@ পরিচয়, আমি কিছুটা হাস্যকর হওয়ার চেষ্টা করছিলাম :)

— শয্যাশায়ী

Answer 5

খুব শীঘ্রই এটিকে আবারও সম্পাদনা করার দরকারের সম্ভাবনা আমার নেই।

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

আপনি যে সমস্যাটি সমাধান করার চেষ্টা করছেন তা সাধারণীকরণ করতে পারলে আপনার কোডগুলি প্রসারিত করা সহজ করতে এবং বাগগুলি পপ আপ করা থাকলে ঠিক করতে পারেন can

Comments

উত্তম উত্তর, তবে আমি এগুলি থেকে দূরে সরে যেতে পারলেও আমার পরে এটি বজায় রাখার জন্য দরিদ্র স্যাপটির কী হবে? ;)।

— ছদ্মবেশে

দেখুন: "প্রায়শই আপনি যে

— অ্যালেক্স

তারপরেও এটি কেবল ক্ষেত্রে যদি আপনি অনুলিপি করছেন এবং আটকানো যা 100% বাগ-মুক্ত পারফেকশন। এবং এটি না, এবং এটি হতে পারে তা ভাবা বন্ধ করুন।

— ড্যান রায়

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

— অ্যালেক্স

Answer 6

আমি অন্য প্রশ্নের উত্তরে যেমনটি বলেছি, আমার পদ্ধতিটি নিম্নলিখিত:

1. প্রথমবার যখন আমি কোনও নির্দিষ্ট সমস্যার সমাধান করি, আমি কেবল এটি সম্পন্ন করি।
2. দ্বিতীয়বার (অর্থাত্‍ আমি যখন একই ধরণের সমস্যার সমাধান করি) আমার মনে হয়: এইচএম, সম্ভবত আমি নিজেকে পুনরাবৃত্তি করছি তবে আমি আপাতত দ্রুত অনুলিপি-অনুলিপিটি যাব।
3. তৃতীয়বারের মতো আমি মনে করি: এইচএম, আমি নিজেকে পুনরাবৃত্তি করছি -> এটিকে সাধারণ করুন!

অর্থাৎ 2 অবধি, ডিআরওয়ির উপরে আরেকটি নীতি (YAGNI) জিতেছে। তবে 3 (বা 4 থেকে শুরু করে যদি আমি সত্যিই অলস হই!) মনে হয় আমার এটির দরকার আছে এবং তাই আমি DRY অনুসরণ করি।

হালনাগাদ

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

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

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

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

সুবিধা: আমাদের কার্যকারিতা এখন প্রায় শেষ এবং যখন আমরা সমস্ত বাগগুলি স্থির করে ফেলি। আমরা এ এবং বি এর সমস্ত রিফ্যাক্টরিং এবং পরীক্ষা সংরক্ষণ করেছি

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

সুতরাং: কোড সদৃশ সর্বদা বিপজ্জনক। আমি মনে করি এটি সর্বদা বাণিজ্য-সন্ধানের বিষয় এবং প্রায়শই এটি সহজ নয়।

Answer 7

কেবল পরিষ্কার করার জন্য, যেহেতু আমি অন্য কোনও উত্তরে এটি পাই না:

সকল ধরণের তথ্যের পুনরাবৃত্তি হ্রাস করার লক্ষ্যে ডিআরওয়াই হ'ল সফটওয়্যার বিকাশের একটি মূলনীতি ।

জ্ঞানের প্রতিটি অংশের অবশ্যই একটি সিস্টেমের মধ্যে একক, দ্ব্যর্থহীন, অনুমোদনমূলক প্রতিনিধিত্ব থাকতে হবে।

অ্যান্ডি হান্ট এবং ডেভ থমাস উল্লিখিত DRY নীতিটি কোডের নকল রোধের মধ্যে সীমাবদ্ধ নয়। এটি কোড উত্পন্নকরণ এবং যে কোনও অটোমেশন প্রক্রিয়াটিরও সমর্থন করে। হাস্যকরভাবে, কোড উত্পন্ন ফলাফল এমনকি ডুপ্লিকেট কোড হতে পারে ...

অন্যান্য উত্তরগুলিতে ইতিমধ্যে কেন পুরোপুরি ব্যাখ্যা করা হয়েছে তার কারণ, তবে ফ্যালকন এর মন্তব্য এটি যথেষ্ট পরিমাণে পূরণ করে আইএমএইচও:

পরিবর্তনের একক পয়েন্ট বজায় রাখা সহজ।

Comments

ওহ বাহ, আমি ভেবেছিলাম ট্যাগটিতে কিছু ডেটা রয়েছে। আমি সেখানে কিছু তথ্য রাখব।

— ছদ্মবেশে

Answer 8

খুব বেশি DRY এর মতো জিনিস রয়েছে thing যখন এটি ঘটে তখন দুটি ধারণা যা ফ্যাক্টরিং কোড (1) এর পরোয়ানা হিসাবে যথেষ্ট অনুরূপ হতে পারে পরে তা আলাদা আলাদা হতে পারে যে তারা পৃথক বাস্তবায়নের প্রাপ্য।

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

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

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

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

(1) আমি "কোড" শব্দটি ব্যবহার করছি, তবে এটি ডিজাইনের ক্ষেত্রেও প্রযোজ্য।

Comments

বর্ণালীটির কম দেখা শেষ হওয়ার কারণে এটি "অত্যধিক শুকনো" উদাহরণ দেওয়ার পক্ষে সহায়ক হবে।

— ছদ্মবেশে

@ পরিচয়: আমি আমার উত্তর সম্পাদনা করেছি। কোন দৃ concrete় উদাহরণ নয়, তবে আশা করি আমি যা বোঝাতে চেয়েছি তা যথেষ্ট পরিস্কার।

— জো

Answer 9

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

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

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

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

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

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

Answer 10

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

Comments

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

— n611x007

Answer 11

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

দুর্ভাগ্যক্রমে কয়েকটি পদ্ধতির ক্ষেত্রে সূক্ষ্ম বাগ রয়েছে যেমন কিছুটা ক্ষেত্রে চর অ্যারে যথেষ্ট দীর্ঘ নয়, স্ট্রাইকপি () ইত্যাদির মতো অনিরাপদ স্টাফ ব্যবহার করে etc.

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

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

Answer 12

হ্যাঁ, আপনি যদি থ্রোওয়ে কোড লিখছেন তবে ডিআরওয়াই সম্পর্কে বিরক্ত করবেন না ।

তবে ডিআরওয়াই অবশ্যই গুরুত্বপূর্ণ, যদি আপনি কোডটি রাখার পরিকল্পনা করেন।

Answer 13

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

যদি কোনও প্রোগ্রামের উইজেটগুলি প্রক্রিয়া করার কথা, প্রতিটি তিনটি উওজল সহ এবং এটি ফর্মের অনেক লুপ

for (i=0; i<3; i++)
  thisWidget.processWoozle(i);

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

#define WOOZLES_PER_WIDGET 3

এবং প্রতিটি লুপ আবার লেখা হয়েছিল

for (i=0; i<WOOZLES_PER_WIDGET; i++) ...

যেমন একটি নকশা উইজেট প্রতি woozles সংখ্যা পরিবর্তন করা খুব সহজ করতে পারে ।

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

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

Answer 14

যদিও আমি অন্যান্য পোষ্টারগুলির সাথে রক্ষণাবেক্ষণ সম্পর্কে মন্তব্যগুলির সাথে সত্যই মতামত জানাতে পারি which এগুলি সবই বৈধ।

আমি বিতর্কে একটি ছোট মতবিরোধ ভয়েস যুক্ত করতে চাই।

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

Comments

যেহেতু এই সাইটটি "প্রোগ্রামারদের" জন্য, আমি মনে করি এটি "প্রোগ্রামার দর্শন দর্শন" -এ প্রশ্নটি নির্দেশিত বলা নিরাপদ বলে মনে করি। মজুরিদাতা, ইউএটি এবং গুরুত্বের র‌্যাঙ্ক সম্পর্কে আপনার বক্তব্য অবশ্যই বৈধ, তবে এই নির্দিষ্ট প্রশ্নের সাথে প্রাসঙ্গিক নয়।

— ozz

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

— মাইকেল ডুরান্ট

আপনার দ্বিতীয় বুলেট পয়েন্ট পুরোপুরি সঠিক।

— জিম জি

@ ওজ, আপনার নৈপুণ্যের জন্য গর্ব একটি ভাল প্রোগ্রামারের জন্য প্রয়োজনীয় এমনকি গুরুত্বপূর্ণ, তবে সম্ভবত "গ্রাহক সন্তুষ্টি" এর জন্য উদ্বেগের একটি উপায় অন্তর্ভুক্ত করা উচিত "প্রোগ্রামারদের দৃষ্টিভঙ্গি"।

— জেমস অ্যান্ডারসন

Answer 15

<tl;dr>

আমি সমস্ত পুনরাবৃত্ত উত্তরগুলি পড়তে পারি নি তাই আমি কিছু মিস করেছি (এবং নিজেই এটিকে পুনরাবৃত্তি করব <= দেখুন এখানে আমি কী করেছি?)।

কোড নকল প্রতিরোধ সম্পর্কে দুর্দান্ত যে জিনিসগুলির তালিকা এখানে!

1. পরীক্ষা করা সহজ: আপনার কেবলমাত্র কোডের একটি 'অনুলিপি' পরীক্ষা করতে হবে।
2. সমাধান করা সহজ: আপনার কেবল কোডের একটি 'অনুলিপি'তে বাগটি খুঁজে বের করতে হবে এবং একবারে এটি ঠিক করতে হবে।
3. হালনাগাদ করা সহজ (উপরের মত): প্রয়োজনীয় পরিবর্তনগুলি প্রায়শই খুব কম জায়গায় কোড সংশোধন করে পরিচালনা করা যায় কারণ আপনি সঠিকভাবে কোডটি পুনরায় ব্যবহার করতে সময় নিয়েছিলেন এবং উত্সের কয়েক হাজার বা বিভিন্ন জায়গায় একই লাইনগুলি অনুলিপি করেন নি।
4. পুনরায় ব্যবহার করা সহজ: যখন (কয়েকটি জায়গায় সদৃশ হয় না) এবং জেনেরিক যথাযথ নামকরণ পদ্ধতিতে রাখা হয়, আপনার নিজের লেখার পরিবর্তে সেগুলি খুঁজে পাওয়া এবং তাদের ব্যবহার করা সহজ।
5. পড়তে সহজ: ডুপ্লিকেট কোডটি পড়া শক্ত কারণ এটি অযথা ভার্চুজের; এটিতে অনেকগুলি লাইন রয়েছে যা যুক্তি এবং নির্দিষ্ট উদ্দেশ্যে কার্যকরীতার অংশ নয় (উদাহরণস্বরূপ জেনেরিক কমান্ডগুলি সঞ্চালনের জন্য স্টেজ স্থাপন করার জন্য ব্যবহৃত হয় বা জেনেরিক সাধারণ পুনরাবৃত্ত কাজগুলি যা অনেক জায়গায় প্রয়োজনীয়)। ক্লিন কোড যুক্তি এবং কার্যকারিতাটিকে পপ-আউট করে তোলে কারণ কোড-স্পেসে কোনও লিটারের পুনরাবৃত্তি নেই।
6. (1) এবং (5) এর কারণে ডিবাগ করা সহজ।
7. আপনার সময় এবং অর্থ সাশ্রয় করে এবং ভবিষ্যতে আরও মজাদার জিনিসগুলি করে; বিশেষত আরও শক্তিশালী কোড তৈরি করুন। এটি নীচের লাইন এবং এটি উপরের সমস্তগুলির প্রায় এক সংক্ষিপ্তসার। যদি অনেক লোক একই ফাংশনটি ব্যবহার করে doFoo1(a, b), তবে এর অনেকগুলি বিরক্তিকর ত্রুটি ও প্রান্তের কেস উন্মোচিত এবং সমাধান করার আরও ভাল সম্ভাবনা রয়েছে। যদি প্রত্যেকে কোডটি অনুলিপি করে তৈরি করে doFoo2(specialA)... doFuu2^n(a, b, c)তবে তারা সমস্যাগুলি নকল করে নিল doFoo1এবং আরও অনেক কাজ তৈরি করেছে।

</tl;dr>

দীর্ঘ সংস্করণ:

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

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

কোড নকলায় আমি যে জিনিসগুলি ক্ষতিকারক বলে মনে করি:

1. এই ফাংশন ব্যবহারযোগ্য? আসুন যাক আপনি এমন একটি ফাংশন খুঁজে পান যা (বা আপনার প্রয়োজন অনুসারে প্রদর্শিত হবে), কীভাবে এটি কীভাবে সঠিকভাবে কাজ করার কথা রয়েছে বা এটির কোডটিও রয়েছে যা নকল করে ফেলে দেওয়া হয়েছে।
2. অপ্রয়োজনীয় কোড। কখনও কখনও লোকেরা কোডটি নকল করে, এটি ব্যবহার করে এবং এটি ভুলে যান (তারা ভবিষ্যতে সর্বদা এটি আবার সদৃশ করতে পারে)। এক পর্যায়ে কেউ কেউ রিফ্যাক্টর করার প্রয়াসে কিছু জায়গায় ডুপ্লিকেট ফাংশনে কলগুলি সরিয়ে দেয় তবে অব্যবহৃত ফাংশনটি সক্রিয়ভাবে ব্যবহার না করা সত্ত্বেও রয়ে যায়।
3. আপনি যা সন্ধান করছেন তা খুঁজে পাওয়া শক্ত। ডুপ্লিকেটড কোডটি জায়গা নেয় এবং দরকারী এবং প্রয়োজনীয় জিনিসগুলি খুঁজে পেতে (গ্রেপের মতো সরঞ্জাম ব্যবহার করে) এটি করা তার চেয়ে শক্ত কাজ যেমনটি আপনি কয়েক ডজন বা হাজারো ফলাফল পান যেখানে আপনার কেবলমাত্র মুষ্টিমেয় হওয়া উচিত।
4. (এর আগে উল্লেখ করা হয়েছে): বজায় রাখা শক্ত তবে রক্ষণাবেক্ষণ এবং প্রতিরোধের উদ্দেশ্যে ব্যবহার করাও শক্ত। যদি পরীক্ষার কোডটি সদৃশ হয় এবং সঠিকভাবে ফাংশনগুলিতে নিষ্কাশিত হয় না, অন্যরা এটির সদৃশ হবে। কেউ কিউওএল আরও ভাল করার জন্য সহজেই ব্যবহারযোগ্য, এপিআই পড়তে লিখতে বিরক্ত করবেন? আমার অভিজ্ঞতায়, না, হাতছাড়া না হওয়া পর্যন্ত প্রায়শই এমন কিছু লোক মনে হয় যেটিকে চাপ দেওয়া বিষয় মনে হয়।
5. কোড ডুপ্লিকেশনটি পড়া শক্ত কারণ এটি কোড ভার্বোস তৈরি করে যেখানে এটি করা উচিত নয়, যেখানে ভার্বোসটি উদ্দেশ্যে কার্যকরীতা সম্পর্কে তথ্য যোগ করে না: উদাহরণস্বরূপ জেনেরিক পদ্ধতি কলগুলি যা [বারবার] ব্যবহার করা হয় একাধিক প্রকারের উদ্দেশ্যে কার্যকরীতার জন্য ভিত্তি স্থাপন করে, প্রকৃত কার্যকারিতাটিকে পপ আউট করা শক্ত করে তোলে।
6. এটি অনেক উল্লেখ করা হয়েছে। কোডটি যদি ভুল হয় তবে কিছু দরিদ্র গাল বা ছেলেটিকে সেই কোডটির প্রতিটি ব্যবহার অনুসন্ধান এবং পরিবর্তন করতে হবে। উদাহরণস্বরূপ, যদি কেউ এসএসকিউএল ইনজেকশন অনিরাপদ কলটি যেখানে প্রয়োজন হয় এমন একটি সংগঠিত শ্রেণীর খুব অল্প জায়গায় মাইএসকিএল_কিউরিতে কল করেন তবে এটি ঠিক করা এবং পরিবর্তে পিএইচপি পিডিও ব্যবহার করা সহজ হবে তবে তারা যদি কলটি অনুলিপি করে এক হাজারেরও বেশি জায়গায় ব্যবহার করে থাকেন এবং শেষের দিকে, এটি ঠিক করার জন্য ব্যবহারিকভাবে আউটসোর্স করা বা কখনও কখনও আরও বিপজ্জনকভাবে প্রয়োজন হয়, কোডটি স্ক্র্যাচ থেকে আবারও লিখতে হবে।
7. নকল কোড একটি খারাপ অভ্যাস। আপনি যদি কিছু অনুশীলন করেন তবে এটি আস্তে আস্তে দ্বিতীয় প্রকৃতিতে পরিণত হয় এবং এটি আপনার চারপাশের লোককে প্রভাবিত করে। জুনিয়র ডেভস আপনি এটি করতে দেখেন এবং এটিও করেন। আপনি যা প্রচার করেন তা অনুশীলন করা এবং সঠিক জিনিস করার অভ্যাস করা উচিত। আপনি আরও শিখুন। নন-ডুপ্লিকেট কোড লিখানো আরও কঠিন এবং আরও চ্যালেঞ্জিং। এটি একটি লাভজনক অভ্যাস।

অতিমাত্রায়িত কোড ডুপ্লিকেশন প্রতিরোধ ও জিনিসগুলি সমষ্টি সম্পর্কে শেষ নোটগুলি:

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

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