বাগগুলি কি প্রযুক্তিগত debtণের অংশ?


44

আমাদের স্ক্রাম মাস্টার বাগগুলি প্রযুক্তিগত debtণ হিসাবে উল্লেখ করে চলেছে। তিনি কি ঠিক বলেছেন, বাগগুলি কি এগিলের বিশ্বে প্রযুক্তিগত debtণ হিসাবে বিবেচিত হয়?


তারা প্রযুক্তিগত technicalণ কিনা তা কেন সিদ্ধান্ত নেওয়া গুরুত্বপূর্ণ? আপনি কীভাবে আপনার স্ক্রাম বোর্ডে বাগগুলি উপস্থাপন করবেন বা কীভাবে আপনি এটি ঠিক করার পরিকল্পনা করছেন তা প্রভাবিত করবে?
ব্রায়ান ওকলি

@ ব্রায়ানওকলে কিছু বাগ আপনাকে এমনভাবে ব্লক করতে পারে যা আপনাকে আরও বেশি প্রযুক্তিগত debtণ প্রবর্তন করে তাদের চারপাশে কাজ করতে বাধ্য করে। এই বাগ ফিক্স অত্যন্ত ব্যয়বহুল হতে পারে
BЈовић

4
@ ব্রায়ানকলে - আমি সবসময় ভেবেছিলাম প্রযুক্তিগত debtণ এমন ডিজাইন বা রিফ্যাক্টরিং যা বাস্তবায়নের উন্নতি করার জন্য প্রয়োজনীয় ছিল তবে সময় / বাজেটের সীমাবদ্ধতার কারণে বর্তমানে সম্ভব হয়নি। আমি মনে করি সঠিক পরিভাষাটি ব্যবহার করা গুরুত্বপূর্ণ। আমি ভুল হতে পারি বা সে ভুল হতে পারে, এ কারণেই আমি প্রশ্নটি জিজ্ঞাসা করেছি।
ব্যবহারকারী 86834

আমি বুঝতে পারি যে. কেন তাদের প্রযুক্তিগত callণ বলা গুরুত্বপূর্ণ? আপনি কি বলছেন যে আপনি যদি তাদের "প্রযুক্তিগত debtণ" হিসাবে শ্রেণিবদ্ধ করেন তবে আপনি এই বাগগুলি অন্যান্য বাগগুলির চেয়ে আলাদা আচরণ করবেন?
ব্রায়ান ওকলে

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

উত্তর:


35

আমি মনে করি যে এখানে উত্তরটি মোটামুটি সহজ - প্রযুক্তিগত debtণের মূল বৈশিষ্ট্যটি হ'ল এটি আমাদের পছন্দের দ্বারা ব্যয় করা।

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

একটি বাগ আমাদের কোডে রাখার মতো জিনিস নয় - তাই প্রযুক্তিগত notণ নয়, তা ডি-ফ্যাক্টো।

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


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


1
+1 টি। আমি মনে করি বি এর উত্তর বেশ সঠিক, তবে আপনার উত্তরটি সত্যিই মাথার পেরেকটি আঘাত করে। (আমি একটু শব্দ আপনার ব্যবহার দ্বারা বিভ্রান্ত নই কার্যত । যদিও আমি মনে করি না আপনি বলছেন যেতে পারে যে না বিধিসম্মত , একটি বাগ হয় প্রযুক্তিগত ঋণ?)
ruakh

ভাষার ব্যবহার যেমন মজাদার ... এটি চেষ্টা করুন: en.wikedia.org/wiki/De_facto - এটি "সমস্ত উদ্দেশ্য এবং উদ্দেশ্যে" হিসাবে পড়ুন যা আমার অভিপ্রায়টির নিকটবর্তী
মার্ফ

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

ডি জুরে দু জুরে আগামীকাল ডি ফ্যাক্টো। Qed।
রডারবব

1
মার্টিন ফাউলারের কারিগরি tণ চতুর্ভুজ অনুসারে আপনি বাগ এবং খারাপ কোডটিকে "বেপরোয়া অসাবধানতা" asণ হিসাবে চিহ্নিত করতে পারেন: মার্টিনফাউলার / বিলিকি / টেকনিকাল ডেবিটকুয়াদ্রেন্টhtml । আমি মনে করি মুল বক্তব্যটি হ'ল যদি আপনি কিছু সংবেদনশীল বাগগুলি debtণ হিসাবে চিহ্নিত করেন তবে আপনি বুঝতে পারবেন যে সেগুলি আপনাকে কতটা ব্যয় করেছে এবং এটি অপসারণ করার দরকার আছে কিনা। উদাহরণস্বরূপ, আপনার কাছে কি মজাদার লিখিত মডিউল রয়েছে যা বছরে মাত্র একবার পরিবর্তিত হয় এবং এটি পুনরায় লিখতে কয়েক সপ্তাহ লাগবে - আপনার সম্ভবত এটি যেমন রাখা উচিত কারণ এই debt
ণের

20

হ্যাঁ.

কারিগরি debtণ (ডিজাইন debtণ বা কোড asণ হিসাবেও পরিচিত) হ'ল একটি নেওলোজিস্টিক রূপক যা কোনও কোডবেসের মধ্যে দুর্বল বা বিকশিত সফ্টওয়্যার আর্কিটেকচার এবং সফ্টওয়্যার বিকাশের পরিণতিগুলির পরিণতি উল্লেখ করে।

সূত্র: উইকিপিডিয়া

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

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


বি এর উত্তর পড়ার পরে , আমি দেখতে পাচ্ছি যে এটি যতটা ভাবছিলাম ততটা সহজ নাও হতে পারে।

  • উদাহরণস্বরূপ বাগগুলি কি প্রযুক্তিগত debtণের অংশ? নিবন্ধটি দাবি করেছে যে কেবলমাত্র আপনি যে বাগগুলি জানেন তারাই প্রযুক্তিগত debtণের অংশ।

  • আরেকটি উদাহরণ, কারিগরি tণ সম্পর্কে ক্রিস্টোফার চিন্তাভাবনাগুলি এর অংশ নয়, প্রযুক্তিগত debt ণের ফলস্বরূপ বাগগুলি যোগ্য করে তোলে । এটি বলা হচ্ছে, "নতুন বৈশিষ্ট্য প্রয়োগের জন্য ব্যয়" এর মতো তালিকাভুক্ত ফলাফলগুলি বাগের সংখ্যা দ্বারা প্রভাবিত হয়।

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

এটি বলা হচ্ছে, আমি এখনও উত্তর দিতে আগ্রহী যে বাগগুলি - কোনও বাগগুলি প্রযুক্তিগত debtণের অংশ।

প্রথম যুক্তি:

জেফ আতউডের উক্তিটি পড়লে, বেশিরভাগ বাগগুলি এই হিসাবে যোগ্যতা অর্জন করবে:

দ্রুত এবং নোংরা নকশা নির্বাচনের কারণে ভবিষ্যতের বিকাশে আমাদের যে অতিরিক্ত প্রচেষ্টা করতে হবে

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

দ্বিতীয় যুক্তি:

যদি আমরা কোনও সংস্থার অন্য toণের কাছে বিক্রি করা হয় তখন বিবেচনায় নেওয়া গুরুত্বপূর্ণ যে কোনও কোম্পানির সাধারণ debtণ এবং প্রযুক্তিগত debtণ, যেটি যখন অন্য কোনও কোম্পানির কাছে বিক্রি হয় বা দেওয়া হয় তখন বিবেচনায় নেওয়া সমান গুরুত্বপূর্ণ অন্য দলে, আমরা সহজেই দেখতে পাচ্ছি যে বাগগুলি প্রযুক্তিগত debtণের অংশ, যেহেতু নতুন দলটি করবে:

  • হয় নতুন বৈশিষ্ট্য তৈরি করার আগে সেই বাগগুলি মোকাবেলা করতে হবে (জোয়েল টেস্টের পয়েন্ট 5: নতুন কোড লেখার আগে আপনি কি বাগগুলি ঠিক করেন?)

  • বা এইভাবে প্রযুক্তিগত debtণ সংরক্ষণ / বাড়িয়ে বাগগুলি রাখুন।


1
আমি ব্যক্তিগতভাবে ত্রুটিগুলি প্রযুক্তিগত debtণ হিসাবে ভাবি না যদিও এই উত্তরে উপস্থাপন করা যুক্তিটি যথাযথ, তবে ক) প্রযুক্তিগত IMণ আইএমওকে আমরা কীভাবে সংজ্ঞায়িত করি তা আসলেই গুরুত্বপূর্ণ নয়, এবং খ) এটি এমন একটি লিখিত উত্তর আমি ' আমি যাই হোক না কেন এটি ভোটিং। +1 টি!
ব্রায়ান ওকলি

13

জেফ আতউড তার নিবন্ধে আপনার কারিগরি tণ পরিশোধে প্রযুক্তিগত debtণ কী তা সম্পর্কে যথেষ্ট সুন্দর উত্তর দেয়:

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

কড়া কথায় বলতে গেলে, বাগগুলি প্রযুক্তিগত debtণের অংশ নয়, যদি তারা আরও সফ্টওয়্যার বিকাশকে কমিয়ে না দেয় (জিনিস পরিবর্তন করা, নতুন বৈশিষ্ট্য যুক্ত করা ইত্যাদি)। তারা সফ্টওয়্যার ত্রুটি।

তবে, যখন কোনও বাগ সংশোধন করা খুব ব্যয়বহুল হয়, বা এটি আপনাকে চারপাশে কাজ করতে বাধ্য করে (এবং আরও প্রযুক্তিগত debtণ প্রবর্তন করে), তখন এটি প্রযুক্তিগত debtণের অংশ হয়ে যায়।


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

@ মারজানভেনেমা ভাল পয়েন্ট আমি এটা ভাবিনি।
BЈовић

নোট করুন যে এই উদ্ধৃতিটি জেফ আতউডের নয়, এটি মার্টিন ফওলারের একটি পোস্ট থেকে নেওয়া হয়েছে । জেফ তার ব্লগ পোস্টে এটিও উদ্ধৃত করেছেন।
উওও

6

একটি বাগ প্রযুক্তিগত debtণ নয়। প্রযুক্তিগত debtণ গুণমানের উপর ঝুঁকছে, এর অনুপস্থিতি নয়। সফ্টওয়্যারটি এতে বাগের সাথে প্রথমে বিতরণ করা উচিত নয়। আপনি জানেন, বিস্তৃত ডকুমেন্টেশন জিনিসটির উপরে পুরো কার্যকারী সফ্টওয়্যার।

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

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

ওয়ার্ড কানিংহাম ও ক্যাপার্স জোন্স সহ প্রযুক্তিগত tণ বিতর্ক

আর একটি নিবন্ধ পড়ার মূল্য মার্টিন ফওলারের by

কারিগরি onণ নিয়ে মার্টিন ফাউলার

মার্টিনের নিবন্ধের মধ্যে, ওওপিএসএল ৯২ থেকে ওয়ার্ড কানিংহামের কারিগরি debtণের মূল উল্লেখের লিঙ্কটি সন্ধান করুন:

উইক্যাশ পোর্টফোলিও ম্যানেজমেন্ট সিস্টেম

উপরের নিবন্ধের একটি উদ্ধৃতি:

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

শেষ পর্যন্ত, প্রযুক্তিগত tণ কিছু লোকের জন্য বাগগুলি অন্তর্ভুক্ত করতে পারে এবং আমি অনুমান করি যে এটি ঠিক আছে। আমি মনে করি না যে এটিই মূল উদ্দেশ্য ছিল।


"সফ্টওয়্যারটি এতে প্রথমে বাগের মাধ্যমে সরবরাহ করা উচিত নয়" " সমস্ত সফ্টওয়্যার তবে খুব সাধারণ প্রোগ্রামে বাগ রয়েছে। আপনি এই বারটি খুব উচ্চ সেট করেছেন set
bhspencer

2

কড়া কথা বলতে গেলে, আপনার প্রশ্নের উত্তরটি নং is

কারিগরি debtণ বাগের দিকে নিয়ে যেতে পারে (এবং সম্ভবত তা করবে) তবে কোনও ত্রুটি কারিগরি debtণের ফলস্বরূপ এই সিদ্ধান্তে পৌঁছানো দুটি বিষয়গুলির মধ্যে একটি ব্যাখ্যা রাখে: একটি ত্রুটি আছে এবং প্রযুক্তিগত debt ণ রয়েছে (ধরে নিলে এটি সত্য হিসাবে উপসংহারে পৌঁছানো যায়)।

যদি আপনার স্ক্র্যাম মাস্টার 'তত্ত্ব হিসাবে' উল্লেখ করছেন যে বাগগুলি কারিগরি debtণের ফলস্বরূপ, তিনি কোণগুলি কেটে দিচ্ছেন। যদি তিনি এমন নির্দিষ্ট বাগগুলি সম্পর্কে আবার বলছেন যা পুনরায় উপস্থিত হতে থাকে তবে সে ভাল হতে পারে - আমরা এখানে কোডের মান দেখতে পাচ্ছি না ;-)

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


2

আমার মতে, আপনি বলছেন যে প্রযুক্তিগত debtণের অংশ ... বা না তা আসলেই কিছু যায় আসে না।

প্লেইন সত্য যে বিদ্যমান বাগ অতিরিক্ত কাজ যে প্রতিনিধিত্ব করি পারে তাদের বা তাদের চারপাশে কাজ ঠিক করতে, ভবিষ্যতে সঞ্চালিত করা প্রয়োজন হয়।

কারিগরী ঋণ (যেমন ট্যাগ সাধারণত ব্যবহার করা হয়) অতিরিক্ত কাজ যে প্রতিনিধিত্ব করে পারে ভবিষ্যতে ... একটি উপায় বা অন্য সঞ্চালিত করা প্রয়োজন।

সুতরাং আপনি জ্ঞাত (বা অজানা) বাগগুলি প্রযুক্তিগত debtণ ... বা না ... সত্যই এটি কেবল সংজ্ঞার বিষয়। যেহেতু কিছু নেই প্রামাণিক সংজ্ঞা 1 "প্রযুক্তিগত ঋণ" এর পুরো আলোচনা অর্থহীন ধরনের।

লুইস ক্যারল যেমন লিখেছেন:

'আমি যখন কোনও শব্দ ব্যবহার করি,' হ্যাম্প্টি ডাম্প্টি বরং কটূক্তিপূর্ণ সুরে বলেছিলেন, 'এর অর্থ আমি যা বোঝাতে চাইছি তার অর্থ - আরও বেশি বা কম নয়' '

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


1 - ওয়ার্ড কামিংহাম এবং কেপার জোনসের মতো লোকের উদ্ধৃতি দেওয়াও কোনও কাজে দেয় না। সর্বোপরি এটি আমাদের জানায় যে তারা যখন শব্দটি ব্যবহার করে (ব্যবহৃত) তখন তারা কী বোঝায় (বা বোঝায়)। তারা এই বাক্যাংশটি "নিজস্ব" করে না। নিঃসন্দেহে তারা এই বিষয়গুলিতে কর্তৃপক্ষ হলেও এটি এখনও তাদের মতামত।

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