2.2 সফটওয়্যার নকশার নীতি

পরিচিতি ও প্রেরণা

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

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

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

মূল নীতিসমূহ

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

সুপারিশ

SOLID-কে চেকলিস্ট নয়, লেন্স হিসেবে ব্যবহার করুন

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

DRY প্রয়োগ করুন জ্ঞানে, পাঠ্যে নয়

DRY হলো জ্ঞানের একটি প্রামাণ্য অংশ পুনরাবৃত্তি না করা। এটি কেবল দেখতে একই রকম লাইন দূর করা নয়। কোডের যে দুটি অংশ দেখতে একই কিন্তু ভিন্ন কারণে বদলায় সেগুলো আলাদা থাকা উচিত। অসম্পর্কিত জিনিসকে যুক্ত করা অকালপক্ব ভাগ করা বিমূর্তনের চেয়ে সামান্য পুনরাবৃত্তি পছন্দ করুন। প্রকৃত প্যাটার্ন দুই-তিনবার দেখা দিলে বিমূর্তন বের করুন।

KISS ও YAGNI-কে জল্পনা প্রতিরোধ করতে দিন

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

নিম্ন সংযুক্তি ও উচ্চ সংসক্তির জন্য সুস্পষ্টভাবে নকশা করুন

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

নকশা প্যাটার্নকে শব্দভাণ্ডার হিসেবে ব্যবহার করুন, অ্যান্টি-প্যাটার্নকে সতর্কতা হিসেবে

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

ডোমেইন জটিল হলে ডোমেইন-ড্রিভেন ডিজাইন গ্রহণ করুন

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

খাপ অনুযায়ী প্যারাডাইম বেছে নিন

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

ট্রেড-অফ: সুবিধা ও অসুবিধা

নীতি / পদ্ধতি	ভালোভাবে প্রযুক্ত হলে	ব্যর্থতার ধরন
SOLID	যেখানে পরিবর্তন ঘটে সেখানে স্পষ্ট জোড়; পরীক্ষণযোগ্য একক	ইন্টারফেস ও স্তরের বিস্তার; প্রতিদানহীন পরোক্ষতা
DRY	প্রকৃত জ্ঞানের জন্য সত্যের একক উৎস	ভুল বিমূর্তন অসম্পর্কিত কোডকে যুক্ত করে
KISS / YAGNI	ছিমছাম, বোধগম্য সিস্টেম	কম-নকশা করা জোড়; প্রয়োজনীয় নমনীয়তার ব্যয়বহুল পরে-জোড়া
নকশা প্যাটার্ন	ভাগ করা শব্দভাণ্ডার; প্রমাণিত কাঠামো	প্যাটার্নের কার্গো-কাল্ট; আকস্মিক জটিলতা
ডোমেইন-ড্রিভেন ডিজাইন	সারিবদ্ধ মডেল ও দল; বশে আনা জটিলতা	সরল ডোমেইনে ভারী আনুষ্ঠানিকতা; ভুল জায়গায় কনটেক্সট সীমানা
ফাংশনাল / অপরিবর্তনীয়	পূর্বানুমেয়তা; নিরাপদ কনকারেন্সি	স্বভাবত অবস্থাযুক্ত সমস্যায় আনাড়ি খাপ; পারফরম্যান্সের চমক

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. একটি ভাগ করা বিমূর্তন বের করার আপনার সুনির্দিষ্ট সীমা কী, এবং DRY-কে ভুলটি তৈরি করা থেকে কীভাবে ঠেকাবেন? এই অধ্যায় সোজাসুজি বলে ভুল বিমূর্তনের চেয়ে পুনরাবৃত্তি সস্তা, এবং বের করার আগে প্যাটার্ন দুই-তিনবার দেখা দেওয়া পর্যন্ত অপেক্ষা করা উচিত। বড় দলে বিপদ হলো কেউ দুটি দেখতে-একই কোড-টুকরো দলের সীমানা পেরিয়ে একটি ভাগ করা মডিউলে গুছিয়ে ফেলেন, তারপর একটি কলারের প্রতিটি ভবিষ্যৎ পরিবর্তন অন্যটিতে ঢেউ তোলে। যে সংকেত আনতে হবে তা হলো পুনরাবৃত্ত অংশ একই কারণে বদলায় নাকি আপাতত কেবল দেখতে একই। তিনের নিয়মে একমত হন, এবং কলারদের যুক্ত করার আগে একটি প্রার্থী বিমূর্তন সত্যিই একসঙ্গে বদলেছে কি না আবশ্যক করুন। সেই একটি সমঝোতা এমন এক শ্রেণির সংযুক্তি ঠেকায়, যা অনেক দল নির্ভর করার পর খোলা ব্যয়বহুল।

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

3. আপনার সিস্টেমে ডোমেইন-ড্রিভেন ডিজাইনকে যুক্তিসঙ্গত করার মতো সমৃদ্ধ ডোমেইন এবং যেখানে তা অতিরিক্ত এমন সাদামাটা CRUD অ্যাপের মধ্যে রেখা কোথায়? অধ্যায়টি DDD-র বাউন্ডেড কনটেক্সটের সুপারিশ করে ঠিক কারণ তা দলের মালিকানাকে মডেলের সীমানার সঙ্গে সারিবদ্ধ করে, এবং সতর্ক করে যে সরল তৈরি-পড়া-হালনাগাদ-মোছা সিস্টেমের জন্য DDD অতিরিক্ত এবং প্রকৃত মডেলিং ছাড়া আনুষ্ঠানিকতায় ক্ষয়ে যায়। দুই দিকেই ভুল করা ব্যয়বহুল: পাতলা ডোমেইনে ভারী DDD একটি সরল অ্যাপকে আনুষ্ঠানিকতায় ডুবিয়ে দেয়, আর বহু দল জুড়ে ছড়ানো ভাগ করা মডেল নিরন্তর আন্তঃদল সমন্বয় বাধ্য করে। যে সংকেত সত্যিই এটি ঠিক করে তা আনুন: ব্যবসায়িক নিয়মের ঘনত্ব, এবং কতগুলো দলকে স্বাধীনভাবে অংশগুলোর মালিক হতে হবে। রণনীতিগত যন্ত্রব্যবস্থা জটিল মূলের জন্য রাখুন, এবং সরল প্রান্তগুলোকে সরল থাকতে দিন। এতে আপনি DDD থিয়েটার এবং কাদার বিশাল দলা, উভয় থেকে দূরে থাকেন।

4. কখন একটি বিমূর্তন, ইন্টারফেস বা নকশা প্যাটার্ন তার যোগ করা পরোক্ষতার যোগ্য, এবং একটি নকশাকে অতি-প্রকৌশলী বলার কর্তৃত্ব কার? এই অধ্যায় সুস্পষ্ট যে পরোক্ষতার খরচ আছে যা আপনি প্রতিটি পাঠে দেন, এবং SOLID তুষ্ট করতে বা পরিশীলিত দেখাতে ইন্টারফেস, ফ্যাক্টরি ও স্তর বানানো একটি ব্যর্থতার ধরন। বড় দলে চাপ উল্টো দিকে চলে: পর্যালোচকেরা অতিরিক্ত বিমূর্তন পার করে দেন কারণ তা শৃঙ্খলাবদ্ধ দেখায়, আর কম কাঠামোর পক্ষে যুক্তি দেওয়া মানুষ হতে কেউ চায় না। প্রতিদ্বন্দ্বী বিবেচনা প্রকৃত, কারণ কিছু জোড় সত্যিই নিজের স্থান অর্জন করে এবং পরে সরানো ব্যয়বহুল। আলোচনায় সুনির্দিষ্ট প্রমাণ আনুন: একটি ইন্টারফেসের আজ আসলে কতগুলো বাস্তবায়ন আছে, প্রসারণ বিন্দুটি কখনো কতবার নড়েছে, এবং একটি কোড-পথ অনুসরণ করতে পাঠককে কতগুলো ফাইল খুলতে হয়। একমত হন যে দ্বিতীয়টির আভাস ছাড়া একক বাস্তবায়ন ইনলাইন করার ডিফল্ট কারণ, এবং নাম দিন কে একটি নকশাকে অপমানের মতো না শুনিয়ে অতি-প্রকৌশলী বলতে পারেন। রচয়িতাদের এক দশক ছাড়িয়ে টেকা এন্টারপ্রাইজ ও সরকারি সিস্টেমে অকারণ পরোক্ষতা এমন কর, যা প্রতিটি ভবিষ্যৎ রক্ষণাবেক্ষক দেন, তাই “এই বিমূর্তন আমাদের কী কিনে দিচ্ছে” কে ব্যক্তিগত চ্যালেঞ্জ নয়, স্থায়ী রিভিউ প্রশ্ন ভাবুন।

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

6. এই নীতিগুলোকে মতবাদে শক্ত হওয়া থেকে কীভাবে ঠেকাবেন, এবং একটি নকশা সিদ্ধান্তের পেছনের যুক্তি কোথায় লিখে রাখবেন যাতে ভবিষ্যতের দল তা পুনর্বিবেচনা করতে পারে? এই অধ্যায়ের প্রতিটি নীতির প্রযোজ্যতার ক্ষেত্র ও ব্যর্থতার ধরন আছে, এবং পুরো কাঠামোটি সেগুলোকে প্রয়োগ করার আইন নয়, বিচারবুদ্ধি দিয়ে প্রয়োগ করার হাতিয়ার হিসেবে দেখে। বড় দলে একটি নীতি নিঃশব্দে নিয়ম হয়ে যায়: DRY যেকোনো পুনরাবৃত্তি নিষিদ্ধ করে, SOLID প্রতি ক্লাসে একটি ইন্টারফেস আবশ্যক করে, এবং বাস্তবসম্মত ব্যতিক্রম রিভিউয়ে ফলাফলের বদলে সংক্ষিপ্ত রূপ উদ্ধৃত করা মানুষের দ্বারা আটকে যায়। টানাপোড়েন হলো কিছু সামঞ্জস্য সত্যিই শত শত ইঞ্জিনিয়ারকে সমন্বয় করতে সাহায্য করে, তাই আপনি সহজভাবে প্রতিটি নীতিকে ঐচ্ছিক ঘোষণা করতে পারেন না। এমন উদাহরণ আনুন যেখানে অক্ষরে নীতি অনুসরণ খারাপ নকশা তৈরি করেছে, এবং যদি থাকে সেই সিদ্ধান্তের নথি আনুন যা ব্যাখ্যা করে কেন একটি নির্দিষ্ট সীমানা বা বিমূর্তন আছে। একমত হন যে নীতিগুলো ডিফল্ট, যা থেকে ইঞ্জিনিয়ার লিখিত কারণসহ বিচ্যুত হতে পারেন, এবং পরিণামবহ নকশা পছন্দ একটি সংক্ষিপ্ত স্থাপত্য সিদ্ধান্তের নথিতে ধরুন, যাতে পরবর্তী দল কেবল কোড নয়, যুক্তিও উত্তরাধিকার পায়। এন্টারপ্রাইজ ও সরকারি সিস্টেমে, যেখানে মূল রচয়িতারা অনেক আগে চলে গেছেন এবং অডিট জিজ্ঞেস করে সিস্টেম কেন এই আকারের, সেই লিখিত ট্রেইল হলো ভবিষ্যতের দল নিরাপদে বদলাতে পারে এমন নকশা এবং ছুঁতে ভয় পায় এমন নকশার মধ্যে পার্থক্য।

খাতভেদে দৃষ্টিভঙ্গি

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

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

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

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

উদাহরণ

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

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

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

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

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

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

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• জল্পনামূলক সাধারণত্ব: যে কল্পিত প্রয়োজনীয়তা কখনো আসে না তার জন্য প্রসারণযোগ্যতা গড়া।
• ভুল বিমূর্তন: DRY তুষ্ট করতে অসম্পর্কিত কোড জোর করে একসঙ্গে বাঁধা, পুনরাবৃত্তির চেয়ে খারাপ সংযুক্তি তৈরি করা।
• প্যাটার্নের কার্গো-কাল্ট: নিজের জন্য নকশা প্যাটার্ন প্রয়োগ, সুবিধা ছাড়া পরোক্ষতা যোগ করা।
• রক্তশূন্য বা গড অবজেক্ট: আচরণহীন মডেল, বা সবকিছু করা অবজেক্ট; দুটিই ভুল জায়গায় দায়িত্বের লক্ষণ।
• বিতরিত মনোলিথ: ভৌতভাবে ভাগ করা কিন্তু তবু আঁটসাঁটভাবে যুক্ত সার্ভিস, দুই পদ্ধতির খরচ একত্র করে।
• কাদার বিশাল দলা: কোনো দৃশ্যমান কাঠামো নেই; প্রতিটি পরিবর্তন সবকিছু ঝুঁকিতে ফেলে।
• DDD থিয়েটার: যে ডোমেইন মডেলিং একে মূল্য দেয় তা ছাড়া শব্দভাণ্ডার ও ফোল্ডার কাঠামো গ্রহণ।

পরিপক্বতা মডেল

• স্তর ১, সূচনা: নকশা তাৎক্ষণিক ও প্রতিক্রিয়াশীল; সংযুক্তি অনিয়ন্ত্রিত জমে; নীতি অজানা বা স্লোগান হিসেবে উদ্ধৃত, এবং বিমূর্তন ব্যক্তিগত অভ্যাসে আসে বা উবে যায়।
• স্তর ২, বিকাশ: দলগুলো নীতি জানে এবং প্রয়োগ করে, কিন্তু অসঙ্গতভাবে এবং প্রায়ই মতবাদী হয়ে; কিছু গোষ্ঠী সুচিন্তিতভাবে সংযুক্তি ও সংসক্তি পরিচালনা করে, অন্যরা করে না, এবং প্রতিষ্ঠান জুড়ে কোনো ভাগ করা শব্দভাণ্ডার নেই।
• স্তর ৩, মানসম্মতকরণ: একটি ভাগ করা নকশা শব্দভাণ্ডার, বিমূর্তন বের করার তিনের নিয়ম, সংযুক্তি ও সংসক্তির বিশ্লেষণ এবং দলের সঙ্গে সারিবদ্ধ বাউন্ডেড কনটেক্সট নথিবদ্ধ ও প্রতিষ্ঠানজোড়া প্রত্যাশিত, ব্যক্তিগত রুচির হাতে না ছেড়ে নকশা পর্যালোচনায় সামঞ্জস্যপূর্ণভাবে প্রযুক্ত।
• স্তর ৪, ব্যবস্থাপনা: নকশার স্বাস্থ্য ভিত্তিরেখার বিপরীতে মাপা হয়: সংযুক্তি ও সহ-পরিবর্তনের তথ্য, পরিবর্তন-ব্যর্থতার হার, এবং তুলনীয় ফিচার বাস্তবায়নের সময় সময়ের সঙ্গে অনুসরণ করা হয়, ফলে বিমূর্তন ও সীমানা প্রমাণের ভিত্তিতে যোগ, রাখা বা সরানো হয়, এবং অতি-প্রকৌশল ও ভুল বিমূর্তন মতামতের বদলে তথ্য দিয়ে ধরা পড়ে।
• স্তর ৫, সমন্বয়: নকশার শৃঙ্খলা প্রতিষ্ঠান জুড়ে সরবরাহ ও ঝুঁকি পরিকল্পনার সঙ্গে একীভূত; নীতি সূক্ষ্মতা ও পরিচিত ব্যর্থতার ধরনসহ প্রযুক্ত; প্যারাডাইম ও সীমানার পছন্দ সুচিন্তিত ও নিরন্তর পুনর্বিবেচিত, এবং ডোমেইন ও প্রমাণ সরলে প্রতিষ্ঠান নিয়মিত বিমূর্তন রিফ্যাক্টর, নতুন পরিসর ও অবসান করে।

আলোচনার ভাবনা

• ভবিষ্যৎ প্রয়োজনীয়তা হাতে পাওয়ার আগে প্রয়োজনীয় জোড় আর জল্পনামূলক সাধারণত্বের পার্থক্য কীভাবে বুঝবেন?
• আপনার দলকে DRY কখন ভুল বিমূর্তনের দিকে নিয়ে গেছে, এবং কীভাবে তা চিনেছিলেন?
• বাউন্ডেড-কনটেক্সটের সীমানা কোথায় পড়া উচিত, এবং তা সাংগঠনিক চার্টের কতটা কাছাকাছি হওয়া উচিত?
• আপনার প্রেক্ষাপটে কোডের আগে কতটা নকশা হওয়া উচিত, এবং সিদ্ধান্ত কীভাবে লিপিবদ্ধ করবেন?
• আপনার সিস্টেমের কোন অংশ আরও ফাংশনাল বা ডেটা-ওরিয়েন্টেড শৈলী থেকে উপকৃত হবে?
• বাস্তবসম্মত ব্যতিক্রম প্রতিরোধ করা মতবাদে নকশা নীতিকে শক্ত হওয়া থেকে কীভাবে ঠেকাবেন?

প্রধান শিক্ষা

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

তথ্যসূত্র ও আরও পড়ার জন্য

• Robert C. Martin, Clean Architecture এবং Agile Software Development, Principles, Patterns, and Practices
• Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
• Vaughn Vernon, Implementing Domain-Driven Design
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software
• Martin Fowler, Refactoring: Improving the Design of Existing Code এবং Patterns of Enterprise Application Architecture
• David L. Parnas, On the Criteria to Be Used in Decomposing Systems into Modules
• Sandi Metz, Practical Object-Oriented Design