রিফ্যাক্টর কখন


32

আমি বেশিরভাগ ফোলারের রিফ্যাক্টরিং বইটি পড়েছি এবং আমার অতীতের বড় এবং ছোট অনেক অ্যাপ্লিকেশন রিফেক্টর করেছি।

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

আমি মনে করি এটির বিষয়ে আরও কঠোর পন্থা হওয়া উচিত তবে তারা কী তা নিশ্চিত।

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


2
মূলত, আপনি এটির মতো একই জিনিসটি জিজ্ঞাসা করছেন: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার / ক্রোয়েশনস / 6268/… । ব্যয় এবং ঝুঁকি কম হওয়ায় পদক্ষেপ নেওয়ার জন্য আপনার থ্রেশহোল্ডটি কম, তাই না?
এসলট

উত্তর:


22

Refactor যখন refactoring খরচ খরচ কম না refactoring।

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


শর্টফর্ম এবং নিখুঁত
জেডজেআর

8
অন্য কথায়: "রিফ্যাক্টর করার মতো যখন এটি মূল্যবান হয়"। Duh। ঠিক আছে, এটি আসলে কোনও উত্তর নয়, এটি :) Measure "cost" however you can.- ঠিক আছে, কীভাবে? প্রশ্নটির মূল বক্তব্য কি তা নয়? সেই ব্যয়টি পরিমাপ করার সময় কোন সময়ের দৃষ্টিকোণ প্রয়োগ করা উচিত?
কনরাড মোরাউস্কি

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

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

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

12

  1. 5 এর নীচে ফাংশনটির চক্রবৃত্তীয় জটিলতা কি ?
  2. এই লিঙ্কটি অনুসরণ না করে আপনি কি চক্রবৃত্তীয় জটিলতাটি পুরোপুরি বুঝতে পেরেছিলেন?
  3. আপনার কাছে কি কার্যের মাধ্যমে প্রতিটি পাথের জন্য একটি স্বয়ংক্রিয় পরীক্ষা বা ডকুমেন্টেড টেস্ট কেস রয়েছে?
  4. বিদ্যমান পরীক্ষার সবগুলিই কি পাস হয়?
  5. আপনি কি 1 মিনিটেরও কম সময়ে আমার কাছে ফাংশনটি এবং এর সমস্ত প্রান্তের বিষয়গুলি ব্যাখ্যা করতে পারেন?
  6. তা না হলে প্রায় ৫ মিনিট কেমন?
  7. 10 মিনিট?
  8. ফাংশনে 100 টিরও কম কোডের কোড রয়েছে (মন্তব্য সহ)?
  9. আপনি কি কেবলমাত্র ভিজ্যুয়াল ইন্সপেকশন দ্বারা এই কোডটি ত্রুটিমুক্ত এই দু'টি বিকাশকারীকে খুঁজে পেতে পারেন?
  10. এই ফাংশনটি কি কেবলমাত্র এক জায়গায় ব্যবহৃত হয়?
  11. ফাংশনটি কি তার কর্মক্ষমতা লক্ষ্যগুলি (সময় / মেমরি / সিপিইউ) পূরণ করে?

স্কোরিং

উপরে "না" উত্তরগুলি জুড়ুন:

  • 0-1 - আপনি কেন এটি পুনর্বিবেচনা সম্পর্কে চিন্তা করবেন? আপনি সম্ভবত কেবল পরিবর্তনশীল নাম পরিবর্তন করতে চান কারণ আপনি পূর্ববর্তী বিকাশকারীর নামকরণ কনভেনশন পছন্দ করেন না
  • 2-5 - এটির জন্য সামান্য টুইটের প্রয়োজন হতে পারে তবে আমি এই সীমাতে থাকা কোনও কিছুর জন্য একটি প্রযোজনা প্রকাশ করতে পারব না
  • 6-8 - ঠিক আছে, সম্ভবত আমাদের এটি ঠিক করা দরকার ... সম্ভবত আমরা এটি পুনর্বিবেচনা করতে চলেছি এবং / অথবা এটি আসলে কী করছে তা আমরা জানি না। এখনও বেড়া উপর, কিন্তু এটি অত্যন্ত সন্দেহজনক
  • 9+ - এটি রিফ্যাক্টরিংয়ের জন্য প্রধান প্রার্থী। (দ্রষ্টব্য, পরীক্ষার কেসগুলি রাইফ্যাক্টরিংয়ের একটি রূপ)

http://mikemainguy.blogspot.com/2013/05/when-to-refactor-code.html


4
# 2 খুব হাস্যকর শোনায় এবং কোড মূল্যায়নের জন্য আসলে অকেজো । # 3 & # 4 প্রতিটি সংস্থা ইউনিট পরীক্ষা ব্যবহার করে না। # 8 যেখানেই সম্ভব মন্তব্য মন্তব্যগুলি এড়িয়ে চলুন এবং 100 টি লাইন খুব বেশি হাই রয়েছে। আমার কাছে পোর্ট্রেট মোডে 1 টি বড় ওয়াইডস্ক্রিন মনিটর রয়েছে এবং আমি একবারে পুরো ফাংশনটি সবে দেখতে সক্ষম হব। যদি এটি আসল কোডের 15 টিরও বেশি লাইন হয় তবে ইতিমধ্যে আপনি কেন এটি চালিয়ে রাখার একটি দৃ reason় কারণ থাকতে হবে। এটি একটি চেকলিস্ট পেতে একটি দুর্দান্ত, ব্যবহারিক পদ্ধতির, কিন্তু এখানে অনেকগুলি পয়েন্ট স্রেফ তৈরি করা হয়েছে বা এর পিছনে কোনও কারণ ছাড়াই এলোমেলো মান ব্যবহার করা হয়।
আর শ্মিতজ

8

যখন আপনার অন্ত্রটি আপনাকে বলছে যে আপনি সম্ভবত কিছু রিফ্যাক্টরিং করা উচিত, সম্ভবত এটি আপনার প্রবৃত্তিগুলি আপনাকে কিছুটা দেরী করে বলছে যে আপনি খুব গুরুত্বপূর্ণ কিছু দূরে রেখে চলেছেন।

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

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

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

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

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


2

আমি মনে করি আপনার প্রশ্নের উত্তর প্রতিটি বিকাশকারী এমনকি প্রোগ্রামিংয়ের দায়িত্বে থাকা ম্যানেজমেন্টের দ্বারা পৃথকভাবে দেওয়া যেতে পারে।

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

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

আমি অনুভব করছি কখন রিফ্যাক্টরটি আসলে আপনি যে সংস্থায় আছেন তার উপর নির্ভর করে।


2

"কখন রিফ্যাক্টর?"

সংক্ষিপ্ত উত্তর: প্রতিবার আপনি এমন কোডটি পেলেন যা খারাপ গন্ধ পেয়েছে বা উন্নত হতে পারে ( বয় স্কাউট বিধি )

ব্যবহারিকভাবে, এটি ঘটে:

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

আমি এইরকম শক্ত অংশটির জবাব না দিয়ে কেবল "আপনার রিফ্যাক্টর" বলেছি বলে মনে হচ্ছে: "আমি মনে করি এটির বিষয়ে আরও কঠোর পন্থা হওয়া উচিত, তবে তারা কী তা নিশ্চিত নয়" "
হার্টটিচিউড

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

1

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

Eclipse, বা অনুরূপ IDE ব্যবহার করে যার শক্তিশালী রিফ্যাক্টরিং সমর্থন রয়েছে, রিফ্যাক্টরিংয়ের প্রচেষ্টা হ্রাস করে। আইডিই সমর্থনটি এটিকে অতিরিক্ত প্রচেষ্টা হিসাবে দেখার পরিবর্তে "তৃতীয়বার" (বা প্রয়োজনটি দেখুন) আঘাতের সাথে সাথে আপনি রিপ্যাক্টর তৈরির সম্ভাবনা তৈরি করে।

এছাড়াও - টিডিডি এখানেও একটি বড় সহায়তা, যেহেতু আপনি নিজের পরীক্ষাগুলিকে আপনার চুল্লি হিসাবে চালিয়ে যেতে পারেন এবং জেনে রাখুন যে আপনি কোনও কিছু ভাঙ্গেন নি।


1

এর সংজ্ঞা দ্বারা রিফ্যাক্টরিং একটি প্রক্রিয়া। এর দ্বারা বোঝা যায় যে রাফ্যাক্টরিংয়ের কাজটি করার জন্য আপনার অতিরিক্ত সময় খোঁজার চেষ্টা করা উচিত নয়, পরিবর্তে আপনি কোড কোডটি দেখতে পেলেন যে আপনি আরও ভাল লেখা যেতে পারে all

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


1

আমার 20 বছরের প্রোগ্রামিংয়ে, এখানে থাম্বের একমাত্র নিয়ম যা আমি আসলে কাজ দেখেছি, যা লোকেরা আঁকড়ে রাখতে পারে এবং পরিচালকদের সময় দেওয়ার অনুমতি দেয়। (রিফ্যাক্টরিং ডায়েটিংয়ের মতো: অবশ্যই, "ক্যালোরি ইন / ক্যালোরি আউট" হ'ল ওজন হ্রাস করার সূত্র, তবে এটি লোকেরা মেনে চলা ডায়েটে অনুবাদ করে না)) এবং তাই:

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

একবার আপনি নিজের সম্পর্কে আরও নিশ্চিত হয়ে গেলে আপনি এই পদ্ধতি থেকে আলাদা হতে পারেন।


1

আমি মনে করি, এটি প্রকল্পের মালিক এবং কোডটির মানের জন্য উত্তর দেওয়া লোকের দাবির উপর নির্ভর করে। যখন অন্য কারও অর্থ প্রশ্নে আসে তখন আপনি কেবল এটি একা সিদ্ধান্ত নিতে পারবেন না।

প্রযুক্তিগত কারণ হিসাবে, বিভিন্ন আছে।

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

স্ক্রাম মাস্টার হিসাবে, আমাদের একজন বিকাশকারী ছিলেন যারা নিয়মিত যুক্তি দিয়েছিলেন যে দলটি আকারের প্রতিটি গল্পই দলটির চিন্তাভাবনার চেয়ে বড় এবং তিনি বুঝতে পেরেছিলেন যে তিনি যে কোডের প্রতিটি অংশটি দেখতে পেয়েছিলেন তা রিফ্যাক্টর করতে চান। সুতরাং, 3 পয়েন্টের গল্পটি সর্বদা তার জন্য 8 ছিল। স্পষ্টতই এটি মূল্য সরবরাহের দিকে ঝুঁকছে। সুতরাং কোনওভাবে কখন রিফ্যাক্টর করা উচিত, এবং কীভাবে সিদ্ধান্ত নেওয়া উচিত সে সম্পর্কে কিছুটা বোঝার প্রয়োজন। কেবল আমার চিন্তাভাবনা, সেই (এবং আরও কয়েকটি) অভিজ্ঞতা থেকে।
কার্টিস রিড
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.