অবজেক্ট অরিয়েন্টেড ডিজাইনে কী করতে হবে তা বাস্তবে কীভাবে খুঁজে পাবেন?


12

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

আমি পিএইচপি অধ্যয়ন যখন 2009 সালে প্রোগ্রাম শিখেছি। পরে ২০১২-এ, আমি সি # এবং .NET এ চলে এসেছি। যাইহোক, কোডিং সমস্যা নয়, অ্যালগরিদম লিখে আমার সমস্যা নয়। আমার আসল সমস্যাটি হ'ল কোনও প্রয়োজনীয়তা অর্জনের জন্য কী কোডিং করতে হয় এবং এটি কোথায় কোডিং করতে হয় তা জানা।

ওয়েবে উপস্থিত বেশিরভাগ কোর্সগুলি কীভাবে - একটি নির্দিষ্ট ভাষায় কোড কীভাবে লিখতে হয়, কীভাবে কিছু এপিআই এর সেট ব্যবহার করতে হয় ইত্যাদি ইত্যাদি বিষয়টিকে মোকাবেলা করে That's এটি এখানে আমার বক্তব্য নয়।

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

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

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

বেশিরভাগ সময়, বেশ অনেক চিন্তাভাবনার সাথে আমি কিছু ধারণাগুলি দিয়ে শেষ করি, তবে আমার ধারণাটি সঠিক কিনা সে সম্পর্কে আমি কখনই বিচার করতে পারি না।

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

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

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


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

2
২. উইনফর্মগুলিতে লিখিত পুরানো অ্যাপ্লিকেশনগুলি যথাযথভাবে আর্কিটেক্ট না করা হলে কাদা বড় বলগুলিতে পরিণত হয়। উদ্বেগের পৃথকীকরণ সর্বজনীন হয়ে ওঠে। Winformsmvp.codeplex.com
রবার্ট হার্ভে

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

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

1
আমি একই সাথে এইটিকে উচ্চতর করতে এবং ভিটিসি করতে চাই ...
এসভিডজেন

উত্তর:


21

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

ঠিক আছে সবার আগে, অবজেক্ট অরিয়েন্টেড ডিজাইনের কথা চিন্তা করা বন্ধ করুন। এটাই ইংলিশকে সঠিক বলে ভাবার মতো।

অবজেক্ট ওরিয়েন্টেড দৃষ্টান্তটি সঠিক নয়। এটির কিছু সুবিধা এবং অসুবিধা রয়েছে। এটি একটি আদর্শ। এটি আমাদের একমাত্র নয়। এটি কোনও কিছুর চেয়ে ভাল তবে এটি অবশ্যই সবকিছু নয়।

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

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

সমস্যাটি হ'ল আমরা সে সব করার জন্য অর্থ পাচ্ছি না। আমরা পেশাদাররা যে কারণে এটি করি। আমাদের যখন বসের সন্ধান না হয় তখন আমাদের সমস্ত কিছুই করতে হবে কারণ সবসময় একটি সময়সীমা থাকে। তবে আমরা 5 বছরে ফিরে আসতে এবং নবদম্পতিদের বলতে চাই: "ওঁ হ্যাঁ, আমি এটি লিখেছিলাম। এখনও হাহ কাজ করে? শীতল?"

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

পড়ুন। প্রশ্ন। পরীক্ষা করুন। পদ্ধতি পুনরাবৃত্তি করুন।

আপনি যখন এই বিষয়টিতে পৌঁছে যান যে আপনি আপনার জীবনের ৮০% এর জন্য এটি করছেন আপনি আমার মতোই বিভ্রান্ত হবেন।

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

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


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

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

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

1

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

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

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

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

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

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

আপনাকে রিফ্যাক্টরের অনুমতি দেওয়ার জন্য পর্যাপ্ত স্বয়ংক্রিয় পরীক্ষার সমাপ্তির জন্য আপনার বিশেষভাবে টিডিডি / বিডিডি এর মতো কঠোর বিকাশ পদ্ধতি অনুসরণ করার দরকার নেই; ভবিষ্যতে দুর্ঘটনাজনিত ব্রেকিং পরিবর্তনের বিরুদ্ধে কোডটি সুরক্ষিত করার জন্য আপনার যথেষ্ট দরকার ।

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

এটি কীভাবে সহজে-টেস্টেবল কোড লিখতে হয় সে প্রশ্ন উত্থাপন করে; SOLID নীতি অনুসরণ করার জন্য এটি সাধারণত প্রধান যুক্তি; প্রকৃতপক্ষে, কোডের হলমার্ক যা সলাইডের নীতিগুলি মেনে চলে তার হ'ল ইউনিট পরীক্ষাগুলি লেখার জন্য এটি সহজ এবং সময় / ব্যয় কার্যকর।

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


1
আমাদের কাছে স্বয়ংক্রিয় পরীক্ষাগুলি লেখার সময় নেই তবে আমরা সবসময় বার বার ম্যানুয়াল পরীক্ষা চালিয়ে যাচ্ছি ...
নিক কেইগলি

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

@ ডাঙ্ক আমি মনে করি না কোডটি আশা করা কখনই পরিবর্তন বা পুনর্বিবেচনা করা উচিত নয় istic ইউনিট টেস্টিং অনুশীলনগুলি এবং সলড গাইডলাইনগুলি এমন উত্সাহজনক অনুশীলনগুলির সম্পর্কে যা অনিবার্য ঘটে যখন কোডটি পরিবর্তন করা সহজ এবং সস্তা cheap উদাহরণস্বরূপ কেউ সত্যই একটি অদ্ভুত বাগ খুঁজে পায় যা বিকাশকারী সেই সময়ে বিবেচনা করেনি, বা গ্রাহকটি দেখে সমাধান এবং প্রয়োজনীয়তাগুলি পরিবর্তন করে বা মূল কোডটিতেও ভুল রয়েছে কারণ বিকাশকারীরা কেবলমাত্র মানব; অথবা হতে পারে বিকাশকারী প্রয়োজনীয়তাগুলি ভুল বুঝেছিলেন, বা পূর্বে অজানা প্রযুক্তিগত সীমাবদ্ধতাগুলি আবিষ্কার করেছেন ...
বেন কট্রেল 20

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

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