জটিলতা বিন্দু না ফেরার। এটাকে কী বলো?


13

সফ্টওয়্যার বিকাশকারী হিসাবে, আমার অন্যতম প্রধান কাজ হ'ল জটিলতা নিয়ন্ত্রণে রাখা।

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

প্রোগ্রামারদের উপভাষায় এই বিশেষ মুহুর্তটির কি কোনও নাম আছে (ট্রলসের জন্য গডউইনের আইনের তুলনায় কিছুটা)?

--edit--

আমি পরিষ্কার না হলে দুঃখিত। আমি মনে করি না এই "মুহুর্ত" এর একটি অফিসিয়াল নাম আছে, বা এটি একটি গুরুতর মেট্রিক। আমি xkcd এর " বলার পিক" এর আত্মার মধ্যে কিছু সম্পর্কে ভাবছিলাম ।


1
আপনার প্রশ্নের সংখ্যার সংজ্ঞাটিতে আমি একটি বিতর্ক দেখতে পাচ্ছি: ... কম সময়ে আপনাকে স্ক্র্যাচ থেকে সমস্ত কিছু নতুন করে লেখার প্রয়োজন হবে , যা বোঝায় যে যারা প্রকল্পটি পুনর্লিখন করতে যাচ্ছেন তারা যথেষ্ট ভাল, বা কমপক্ষে যারা তাদের চেয়ে ভাল better প্রথম জায়গায়
গণ্ডগোল

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

1
হতে পারে এটি: কারিগরি
tণ

উত্তর:


20

জটিলতার চেয়ে এটি রক্ষণাবেক্ষণের বিষয় ।

ঘটনাকে "প্রযুক্তিগত debtণ" বলা হয়, এবং এটি একবার সমালোচনামূলক পর্যায়ে পৌঁছে গেলে প্রকল্প দেউলিয়া হওয়ার পথে।

আপনি কি বোঝাতে চেয়েছিলেন?


আপনার উত্তরের জন্য ধন্যবাদ। আমি "প্রযুক্তিগত বিভাগ" এর ধারণা সম্পর্কে সচেতন। প্রতিটি প্রকল্পে একরকম প্রযুক্তিগত debtণ থাকে। আমার অর্থটি হ'ল: এই debtণটি এতটা প্রসারিত হয়ে যাওয়ার মুহূর্তটিকে আপনি কীভাবে বলবেন যে আপনি এই প্রকল্পটিকে আবর্জনার দিকে ফেলে দিয়ে আবার শুরু করতে পছন্দ করবেন?
থিবল্ট জে

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

2
@ থিবল্ট জে: আমি বিশ্বাস করি না যে সেই মুহুর্তের জন্য একটি নির্দিষ্ট শব্দ রয়েছে। আপনি যদি সেই সময়ের আগে এখনও সুখে বা দুঃখের সাথে এর বাইরে চলে যান তবে তা উপলব্ধি করা আরও বেশি

1
@ বিকাশকারী আর্ট: ... বুঝতে পেরে আপনি যদি সেই সময়ের আগে এখনও সুখে বা দুঃখের সাথে এর বাইরে চলে গিয়েছিলেন - আমি মনে করি এটিই মূল বিষয়টির একটি ভাল সংজ্ঞা দেওয়ার মূল বিষয়: একটি প্রকল্প যা বিন্দু ছাড়িয়ে গেছে কোনও ইঞ্জিনিয়ার হবে না স্বেচ্ছায় গ্রহণ
মোজুবা

3
আমি "প্রযুক্তিগত দেউলিয়া" মেয়াদে যাব, আমি এটি পছন্দ করি। এবং আমি আপনার সংজ্ঞা ব্যবহার করব।
থিবল্ট জে

16

"অতিরিক্ত জটিলতার বিন্দু" ইংরাজীতে উল্লেখ করা হয়েছে:

ওহ আমার THশ্বর এই করপটি কি।

সমস্যাটি হ'ল, এটি সত্যিকারের সহজ কিছুতে প্রযোজ্য হতে পারে তবে এটি এমন এক ভয়াবহ উপায়ে প্রয়োগ করা হয় যাতে আপনার একই প্রতিক্রিয়া হয়।

সুতরাং খুব ভয়ঙ্কর কিছু থেকে খুব জটিল কিছু পৃথক করা কঠিন হতে পারে।

হাওভার: আসলে সমস্ত সফ্টওয়্যারের ক্ষেত্রে যা ঘটে তা হ'ল প্রক্রিয়াটি কিছুটা এইরকম:

পদক্ষেপ 1: একটি দুর্দান্ত অনুমান আছে, একটি দুর্দান্ত নকশা করুন, সুন্দর স্টাফ বাস্তবায়ন করুন। সবাই খুশি।

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

পদক্ষেপ 2: কিছু পরিবর্তন করা হয়, জিনিস যুক্ত হয়, নতুন ফাংশন অন্তর্ভুক্ত করা হয়। পদক্ষেপ 1 এর আর্কিটেকচার এবং কাঠামো এটিকে মোটামুটি ব্যথাহীন প্রক্রিয়া করেছে। [তবে উফ, "ক্রাফ্ট ফ্যাক্টর" সবেমাত্র কিছুটা বাড়িয়েছে]]

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

পদক্ষেপ 3: আরও পরিবর্তন করা হবে, আরও কিছু জিনিস যুক্ত হবে, আরও নতুন ফাংশন হবে, একগুচ্ছ জিনিস বদলে যাবে, ব্যবহারকারীর প্রতিক্রিয়া আসলে শোনা যাচ্ছে।

পদক্ষেপ 3 এর শেষে: বিকাশকারীরা তাদের ডিজাইনের অপূর্ব কমনীয়তার জন্য নিজেকে অভিনন্দন জানায় এবং মোটামুটি খুশি চিন্তাভাবনা থেকে দূরে চলে যায় "জি এই স্থাপত্যটি এতগুলি পরিবর্তন সহজেই স্লট করার অনুমতি দিতে বেশ ভাল। তবে আমি কিছুটা অসন্তুষ্ট I'm এক্স এবং ওয়াই এবং জেড সম্পর্কে। তারা এখন কিছুটা পরিষ্কার করা যেতে পারে But তবে !!! আহ্ !!! আমি এই সমস্ত ভাতাটি প্রথম ধাপে দিয়েছি বলে আমি খুব চালাক This এটি এত ভাল হয়েছে for আমার এখানে একটি দুর্দান্ত উত্তরাধিকার আছে for ভবিষ্যতে অন্যদের জিনিস যুক্ত করার জন্য এটি দুর্দান্ত থাকবে এবং পৃথিবী আরও ভাল জায়গা হবে "।

পদক্ষেপ 4: ঠিক 3 ধাপের মতো: বাদে:

চতুর্থ ধাপের শেষে: বিকাশকারীরা মনে করেন: "এই জিনিসগুলি যা খুব ভাল ছিল তা বজায় রাখার জন্য কৌতুক পাচ্ছে It এটিতে কিছু গুরুতর পরিবর্তন দরকার I'm আমি সত্যিই এটির সাথে কাজ করতে পছন্দ করি না It এটির পুনঃসংশোধক প্রয়োজন I আমি আশ্চর্য হলাম বস কী যখন আমি তাকে বলব যে এটির জন্য 6 সপ্তাহ প্রয়োজন এবং ব্যবহারকারীরা এর শেষে দেখার মতো কিছুই পাবেন না ... তবে আমি আরও 5 বছরের স্বাদযুক্ত ভবিষ্যতের পরিবর্তনের সুযোগটি পেয়ে যাব .... এইচএমএমএম .. "কিছু বিয়ারের জন্য পাব যাওয়ার সময়"

পদক্ষেপ 5: একগুচ্ছ পরিবর্তন করা দরকার।

এবং 5 ধাপের ধাপে বিকাশকারীরা একে অপরকে বলে: "এই কোডটি সফল হয়। এটি কে লিখেছিল? তাদের গুলি করা উচিত Its এটি ভয়াবহ। আমরা এটি পুনরায় লিখতে চাই TO"

5 ধাপটি মারাত্মক। এই স্থানে ক্রাফ্ট ফ্যাক্টরটি এতটাই খারাপ হয়ে উঠেছে যে কোডটিতে আরও কয়েকটি পরিবর্তন হতে পারে না, এটিতে আরও কিছু বিগ পরিবর্তন করা দরকার।

5 ধাপের ঝামেলা হ'ল এটিকে ফেলে দেওয়া এবং আবার শুরু করার ইচ্ছা। এটি মারাত্মক হওয়ার কারণটি হ'ল "নেটস্কেপ ফ্যাক্টর"। এটি গুগল যান। সংস্থাগুলি এই মুহুর্তে ডিআইই, কারণ আবার শুরু করার অর্থ আপনি তথ্যের পরিবর্তে প্রায় 50% অনুমান, জ্ঞানের পরিবর্তে 150% উত্সাহ, বিনয়ের পরিবর্তে 200% দাম্ভিকতা ("এই লোকগুলি এত বোকা!") দিয়ে শুরু করেছিলেন। এবং আপনি নতুন বাগগুলির পুরো গোছা পরিচয় করিয়ে দিন।

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


আমি বাজি ধরছি যদি আপনি আপনার পদক্ষেপগুলি সংক্ষিপ্ত করেন তবে আপনি বেশি ভোট পাবেন।
কোডিমে

আমাকে যুক্ত করতে হবে যে বেশিরভাগ ব্যবসায়গুলি এর জন্য বাজেট করে না, তাই রিফ্যাক্টরিং সবসময় খুব দেরিতে হয়। সিস্টেমগুলির ক্রমবর্ধমান এনট্রপি পরিচালনা করার জন্য, প্রথম দিন থেকে, গৃহকর্মের জন্য প্রতিটি কাজ থেকে একটি বাজেট (10% -20%) বরাদ্দ করা হয়। এটি কোনও বাগ ফিক্স বাজেট নয়। বাজেট ব্যয়টি ইঞ্জিনিয়ারিং দ্বারা পরিচালিত হয়, পরিচালনা বা বিপণন বা বিক্রয় নয়। এটি কেবলমাত্র বিকাশের দ্বারা নির্মিত এন্ট্রপিকে ফ্যাক্ট করতে ব্যবহৃত হয়, এবং পণ্য জীবনের শেষের দিকে আসার সাথে সাথে ব্যয় হ্রাস পায়।
mattnz

একমত। পরিচালনা সবসময় এই জাতীয় জিনিসটি ছাঁটাই করতে চায়। কখনও কখনও আপনি এটি লুকিয়ে রেখে পালিয়ে যেতে পারেন (কিছু করার জন্য বিকাশের প্রাক্কলনে প্রায় 20% যোগ করুন, এবং যখন রিফ্যাক্টরিং প্রয়োজন হয় - এটি করুন)।
দ্রুত_ এখন

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

2

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


1

খুব সহজেই ভাল কোডটি এই মিথ্যা ছাপের ভিত্তিতে বাতিল করা হয় যে নতুন সরঞ্জামগুলির সাথে নতুন দলটি এটি আরও সস্তার, আরও নির্ভরযোগ্যতার সাথে দ্রুততর করতে পারে, কেবল এটিই খুঁজে পেতে

  • জটিলতা হ'ল পূর্বাভাস সংক্রান্ত প্রয়োজনীয়তাগুলিতে
  • নতুন সরঞ্জামগুলি ব্যবহার করা আরও শক্ত এবং তারপরে ফ্ল্যাশ ওয়েবসাইটটি প্রতিশ্রুতি দেয়
  • নতুন দলটি যেমনটি ভেবেছিল তেমন 'গরম' নয়

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

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


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

তবে এটি এত চ ** এড আপ কীভাবে পেল? যদি জটিল জটিলতার কারণে, খারাপ পরিচালনার কারণে, অপটিমাস্টিক ইঞ্জিনিয়ারদের থেকে থাকে তবে কেন পুনরায় লেখক এটি সংশোধন করবে?
mattnz

কারণ দলটি পুনরায় লেখার কাজটি শুরুতে যারা লিখেছেন, তার মতো নয়?
থিবল্ট জে

1

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

তবে আমি পছন্দ করি যে আমরা এটির একটি নাম দিতে পারি। "জেন্টস," আপনি বলতে পারেন, আপনার সহকর্মী বিকাশকারীদের আপনার চারপাশে টেনে নিয়ে এসেছেন, "আমরা রক্ষণাবেক্ষণ হেলসপন্টটি পেরিয়ে গিয়েছি your


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

@ থিবল্টজে - সম্ভবত আপনার সহকর্মীরা সাইকোপ্যাথ হয়েছেন?
ড্যান রে

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

আমার শেষ কাজটিতে, আমি মনে করি না যে কোনও রক্ষণাবেক্ষণের প্রতিশ্রুতি রয়েছে যে কেউ কখনও বিশ্বাস করে যে এটি কোডবেসের উন্নতি with
ববি টেবিল

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

-1

কোনও নাম আছে কিনা তা আমি জানি না তবে যদি কিছু না থাকে তবে আমি এটিকে "মেল্টডাউন পয়েন্ট" বলার প্রস্তাব দেব


বা অন্য পারমাণবিক শব্দ ধার করা: সমালোচনা ভর
জন ক্রোমার্টি

-2

এটি খুব আকর্ষণীয় প্রশ্ন নয়।

আসলে এটি তুচ্ছ।

এটি এত তুচ্ছ যে আমরা মোকাবেলার জন্য অনেকগুলি উপায় বিকশিত করেছি।

  1. জলপ্রপাত পদ্ধতি। জটিলতা পরিচালিত হয়েছে কিনা তা নিশ্চিত হতে প্রচুর লোক প্রয়োজনীয়তা এবং ডিজাইন ডক্স পর্যালোচনা করতে প্রচুর সময় ব্যয় করে।

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

"জটিলতা" নিয়ে যে কেউ কেবল একবার কুস্তি খায় সেই কারণটি পদ্ধতিটি অনুসরণ করতে এবং সঠিকভাবে তাদের সময় পরিচালনা করতে ব্যর্থ হয়।

  • জলপ্রপাত পদ্ধতিতে কোনও তদারকি নেই। প্রয়োজনীয়তা, আর্কিটেকচার, উচ্চ-স্তরের নকশা বা বিশদ নকশার পর্যালোচনাগুলিতে তারা মধ্যবর্তী কাজের পণ্যগুলি পর্যালোচনা করতে বাধ্য হয় না।

  • কোনও চৌকস পদ্ধতিতে কোনও স্প্রিন্টের সময়সীমা বা সঠিক ব্যবহারের ক্ষেত্রে অগ্রাধিকার নেই। তারা যত তাড়াতাড়ি সম্ভব ব্যবহারকারীর কাছে কিছু ছেড়ে দেওয়ার বিষয়ে দৃষ্টি নিবদ্ধ করে না।

জটিলতা লক্ষ্য নির্ধারণের মাধ্যমে সীমাবদ্ধ করা উচিত।

জটিলতার সাথে লড়াই করার অর্থ লক্ষ্য নির্ধারিত হয় না বা সঠিকভাবে পুরস্কৃত হয় না।

কোনও "টার্নিং পয়েন্ট" নেই। জটিলতা পরিচালনা যদি কোনওভাবে সমস্যা হয় তবে সাংগঠনিকভাবে কিছু ইতিমধ্যে ভুল।


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

@ ডেভিড থর্নলি: এটি আমার বক্তব্য। "প্রত্যাবর্তনের জটিলতা বিন্দু" বিদ্যমান নেই। এটি কেবল সাধারণ-পুরানো খারাপ পরিচালনা। একটি পরিশীলিত নাম বা নিয়মের কোনও প্রয়োজন নেই। জটিলতা খারাপ পরিচালনার লক্ষণ মাত্র। সত্যিই খুব আকর্ষণীয় নয়।
এস .লট

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

@ ডেভিড থর্নলি: আমি মনে করি খারাপ পরিচালনা (যা সবাইকে ত্যাগের দিকে নিয়ে যায়) থেকে খারাপ পরিচালনা (যা ভয়াবহ জটিলতার দিকে পরিচালিত করে )কে ছিন্ন করা খুব কঠিন hard কোনও প্রকল্প খুব জটিল হয়ে উঠবে বা ঠিক দেরিতে বা কেবলমাত্র অক্ষম হবে কিনা তা বলার উপায় আমি দেখতে পাচ্ছি না।
এস .লট

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

-2

(বড়) প্রকল্প এবং কোডের জটিলতা বৃদ্ধির ঝুঁকিটি কল্পনা এবং নিরীক্ষণের জন্য এমন পদ্ধতি রয়েছে। এগুলি যখন যুক্তিসঙ্গতভাবে প্রয়োগ করা হয় তখন আশা করি কোনও প্রত্যাবর্তনের পয়েন্টের জন্য একটি নতুন নামের প্রয়োজন হবে না। (ওপেনএইচপিআইতে সম্পর্কিত এমওওসি রয়েছে: https://open.hpi.de/courses/softwareanalytics2015/ )

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

কাঠামোগত জটিলতা হ্রাস করার কয়েকটি উপায় হ'ল http://www.buch.de/shop/home/suche/?fq=3540878890 :

  • modularisation
  • প্রতিক্রিয়া লুপ এড়ানো
  • ট্রায়াঙ্গুলেশন

তদুপরি অ্যাক্সিয়োমেটিক ডিজাইনের ধারণা রয়েছে: https:। En.wikedia.org \ wiki x axiomat_design \ এই ধারণার সাথে আনইনসেসরিজ জটিলতার কারণে নির্ভরযোগ্য সমস্যাগুলি এড়ানো যায়।

এইভাবে বিভিন্ন পদ্ধতি উপলব্ধ রয়েছে। শেষ পর্যন্ত সবসময় তাদের সম্পর্কে ভাবার সিদ্ধান্তের বিষয়ে থাকে কারণ একটি প্রকল্প যথেষ্ট বড় হয়ে যায়।


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