ভাঙ্গা উইন্ডোজ ঠিক না করা কখন গ্রহণযোগ্য?


21

ভাঙা উইন্ডোগুলির প্রসঙ্গে , এমন কোনও সময় রয়েছে যখন কোনও ভবিষ্যতের ক্রিয়াকলাপের জন্য রিফ্যাক্টরিং সেরা থাকে?

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


6
কখনও কখনও, বস সিদ্ধান্ত নেন যে ভাঙা উইন্ডোজগুলি ঠিক করা হবে না, কারণ তিনি জানেন যে পরে পুরো বাড়িটি ঠিক করে তিনি আরও বেশি অর্থোপার্জন করবেন।
mouviciel

1
বেস রুল: কারিগরি debtণ একটি সময়সীমা পৌঁছানোর জন্য ঠিক আছে, তবে শেষ পর্যন্ত ক্ষতিপূরণ দিতে হবে এবং যত তাড়াতাড়ি আরও ভাল
জেএফ ডায়ান

4
অভিনন্দন! আপনি পিএইচপি এর "নকশা দর্শন" পুরোপুরি বর্ণনা করেছেন।
থমাসএক্স


4
আগামীকাল কখনই আসে না ...
এরিক কিং

উত্তর:


25

রিফ্যাক্টরিং একটি চলমান প্রক্রিয়া - এবং হওয়া উচিত। কেবলমাত্র একটি কাজ এবং পরীক্ষিত বাস্তবায়নের সাথে প্রয়োজনীয়তাগুলি পূরণ করা যথেষ্ট নয় যা এখনও কিছুটা অসম্পূর্ণ।

"এটি কাজ করুন, তারপরে এটি আরও ভালভাবে কাজ করুন"

আমি সেই উদ্ধৃতিটি কোথায় পড়েছি তা মনে করতে পারছি না, তবে এটি রিফ্যাক্টরিং ভালভাবে প্রয়োগ করার মূল চাবিকাঠি এবং আমি অন্যথায় এটি করা অযৌক্তিক হিসাবে বিবেচনা করি।

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

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

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

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

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

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


উক্তিটি ভালো লেগেছে।
মার্জন ভেনেমা

1
অনেক জায়গায় "বিরল সময়" হ'ল আদর্শ।
ozz

2
যদি কেবল পিএইচপি "ডিজাইনাররা" সেই উদ্ধৃতিটি স্বীকৃতি দেয় ...
থমাসএক্স

1
দুর্দান্ত উক্তি, এটি সম্পর্কে চিন্তা করুন - আপনি কি চান যে আপনার গাড়ী চিত্রশিল্পী আপনার 1999 টয়োটা মেরামত করার জন্য একই যুক্তি প্রয়োগ করতে পারে - এবং যদি তাই হয় তবে আপনি কি 1000 ডলার গাড়িতে রোল রইস পেইন্ট ফিনিশটির জন্য অর্থ প্রদানের জন্য প্রস্তুত?
mattnz

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

11

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

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

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


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

9

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

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

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

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

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


4
বানান ভুল থাকা সত্ত্বেও +1 :); বেশিরভাগ সময় ক্লায়েন্ট ক্লিন কোডের জন্য অর্থ প্রদান করে না - তারা কোনও ফলাফলের জন্য অর্থ প্রদান করে। আপনার যদি পরিষ্কার কোড এবং ফলাফল না থাকে তবে আপনাকে অর্থ প্রদান করা হবে না এবং আপনি খুব বেশি দিন রিফ্যাক্টরিং করবেন না।
জেসনক

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

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

1
@ এসরোবিনস আমরা রিফ্যাক্টরিংয়ের বিষয়ে কথা বলছি, এবং খারাপ ফ্যাক্টরিড কোড নয়, (আমার মনে দ্বিতীয়টি একটি সমস্যা, প্রথমটিটি খুব ভাল লাগবে)।
জেসনক

5

এটি ঠিক করা দ্বারা ব্যবসায়ের যে ক্ষতি হয় তার চেয়ে বেশি হলে তা গ্রহণযোগ্য।

পরিস্থিতি যেখানে এটি ঘটে তা হতে পারে:

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

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

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

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

এবং যদি কোনও বিকল্প না থাকে তবে সর্বদা জরিমানা হয় তবে আমরা কখন এটি ঠিক করব?

কারণ এটা প্রায় প্রায়, প্রায় সবসময় হওয়া উচিত যখন , না যদি


পুনঃ কৃত্রিম সময়সীমা; আদর্শ বিশ্বে যে কোনও শালীন প্রকল্পের একটি সময়সীমা থাকতে হবে। আমি শুনেছি প্রোডাক্ট টিমগুলি এক সপ্তাহের পিছলে পিছলে যাওয়ার সাথে ঠিক আছে (এক সপ্তাহ কোনও বড় বিষয় ঠিক নয়?) - ব্যবসায়ের প্ররোচনাটি অনুধাবন না করে - এটি আপনাকে কালো শনিবারের পরে রেখেছিল , বনাম আগে। বাজে সিদ্ধান্ত.
জেসনক

3

যদি পরিচালকরা সিদ্ধান্ত নেন যে তারা প্রযুক্তিগত debtণ তৈরি করতে চান । উদাহরণস্বরূপ, কিছু প্রাথমিক গ্রাহকদের কাছে কিছুটা প্রাথমিক প্রতিক্রিয়া পেতে যদি একটি প্রাথমিক প্রোটোটাইপ চান তবে এটি করার একটি ন্যায্য সিদ্ধান্ত।


4
এটি প্রায়শই ঘটে থাকে, যেখানে ম্যানেজাররা কারিগরি debtণটি একটি কঠোর সময়সীমা পূরণের অনুমতি দেয়, কেবলমাত্র যত তাড়াতাড়ি সম্ভব payingণ পরিশোধের পরিবর্তে, তারা পরবর্তী সময়সীমাটি বাড়তে দেখছে এবং পরিবর্তে আগত কাজ এবং পূর্বের debt ণের সময় নির্ধারণের পরিবর্তে , debtণ উপেক্ষা করা হয় এবং সময় মুক্তির জন্য অতিরিক্ত নতুন বৈশিষ্ট্য দ্বারা ভরা প্রয়োজন। অন্য কথায়, debtণটি কখনই পরিশোধ করা হয় না, এবং আপনি বুঝতে পারার আগে এই প্রকল্পটি কতটা গভীর is Debtণ আদায় করা ঠিক আছে, যতক্ষণ আপনি প্রকৃতপক্ষে তা দ্রুত পরিশোধ করেন।
S.Robins

2
আপনি যখন কারিগরি mentionণের কথা উল্লেখ করেন তখন কিছু পরিচালক (বিশেষত নন প্রযুক্তিগত) আপনি কী সম্পর্কে কথা বলছেন তা সম্পর্কে কোনও ধারণা নেই। কেউ কেউ এমনকি মনে করেন যে আপনি তাদের সত্যিকারের কাজ না করে কেবল দূরে গিয়ে স্টাফ নিয়ে খেলতে চেষ্টা করছেন।
দ্রুত_ এখন

এই কারণেই আমাদের সংস্থার পরিচালক নেই: ওপেন -আরগ ডটকম;)
ডেভিড

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

1

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

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

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


0

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

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

যদি এটি কার্যকারিতা দ্বারা ভাঙা হয় এবং আপনি নতুন বৈশিষ্ট্যগুলি এর উপর নির্ভর করে তবে এটি এএসএপটিকেও ঠিক করা ভাল।


0

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

এটি মূল্যবান কিনা তা বেশিরভাগ আপনার পরিচালকের উপর নির্ভর করে।


1
-1; এই ধরণের মনোভাবটিই সফ্টওয়্যার সিস্টেমগুলিকে উত্সাহ দেয় কারণ রিফ্যাক্টরিংকে "নতুন সময় ব্যয় করতে পারে" হিসাবে দেখা হয়।
ওয়েন মোলিনা

1
রিফ্যাক্টরিংয়ের সময় নতুন জিনিসগুলিতে ব্যয় হয় না।
পিটার বি

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

+1 এই ধরণের দৃষ্টিভঙ্গি হ'ল যাঁরা আপনার বেতন প্রদান করছেন তার মান দেয়। এটি ছাড়া আপনার পুরো কাজ আউটসোর্স করা যেতে পারে।
মার্কজে

0

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

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

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


0

এই দৃশ্যে সময়সীমা নির্ধারণের জন্য বিদ্যমান কোডটিতে বড় রিফ্যাক্টরিংগুলি স্থগিত করা কি কখনও ন্যায়সঙ্গত হতে পারে?

  • যদি কিছু ভেঙে যায় তবে সম্ভবত না not আপনি আংশিক-কাজ ব্রেক সহ গাড়ী চালনা করবেন না, আপনি কি? (ত্রুটিযুক্ত ব্রেকের কারণে দুর্ঘটনার ঝুঁকির চেয়ে যথাসময়ে কোথাও না আসার ঝুঁকি না থাকলে) আদর্শ সমাধান থেকে দূরে, তবে দুর্ভাগ্যক্রমে এটি ঘটে।

তবে, আপনি যদি ওয়ার্কিং কোডটিকে পুনরায় ফ্যাক্টরিং করার কথা বলছেন তবে আমি নিম্নলিখিতগুলি বিবেচনা করব:

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

  • যদি রি-ফ্যাক্টরিং ব্যবসায়ের লাভে নেতিবাচক প্রভাব ফেলে তবে তা পুনরায় নির্ধারিত হওয়া উচিত।

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

  • আপনি সর্বদা কিছু করার জন্য আরও ভাল উপায় পাবেন। এটি একটি প্রাকৃতিক প্রক্রিয়া এবং একটি লাইন আঁকতে সক্ষম হওয়া খুব গুরুত্বপূর্ণ।


ডাউন ভোটের বিষয়ে কিছু প্রতিক্রিয়া জানাতে ভালো লাগবে: ডি
কোডার্ট

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

-1

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

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

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


ডাউন ভোটের কারণ কী? এখানে কিছু বলা হয়নি ঠিক? বা শুধু প্রতিবাদী সম্পাদক?
স্যাম গোল্ডবার্গ

-1

যদি এটি সত্যিই ভেঙে যায় তবে এটি ঠিক করা উচিত।

তবে আসলেই কি এটি ভেঙে গেছে? আপনি কি নিশ্চিত যে আপনি কেবল "ভাঙাখুলি" ভাঙ্গার সাথে সমীকরণ করছেন না।

ওয়ার্কিং কোডটিকে পুনরায় ফ্যাক্টর করার আগে আপনাকে "ডুবানো মান" গণনা প্রয়োগ করতে হবে কারণ আপনি শৈলী পছন্দ করেন না বা, কারণ আপনি ভাবেন যে এটি ভবিষ্যতে সমস্যার কারণ হবে।

গত সপ্তাহে আপনি পুনরায় ফ্যাক্টরিং কোড লিখেছেন যে আপনি গত সপ্তাহে কোডিংয়ে ব্যয় করেছেন ডুবে যাওয়া ব্যয়, কোডটির যথেষ্ট উন্নতি হয়েছে কিনা তা নিয়ে বিরক্ত করার মতো মূল্য নেই।

রি-ফ্যাক্টরিং কোড যা ইউনিট পরীক্ষার মাধ্যমে হয়েছে। এখন আপনার কেবল নতুন করে লেখার দরকার নেই, আপনার এখন পর্যন্ত করা সমস্ত টেস্টিং পুনরায় সংজ্ঞায়িত এবং পুনরায় চালানো দরকার, এটি ব্যয়বহুল দেখাচ্ছে look

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

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


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

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

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

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

1
@ ওয়াইনেম - সুতরাং আপনি একটি "ত্রুটি" বাড়াবেন কারণ কোডটি দেখতে আপনার পছন্দ মতো নয়। কোড একটি কাজ করার জন্য লেখা হয় - যদি এটি কাজ করে তবে তার কাজ করে। রক্ষণাবেক্ষণের ব্যয় বেশি হতে পারে তবে এটি পুনরায় লেখার চেয়ে সস্তা হবে।
জেমস অ্যান্ডারসন

-2

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

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


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