ওওপি-র অতিরিক্ত জটিলতার জন্য কি কোনও শব্দ রয়েছে?


18

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

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

আমি সত্যিই যা খুঁজছি তা হ'ল সাক্ষাত্কারের সময় এটিকে সামনে আনা। আমি জানতে চাই যে কেউ আর্কিটেকচার / প্রাক পরিকল্পনার অভাবের সাথে এর মধ্যে পড়ে যাওয়া কতটা সচেতন এবং সচেতন কিনা (এবং তারা সঠিক জায়গায় ভারসাম্য বজায় রাখছেন বলে মনে হচ্ছে কিনা) তবে এটি আসলে কিছু নয় আমি অনেক তথ্য খুঁজে পেতে পারেন।


25
হ্যাঁ, এটিকে ওওপি বলা হয়।
গার্ডেনহেড

উত্তর:


28

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

আরও সাধারণ স্তরে, জোয়েল স্পলস্কি এমন ডিজাইনারদের দিয়েছিলেন যারা আর্কিটেকচার ডিজাইনাকে " আর্কিটেকচার অ্যাস্ট্রোনটস " নামটি কাটিয়ে ওঠেন ।

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


ধন্যবাদ। আমি ইয়াজিএনআই-এর বড় উকিল, সাধারণ বিপরীত ছিল কিনা তা নিশ্চিত ছিল না।
jleach

আমি জোর দিয়ে বলব যে ইয়াগনি "এখনই যা প্রয়োজন তা" সম্পর্কে is আপনার এখনও জিনিসগুলি বাইরে রাখা উচিত, যদিও এটি জানা থাকলে এটি পরে প্রয়োজন হবে, যতক্ষণ না এখনই এটি প্রয়োজন হয় না।
বেন্ট করুন

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

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

4

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

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

সুতরাং সংক্ষিপ্তসার হিসাবে, কোডের অত্যধিক জটিলতা রোধ করতে:

1) KISS (এটি সাধারণ বোকা রাখুন)

2) সলিড নীতিগুলি ব্যবহারিকতার মাথায় রেখে অনুসরণ করুন।

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

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

5) কোড আপনি যদি এটি এক যে এটি বজায় রাখতে চলেছে।


-3

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

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


4
আমি দুঃখিত, তবে আমি সত্যিই ভাবছিলাম যে এর কোনও শব্দ আছে কিনা। আমি কীভাবে একটি সাক্ষাত্কার পরিচালনা করব (বা আমি কীভাবে একটি সাক্ষাত্কার করব তা আমার প্রশ্নটি কোনওভাবেই অনুধাবন করা উচিত) সম্পর্কে পরামর্শ খুঁজছিলাম না। আপনার উদ্বেগ যদিও ... জন্য ধন্যবাদ
jleach

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