2.9 সফটওয়্যার নির্মাণ

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

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

বড় দলে নির্মাণ একক নয়, দলীয় প্রচেষ্টা। শত শত ইঞ্জিনিয়ার একটি ভাগ করা কোডবেসে লেখেন, যা যেকোনো একজনের দলে থাকার সময়কে ছাড়িয়ে টিকবে। তাই মানদণ্ড “আজ আমার মেশিনে কাজ করে কি না” নয়। এটি “পাঁচ বছর পরে একজন অপরিচিত কি এটি নিরাপদে বদলাতে পারবেন”। নির্মাণ ওপরের দিকে প্রয়োজনীয়তার (অধ্যায় 2.8) ও নকশার (অধ্যায় 2.2) সঙ্গে যুক্ত, যা বলে কী গড়বেন ও তার আকার। পাশের দিকে এটি কোডিং মান (অধ্যায় 2.1), টেস্টিং (অধ্যায় 2.4) ও কোড রিভিউয়ের (অধ্যায় 2.5) সঙ্গে যুক্ত, যা আকার দেয় কাজ কীভাবে প্রকাশিত, যাচাই ও পরিদর্শিত হয়। ভালো নির্মাণ সুষ্ঠু নকশাকে রক্ষণাবেক্ষণযোগ্য সম্পদে পরিণত করে। দুর্বল নির্মাণ ভালো নকশাকেও দায়ে পরিণত করে।

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

মূল নীতিসমূহ

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

সুপারিশ

প্রাথমিক শৃঙ্খলা হিসেবে জটিলতা ন্যূনতম করুন

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

পরিবর্তন ও যাচাইয়ের জন্য গড়ুন

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

সুচিন্তিতভাবে পুনর্ব্যবহার ও প্রমিত করুন

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

বিচারবুদ্ধিসহ প্রতিরক্ষামূলক প্রোগ্রামিং চর্চা করুন

বিশ্বাস সীমানায় (বাইরের অনুরোধ, ফাইল ও নেটওয়ার্ক I/O, ব্যবহারকারীর ইনপুট) ইনপুট যাচাই করুন এবং সেই সীমানা পেরোনো যেকোনো ডেটাকে প্রমাণিত না হওয়া পর্যন্ত শত্রুভাবাপন্ন ধরুন। তবে একটি ভালোভাবে-পরীক্ষিত মডিউলের ভেতরে প্রতিটি লাইনকে অপ্রয়োজনীয় পরীক্ষায় ঢেকে দেবেন না, যা যুক্তি লুকায় এবং প্রকৃত ব্যর্থতা দমায়। নিয়ম সরল: সীমানায় রক্ষা করুন, তার ভেতরে বিশ্বাস করুন। একটি সঠিক প্রোগ্রামে কখনো মিথ্যা হওয়া উচিত নয় এমন অপরিবর্তনীয় শর্ত নথিবদ্ধ ও প্রয়োগ করতে অ্যাসারশন ব্যবহার করুন। রানটাইমে বৈধভাবে ঘটতে পারে এমন পরিস্থিতির জন্য এক্সেপশন ও ত্রুটি সামলানো ব্যবহার করুন। দুটি আলাদা রাখুন: অ্যাসারশন প্রোগ্রামারের অনুমান রক্ষা করে, ত্রুটি সামলানো প্রত্যাশিত ব্যর্থতা পরিচালনা করে।

ত্রুটি সুস্পষ্টভাবে সামলান এবং নিরাপদে ব্যর্থ হন

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

নির্মাণের সময়েই গুণমান গেঁথে দিন

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

নির্মাণের টুল বেছে নিন ও প্রমিত করুন

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

উদাহরণ

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

এন্টারপ্রাইজ। একটি বৈশ্বিক পেমেন্ট কোম্পানি শত শত ইঞ্জিনিয়ার জুড়ে একটি ভাগ করা টুলচেইন বলবৎ করে: প্রতিটি কমিটে স্বয়ংক্রিয় ফরম্যাটিং ও লিন্টিং, পাইপলাইনে স্ট্যাটিক বিশ্লেষণ গেট, এবং সার্ভিস সীমানায় সব বাইরের ইনপুট যাচাইয়ের নিয়ম। ডোমেইন যুক্তি “একটি খতিয়ান এন্ট্রি সবসময় ভারসাম্যে থাকে”-র মতো অপরিবর্তনীয় শর্ত প্রয়োগ করতে অ্যাসারশন ব্যবহার করে, আর প্রত্যাখ্যাত কার্ডের মতো রানটাইম পরিস্থিতি সুস্পষ্ট, লগ করা ফলাফল হিসেবে সামলানো হয়। মান অভিন্ন এবং ত্রুটি কখনো নিঃশব্দে গেলা হয় না বলে ইঞ্জিনিয়াররা অপরিচিত সার্ভিস জুড়ে আত্মবিশ্বাসের সঙ্গে সরেন, এবং প্রোডাকশন ঘটনা সরাসরি লগ থেকে নির্ণয় করা যায়।

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

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

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

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

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

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

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

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

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

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

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

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

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

• IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), সফটওয়্যার নির্মাণ জ্ঞান-ক্ষেত্র
• Steve McConnell, Code Complete: A Practical Handbook of Software Construction
• Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
• Andrew Hunt ও David Thomas, The Pragmatic Programmer
• Martin Fowler, Refactoring: Improving the Design of Existing Code
• John Ousterhout, A Philosophy of Software Design