খারাপ সফ্টওয়্যার আর্কিটেকচারের জন্য মানদণ্ড

খারাপ ডিজাইনের মানদণ্ড

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

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

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

এই সমস্যার মূল হল "খারাপ" ডিজাইনের সংজ্ঞার অভাব।

এটা আমার মনে হয় যে এটি ডিজাইনের গুণমান এবং এর "ক্ষয়" এর কারণগুলি বোঝা যা যেকোনো প্রোগ্রামারের জন্য সবচেয়ে গুরুত্বপূর্ণ গুণ। অন্যান্য বেশিরভাগ ক্ষেত্রে যেমন, প্রধান জিনিসটি সমস্যাটি চিহ্নিত করা, এবং এটি সমাধান করা প্রযুক্তির বিষয় হবে।

"খারাপ ডিজাইন" এর সংজ্ঞা

আপনি যদি একজন সহকর্মী প্রোগ্রামারের সামনে আপনার কোড নিয়ে বড়াই করার সিদ্ধান্ত নেন, তাহলে সম্ভবত আপনি উত্তরে উপহাস পাবেন: "কে এটা করে?", 'এটা এমন কেন?' এবং "আমি জিনিসগুলি অন্যভাবে করব।" এটা খুব প্রায়ই ঘটে.

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

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

খারাপ ডিজাইন:

• পরিবর্তন করা কঠিন কারণ যেকোনো পরিবর্তন সিস্টেমের অনেক অন্যান্য অংশকে প্রভাবিত করে। ( অনমনীয়তা , অনমনীয়তা)।
• যখন পরিবর্তন করা হয়, সিস্টেমের অন্যান্য অংশগুলি অপ্রত্যাশিতভাবে ভেঙে যায়। ( ভঙ্গুরতা , ভঙ্গুরতা)।
• কোডটি অন্য অ্যাপ্লিকেশনে পুনরায় ব্যবহার করা কঠিন কারণ এটি বর্তমান অ্যাপ্লিকেশন থেকে বের করা খুব কঠিন। ( অচলতা , অচলতা)।

এবং মজার বিষয় হল যে সিস্টেমের এমন একটি অংশ খুঁজে পাওয়া প্রায় অসম্ভব যেটিতে এই বৈশিষ্ট্যগুলির কোনটি নেই (অর্থাৎ নমনীয়, নির্ভরযোগ্য এবং পুনরায় ব্যবহারযোগ্য), প্রয়োজনীয়তা পূরণ করে এবং একই সাথে এর নকশাটি খারাপ। .

সুতরাং, একটি নকশা "খারাপ" বা "ভাল" কিনা তা দ্ব্যর্থহীনভাবে নির্ধারণ করতে আমরা এই তিনটি বৈশিষ্ট্য ব্যবহার করতে পারি।

"খারাপ ডিজাইন" এর কারণ

কোন ডিজাইনকে অনমনীয়, ভঙ্গুর এবং অস্থাবর করে তোলে? মডিউলগুলির অনমনীয় আন্তঃনির্ভরতা।

একটি নকশা অনমনীয় যদি এটি সহজে পরিবর্তন করা যায় না। এই দৃঢ়তা এই কারণে যে বোনা সিস্টেমে কোডের একটি অংশে একক পরিবর্তনের ফলে নির্ভরশীল মডিউলগুলিতে ক্যাসকেডিং পরিবর্তন হয়। এটি সর্বদা ঘটে যখন একজন ব্যক্তি কোডে কাজ করে।

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

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

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

ভঙ্গুরতা হল একটি সিস্টেমের একক পরিবর্তনের পরে একাধিক জায়গায় ভেঙে যাওয়ার প্রবণতা। সাধারণত পরিবর্তনের স্থানের সাথে ধারণাগতভাবে সম্পর্কিত নয় এমন জায়গায় নতুন সমস্যা দেখা দেয়। এই ধরনের ভঙ্গুরতা সিস্টেমের নকশা এবং রক্ষণাবেক্ষণে আস্থাকে গুরুতরভাবে হ্রাস করে।

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

যখন একটি প্রকল্পের একটি ভঙ্গুর আর্কিটেকচার থাকে, তখন বিকাশকারীরা পণ্যের গুণমানের গ্যারান্টি দিতে পারে না।

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

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

আপনার কি মনে আছে সেই JUL লগার, যার ডেভেলপাররা কোন যুক্তিসঙ্গত কারণ ছাড়াই তাদের নিজস্ব লগিং লেভেল নিয়ে এসেছে? এই মাত্র ঘটনা।

একজন ডিজাইনারকে একটি বিদ্যমান ডিজাইনের পুনঃব্যবহার করা কতটা সহজ সে সম্পর্কে ধারণা দেওয়ার জন্য, এটি একটি নতুন অ্যাপ্লিকেশনে ব্যবহার করা কতটা সহজ হবে সে সম্পর্কে চিন্তা করা যথেষ্ট।

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

প্রাসঙ্গিকতা

সবকিছু বদলে যায়, কিন্তু সবকিছু একই থাকে। (চীনা প্রবাদ)

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

একজন ম্যানেজার কীভাবে কিছু বৈশিষ্ট্য যুক্ত করার জন্য এগিয়ে যেতে বা না দিতে পারেন যদি তিনি জানেন না যে এটি আসলে কতটা সময় নেবে? আপনি যদি তাদের বাস্তবায়নের সময় এবং জটিলতা যথাযথভাবে অনুমান করতে না পারেন তবে কীভাবে কাজগুলিকে অগ্রাধিকার দেবেন?

এবং ডেভেলপাররা কীভাবে একই প্রযুক্তিগত ঋণ শোধ করতে পারে যখন আমরা এটি পরিশোধ করার জন্য রেক করব, এবং আমরা যতক্ষণ না রেক করব ততক্ষণ আমরা বুঝতে পারি না?

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

এখানে এই ক্ষেত্রে বব মার্টিনের একটি উদ্ধৃতি রয়েছে: "আপনার কোড পুনরায় ব্যবহার করার জন্য, আপনাকে স্ক্র্যাচ থেকে বিকাশের খরচের চেয়ে কম এটি পুনরায় ব্যবহার করার প্রচেষ্টা করতে হবে। " অন্যথায়, কেউ এই বিষয়টি নিয়ে মাথা ঘামাবে না।

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