ভবিষ্যতে পরিবর্তনগুলির জন্য নকশা করুন বা সমস্যাটি সমাধান করুন [বন্ধ]

Question

কোডটি লেখার সময় বা ডিজাইনের সময় আপনি নিজেই প্রথম সমস্যাটিকে সাধারণীকরণ করার চেষ্টা করেন বা খুব নির্দিষ্ট সমস্যাটি সমাধান করার চেষ্টা করেন।

আমি এটি জিজ্ঞাসা করছি কারণ সমস্যাটি সাধারণ করার চেষ্টা করার ফলে বিষয়গুলিকে জটিল করা যায় (যা প্রয়োজন নাও হতে পারে) এবং অন্যদিকে প্রয়োজনে কোনও পরিবর্তন হলে নির্দিষ্ট সমাধানটি প্রসারিত করা খুব কঠিন হবে।

আমি অনুমান করি সমাধানটি মধ্যবর্তী পথটিই সন্ধান করা যা কাজটির চেয়ে সহজ easier আপনি কিভাবে এই ধরণের সমস্যা মোকাবেলা করবেন? আপনি যদি কোন সময়ে সাধারণীকরণ শুরু করেন তবে আপনি জানেন যে সাধারণীকরণের এই যথেষ্ট পরিমাণে যথেষ্ট?

Comments

আরও দেখুন: দামের জন্য থাম্বের বিধি বনাম কোড পুনরায় ব্যবহারের জন্য সঞ্চয় , তৃতীয়বারের তৃতীয়বার অপেক্ষা করা যুক্তিযুক্ত?

— gnat

এটি একটি খুব গুরুত্বপূর্ণ প্রশ্ন জিজ্ঞেস করে: প্রয়োজনীয়তাগুলি কীভাবে পরিবর্তিত হবে আপনি কী সত্যিই অনুমান করতে পারেন?

— ব্যবহারকারী16764

প্রচুর ভাবেন আপনাকে YAGNI বলবে। আপনি যখন তাদের কাজ নিতে হবে তখন সেই লোকেরা আপনাকে ঘৃণা করবে।

— মার্টিন মাট

Answer 1

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

এটি থাম্বের একটি নিয়মে সিদ্ধ করতে: কম বেশি হয়।

Comments

+1 "ভবিষ্যতে আগের মতো হয় না" "

— ড্যান লিয়ন্স

Answer 2

আপনি কি চপলতার সাথে পরিচিত? Agile এর অন্যতম বড় নীতি হ'ল YAGNI । আমি জিনিসগুলির কাছে যাওয়ার সেরা উপায় এটি।

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

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

সমর্থনমূলক অনুশীলনের সাথে একত্রিত হয়েও YAGNI বৈধ নীতি হিসাবে সর্বজনীনভাবে গ্রহণযোগ্য নয়। এটি স্ট্যান্ডেলোন ব্যবহার না করে সমর্থনকারী অনুশীলনের সাথে একত্রিত করার প্রয়োজনীয়তা এক্সপির মূল সংজ্ঞার অংশ ...

Comments

যদিও আমি কমবেশি ইয়াজিএনআইয়ের সাথে একমত হই, তবুও আমি এটি চতুর

— জেনস স্কাউডার

"সরলতা - না করা কাজের পরিমাণকে সর্বাধিককরণের শিল্প - প্রয়োজনীয়," YAGNI এবং কিছু অন্যান্য চতুর অভ্যাসের ক্ষেত্রে প্রযোজ্য।

— tvanfosson

যদিও ইশতেহারে এটি "YAGNI" বিশেষভাবে বলে না, আমি মনে করি তারা একে অপরের সাথে সামঞ্জস্যপূর্ণ।

@ জেনস এবং @ ম্যাট, ইয়াজিএনআই, এক্সপি এর মাধ্যমে "চটজলদি" পদ্ধতি হিসাবে বান্ডিল হয়ে চটপটে রয়েছে। উইকিপিডিয়া নিবন্ধে উল্লিখিত হিসাবে, ইএজিএনআই নীতিটি রন জেফরিস এক্সপি মূল অনুশীলনের অংশ হিসাবে তৈরি করেছিলেন।

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

— রবার্ট করিতনিক

Answer 3

এটি সম্ভবত সফ্টওয়্যার বিকাশের সবচেয়ে জটিল অংশগুলির একটি কারণ আপনাকে "YAGNI" এবং "পিওয়াইআইএসি" (নিজেকে কোণে আঁকুন) এর মধ্যে লাইনটি চলতে হবে।

এটি "আপনার কোনও প্রয়োজন না হলে কোনও বৈশিষ্ট্যটি লিখবেন না" বলা খুব সহজ। হার্ড অংশটি আপনার কোডটি ডিজাইন করছে যাতে আপনার যখন প্রয়োজন হয় তখন আপনি সহজেই বৈশিষ্ট্যগুলি যুক্ত করতে পারেন।

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

Answer 4

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

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

Answer 5

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

Answer 6

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

আমি মনে করি আমি অন্য লোকদের এর প্রভাব সম্পর্কে কিছু বলতে শুনেছি:

আমি সমস্যাটি প্রথমবার সমাধান করেছি। আমি যখন প্রথমবার আমার সমাধানটির পুনরাবৃত্তি করি তখন আমি এটি নোট করি। আমি আবার এটি পুনরাবৃত্তি যখন, আমি চুল্লি।

Answer 7

"এখন + 1" এর জন্য ডিজাইন। এর অর্থ হ'ল তাত্ক্ষণিক সমস্যাটি সমাধান করুন, এবং পর্যাপ্ত কার্যকারিতা তৈরি করুন যাতে পরের বার তারা কোনও পরিবর্তন চাইবে, আপনি ইতিমধ্যে এটি অর্ধেক (বা আরও) সম্পন্ন করেছেন এবং একটির পছন্দ আছে) তা অবিলম্বে সমাধান করে এবং পরে রিফ্যাক্টরিং, বা খ) আবার "এখন + 1" সমাধান করা ("এখন" অর্ধেকটি সম্পন্ন করে)

এটি প্রকল্প নির্ভর করে এবং সংক্ষেপে, অভিজ্ঞতা আপনাকে "+1" কী তা শিখিয়ে দেবে।

Answer 8

ইয়াএগএনআই- এর দর্শন , আপনার দরকার নেই, এর সংক্ষিপ্তসার দেওয়া যেতে পারে (নিবন্ধ থেকে):

যারা YAGNI পদ্ধতির পক্ষে ছিলেন তাদের মতে, কোডটি লেখার প্রলোভন যা এই মুহুর্তে প্রয়োজনীয় নয়, তবে ভবিষ্যতে হতে পারে, নিম্নলিখিত অসুবিধাগুলি রয়েছে:

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

Answer 9

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

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

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

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

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

কি বলছে? "আপনার সমস্ত কিছু যখন হাতুড়ি হয়ে যায় তখন সমস্ত কিছুই পেরেকের মতো দেখতে শুরু করে।"

আমি যখন কাউকে বলতে শুনেছি প্রতিবারের জন্য আমি এক পাউন্ড পেয়েছি, "তবে এটি এমন একটি সমাধান যা ভবিষ্যতে আমরা দেখতে পাচ্ছি যে সাধারণ ক্ষেত্রে এটি আরও উপযুক্ত হবে ad"