DEV Community: Monirul Islam

Day 6 — API Security — এই ভুলগুলো করলে production-এ কাঁদতে হবে

Monirul Islam — Thu, 10 Sep 2026 18:20:00 +0000

মনে করুন আপনারা ৪ ভাই। সবাই একসাথেই বসবাস করেন। সৌভাগ্যক্রমে আপনাদের বাবার huge পরিমাণে সম্পদ আছে এবং সম্পদের কারণে না চাইতেও অনেক শত্রু হয়ে গেছে। এখন তাদের নজর আপনাদের এই সম্পত্তির ওপরে। তারা আপনাদের ক্ষতি করতে চায়, সম্পত্তি হাতিয়ে নিতে চায়। এখন তারা কিছুই করতে পারে না। কারণ আপনারা সবাই একসাথে থাকেন।

এখন আপনারা ৪ ভাই যদি আলাদা হয়ে যান এবং গ্রামে বিভিন্ন অংশে move করেন তাহলে কী হতে পারে?

এখন আপনাদের যে শত্রুরা আছে তারা খুব easily-তেই আপনাদের ক্ষতি করতে পারবে। বিভিন্নভাবে আপনাদের ওপর হামলা করবে। তাই বলে কি এগুলো রুখে দেয়া যাবে না? অবশ্যই যাবে, যদি আপনি proper way-তে security maintain করেন।

এখন same way-তে একটা application যখন একসাথে থাকে তখন তার security maintain করা একটু easy। কিন্তু যখন আপনি separate করবেন তখন কিন্তু এর security নিয়ে একটা issue থেকেই তৈরি হবে। উপরের গল্পের মতো hacker-রাও এই issue-গুলো খুঁজে বের করে আপনার application-এর damage করবে। তবে proper standard maintain করলে এই hacker attack থেকে application-কে protect করা যাবে।

আজকে মূলত API security নিয়ে কথা বলবো।

Authentication vs Authorization

Authentication সম্পর্কে মোটামুটি সবাই জানি। কোনো application-এ user_id এবং password দিয়ে access নেয়াই হচ্ছে authentication। কিন্তু এই authorization-টা হচ্ছে authentication-এর পরের step।

একটা office-এর ভেতরে কিন্তু অনেক employee থাকে, সবাই কি সবকিছু ইচ্ছা করলেই করতে পারে? তাদের কি সবার authority আছে?
অবশ্যই না। এখন manager যা যা করতে পারবে সেই same কাজ যদি একজন সাধারণ employee করতে পারে তাহলে তো office-এ অরাজকতার সৃষ্টি হবে। Management-এর অবস্থা খারাপ হয়ে যাবে। এই যার যে যে access, ঐগুলো বাদে অন্য কিছুর access ensure করাই হচ্ছে Authorization।

API-এর authorization-এর ক্ষেত্রে authorization URL বা resource-এর access maintain করতে হয়। Suppose user related যে resource-গুলো আছে সেগুলো শুধুমাত্র admin-ই access করতে পারবে, এই access তো একটা সাধারণ user পেতে পারে না। এটা ensure করাই হচ্ছে API-এর authorization।

একটা application-এর উদাহরণ দিলে easily মনে রাখতে পারবেন:

Authentication মানে হচ্ছে আপনি এই application-টা use করতে পারবেন কি না সেটা check করা।
Authorization মানে হচ্ছে আপনি কী কী feature/functionality access করতে পারবেন সেগুলো check করা।

OWASP Top 10: সবচেয়ে বড় ভুলগুলো

OWASP প্রতি বছর top security vulnerabilities publish করে।
এখানে নানা security-এর মধ্যে top 10 security issue-গুলো নিয়ে বিস্তারিত থাকে। সাথে তার solution-ও সেখানে বিদ্যমান থাকে। তাই API security ensure করার জন্য এই OWASP report-টা খুব কাজে আসে। নিচে কয়েকটা common security issue নিয়ে আলোচনা করি:

Broken Authentication

weak password
no token expiry (অনেক ক্ষেত্রে expiry set করলেও তা check করা হয় না।)
plain text password storage (password hash না করেই database-এ store করা)

SQL Injection — URL-এর মাধ্যমে or POST request-এর মধ্যে malicious SQL clause inject করা হয়, যেটা server-side database সেটাকে valid SQL হিসেবে execute করে ফেলে। এটাই হচ্ছে SQL Injection। এভাবে attacker চাইলে data চুরি করতে পারে, authentication bypass করতে পারে, এমনকি পুরো table drop করে দিতে পারে।

Broken Access Control — এটা authorization problem। কোন user-এর কোন access থাকবে সেটা control না করা। একজন admin-ও যা যা করতে পারে আবার একজন simple user-ও same করতে পারে।

Rate Limiting: বোকাদের বোকা বানানো

একটা জিনিস চিন্তা করুন আপনি একটা API-কে access করছেন। এখন আপনার ১ মিনিটে কতবার access করা লাগতে পারে? আপনি তো প্রতি sec-এ access করবেন না। মিনিটে maximum ১৫-২০ বার access করবেন। এর বেশি যদি করেন সেটা unnecessary। কিন্তু আপনি না বুঝেই করছেন এই কারণে server-এর resource নষ্ট হচ্ছে। কিছু user-এর application use করতে problem হচ্ছে। তা এখন আমি যদি বলে দিই যে আপনি ১ মিনিটে maximum ১০ বারের বেশি access করতে পারবেন না, এর বেশি করলে error দেখাবে। So এটাই হচ্ছে rate limiting-এর concept।

আবার একটা বিষয় চিন্তা করেন একটা application login করার ক্ষেত্রে আপনি login করতে password + username type করে কতক্ষণ লাগতে পারে? normally ১ মিনিটে ৩-৪ বারের বেশি কেউ login করার try করতে পারবে না। আর password save থাকলে তো একবারেই হয়ে যাবে।

নিচে rate limiting-এর একটা code দেয়া হলো। এটা NestJS-এর ওপরে দেয়া আছে।

// NestJS + nestjs-throttler
@Throttle({ default: { limit: 5, ttl: 60000 } })
@Post('/login')
login() { ... }

ওপরে দেয়া ২টা example আসলে দুইটা hacking attack।

প্রথমটা হচ্ছে DDoS attack, এই attack-এ bot-এর মাধ্যমে request send করে server-কে busy করা হয়। একটা সময় server resource শেষ হয়ে যায় এবং server down হয়ে যায়। Rate limiting করলে যখন request limit শেষ হবে, request processing হবে না, error দিবে।
দ্বিতীয়টা হচ্ছে brute force attack, এই attack-এ password and username দিয়ে বারবার try করা হয়। যতবার try করা হয় ততবার request server-এ যেতে থাকে। এখন এটা manually করা possible না। Script দিয়ে করা লাগবে। যখন request limit শেষ হবে, request processing হবে না, error দিবে।

এখানে একটা বিষয় মাথায় রাখা জরুরি যে rate limiting-এর সাহায্যে এই দুইটা attack foolproof-ভাবে prevent করা যায় না। তবে attack-এর speed কিছুটা কমানো যায়।

CORS: Browser-এর নিরাপত্তা প্রহরী

মনে করুন আপনার একটা website আছে + একটা backend API-ও আছে। এখন আপনি চাচ্ছেন ঐ website বাদে অন্য কোনো website যেন আমার এই API-তে request দিতে না পারে। মানে শুধু আপনার website-এর জন্য access দিবেন। এটা করা possible। এই কাজটাই করে CORS।

CORS (Cross-Origin Resource Sharing) হলো browser-এর একটা security feature।
এটা শুধুমাত্র browser-এ support করে। কিন্তু এটা কিন্তু frontend-এর problem না। এটাকে backend থেকেই solve করতে হবে।

আসলে browser কীভাবে এটা process করে সেটা বুঝলে problem solve করা যাবে। Browser যখন request send করে, send করার পরে backend থেকে response পাঠায় সেখানে body থাকে, header থাকে। এই header-এর মধ্যেই browser কয়েকটা field search করে। তার মধ্যে উল্লেখযোগ্য হচ্ছে:

Access-Control-Allow-Origin: এখানে উল্লেখ থাকে কোন কোন domain API access করতে পারবে। এখন যে domain থেকে request গেছে তার নাম যদি এই list-এ না থাকে তাহলে CORS error দেখাবে।
Access-Control-Allow-Methods: এখানেও same logic but এখানে method-এর নাম check করে।

তবে একটা বিষয় অনেক সময়, অন্য কারণেও CORS-এর দেখা যেতে পারে। Browser এই header-গুলো না পেলেই সে CORS error দেখায়। বাকি বিষয়গুলো মাথা ব্যথা নেই। একটা personal experience share করি তাহলে বুঝতে পারবেন।

আমি একটা VPS-এ Nginx setup করে, একটা frontend application host করেছি। কিন্তু কোনো POST request গেলেই CORS error শুধু CORS। কিন্তু backend-এ একদম ঠিকঠাক আছে। প্রায় ৩-৪ ঘণ্টা try করার পরে discover করলাম, application থেকে প্রায় ৪০-৫০MB-এর data server-এ যাচ্ছে। কিন্তু Nginx by default-ভাবে data size 10MB set করে রাখছে। যে কারণে Nginx request return করে দিচ্ছে। আর browser header পাচ্ছে না বলে CORS error-ই show করছে। সেটা ঠিক করার পরে সব ঠিক হয়ে গেছে।

অতএব, backend-এ CORS configure করলেও অনেক ক্ষেত্রে CORS-এর error দেখা যেতে পারে। একটু carefully handle করা দরকার।

Browser Preflight Request

Browser থেকে যখন কোনো write request (POST, PUT, PATCH, DELETE) server-এ যায় তখন সেই request send করার আগে একটা request send করা হয়ে থাকে। এই request-টা OPTIONS method-এ send হয়ে থাকে। এই request-টাকে preflight request বলে। এই method-এর মাধ্যমে check করা হয় যে, browser এই request send করার জন্য allowed কি না।
ওপরের মতো যদি এই request-এর response header-এ Access-Control-Allow-Origin না থাকে, তাহলে browser সাথে সাথে CORS error throw করবে এবং actual write (POST, PUT, PATCH, DELETE) request server-এ send-ই হবে না।
কোনো কারণে যদি server preflight-এ 404 response throw করে, তাহলেও same problem show করবে। এই জন্য server-এ এই method-টা handle করা অত্যন্ত জরুরি।

Hashing: Password কখনো plain text রাখবেন না

একটা situation দিই আপনাকে, আপনার server সেই আকারে secure কোনো vulnerability নেই। এখানে আপনি একটা কাজ করেছেন আপনি user-দের password plain text হিসেবে database-এ store করেছেন। এই situation-এ আপনার server তো hack করতে পারবে না। কিন্তু আপনার database server hack হয়ে গেলো। এবং এখানে আপনার application-এর database-এর user table publish হয়ে গেলো। তাহলে ব্যাপার কী দাঁড়ালো?

Hacker user-দের name + password দুইটাই পেয়ে গেলো। তাহলে আপনার backend এত secure করেও লাভ হলো না। এই অবস্থায় আপনার application-এর কী হবে বুঝতেই তো পারছেন।

এই অবস্থায় আপনার করণীয় হচ্ছে, যখন কোনো user-এর data add করা হবে তখন password-কে hashing করতে হবে যাতে কেউ easily বুঝতে না পারে। Same কাজ password update করার ক্ষেত্রেও same কাজটাই করতে হবে।

এই hashing করার জন্য অনেক algorithm আছে। এখানে একটা জিনিস মাথায় আসছে, এখানে যেহেতু option অনেক advantage, disadvantage থাকবে, আপনাকে research করে বের করতে হবে।

Hashing Algorithm

বিগিনার হিসেবে hashing algorithm নিয়ে research করে শেষ করার মতো না। এখানে অনেক research করতে হবে। তবে Basic level-এ basic কিছু algorithms সম্পর্কে research করলে অনেক কিছু জানা যাবে।

Password Hashing

bcrypt: এটা key stretching-এর জন্য তৈরি করা হয়েছে। এটা rainbow table-কে counter করতে পারে।

Argon2: এটা passwords hashing এবং key derivation function-এর জন্য তৈরি করা হয়েছে। এটা memory-hard, time-hard, and tunable-by-parameter।

Scrypt: এটা memory-hard, time-hard, and tunable-by-parameter।

import bcrypt from "bcrypt";

const SALT_ROUNDS = 12; // Cost factor: ব্রুটফোর্স স্লো করার জন্য যথেষ্ট শক্তিশালী

// ১. রেজিস্ট্রেশনের সময় পাসওয়ার্ড হ্যাশ করা
async function hashPassword(plainPassword) {
  return await bcrypt.hash(plainPassword, SALT_ROUNDS);
}

// ২. লগইনের সময় পাসওয়ার্ড ভেরিফাই করা
async function verifyPassword(plainPassword, hashedPasswordFromDB) {
  // কখনোই `hash === plainPassword` দিয়ে চেক করবেন না!
  // `bcrypt.compare()` ইন্টারনালি constant-time comparison ব্যবহার করে Timing Attack প্রতিরোধ করে
  return await bcrypt.compare(plainPassword, hashedPasswordFromDB);
}

Input Validation ও Parameterized Queries 🛡️

SQL Injection বা NoSQL Injection থেকে বাঁচার একমাত্র সমাধান হলো: User-এর কোনো input-কে সরাসরি query string-এ না বসানো।

সর্বদা Parameterized Queries / Prepared Statements বা টাইপ-সেফ ORM (যেমন Prisma, TypeORM, Drizzle) ব্যবহার করুন।
রিকোয়েস্ট বডি ভ্যালিডেশনের জন্য Zod বা class-validator ব্যবহার করুন।

JWT Security Best Practices

স্বল্পমেয়াদী Access Token: access token-এর expiry time ১৫–৩০ minutes থেকে বেশি রাখবেন না। seesion long time রাখতে Refresh Token Rotation ব্যবহার করতে হবে।
টোকেন স্টোরেজ: browser-এর localStorage-এ store করলে XSS অ্যাটাকে এটা চুরি হতে পারে। তাই refresh token সবসময় httpOnly, secure, sameSite কুকিতে সংরক্ষণ করতে হবে।

SSL/TLS: সব traffic encrypted রাখুন

SSL নিয়ে আগেই কথাবার্তা হয়েছে, এখানে কথা বলে লাভ নাই।

বটম লাইন

একটা কথা বলি, আমাকে একজন একটা কথা বলেছিল, যে security নাকি একটা bogus জিনিস। এখানে কোনো কিছুই নাই। আসলে security জিনিসটা কখনো bogus হবে না। Past-এও ছিল না, future-এও হবে না।

API security-এর OWASP Top 10 জানলেই বেশিরভাগ security-গুলো encounter করতে পারবেন। আর নিজের logical thinking + business requirement অনুযায়ী security ensure করেন।

আপনার কাছে security জিনিসটা কীভাবে দেখছেন? নিচে comment-এ জানাবেন।

Day 5 | gRPC and Protocol Buffers - A game changer

Monirul Islam — Thu, 10 Sep 2026 04:20:00 +0000

আপনার tour শেষ হয়ে গেছে এবং আপনি এখন বাড়িতে আছেন। আপনি বিকালে বসে বসে একটা জিনিস ভাবতে লাগলেন যে, অনেক কিছুই তো করলাম, এর মধ্যে এই এই কাজগুলো না করলেও হতো। আমার খরচটা একটু কমে যেত। যেমন ধরুন, flight-এর ticket না কেটে bus-এ করে গেলেই হতো, খরচ কমে যেত। আবার বড় কোনো 5 star hotel-এ না উঠে, ছোটখাটো normal একটা hotel-এ উঠলেই হতো, খরচ অনেক কমে যেত।
এখানে একটা জিনিস বুঝতে পারবেন, খরচ কমানোর চক্কর করতে গেলে সেখানে কিছু problem-এর সম্মুখীন হতে হবে। যেমন ধরুন, আপনার মালামাল management করা নিয়ে problem face করতে হতে পারে। এছাড়া আরও অনেক problem-এর সম্মুখীন হতে হবে।

কিছু কি relate করতে পারছেন? একটু কষ্ট হচ্ছে। আসুন অন্য একটা বিষয় নিয়ে কথা বলি।

আপনি যখন backend নিয়ে কাজ করছেন তখন microservice নিয়ে আপনার মোটামুটি idea হয়ে যাওয়ার কথা। সহজভাবে বললে একটা single application-কে ছোট ছোট part-এ ভেঙে আলাদাভাবে management করাই হচ্ছে microservice। এটা নিয়ে future-এ একটা dedicated article আসবে। তখন আরও ভালোভাবে জানতে পারবেন।
এখন একটা বিষয় বুঝেন, আপনি যখন কোনো application develop করবেন তখন কিন্তু আপনার অন্য module-এর সাথে communication করার প্রয়োজন হবে। Monolith application-এর ক্ষেত্রে সব এক জায়গায় থাকে সেই জন্য কোনো problem হয় না। কিন্তু যখন microservice-এ যেয়ে communication করা হয় তখন REST API use করার প্রয়োজন পড়ে। কিন্তু problem হচ্ছে, REST API-এর ক্ষেত্রে text based json format serialize, deserialize করার জন্য extra time + bandwidth নষ্ট হয়। text based json serialize, deserialize করা হয় ডাটাকে human readable format-এ নিয়ে use করার জন্য।

Microservice-এ internal communication সবই তো server বা machine। সেক্ষেত্রে এই text based json serialize, deserialize করার কোনো প্রয়োজন নেই। এই overhead-টা কমাতে পারলেই আপনার internal communication-এর speed অনেক বেড়ে যাবে।
একটা জিনিস চিন্তা করুন আপনার একটা data-এর জন্য user-কে যদি ২ sec wait করা লাগে, তাহলে user কি আপনার application use করবে? আপনি কি use করবেন? ক্ষেত্রবিশেষে load বেশি হলে এই waiting-এর time আরও বেশি হতে পারে।

এটার solution হচ্ছে gRPC।

What is gRPC?

gRPC-তে যাওয়ার আগে, RPC সম্পর্কে বিস্তারিত জানাটা প্রয়োজন।
RPC-এর full form হচ্ছে Remote Procedure Call। এটার concept হচ্ছে একদম simple। Server-এ কয়েকটা specific function থাকে। এই function-গুলো client directly call করে কাজ করবে। এটাই হচ্ছে Remote Procedure Call।

এই concept-এর ওপর base করেই Google একটা RPC model develop করে। At first, gRPC Google তাদের internal project-এর জন্য use করে। Then ২০১৫ সালে open source করে দেয়। তবে concept-টা RPC-এর তবে অনেক efficient।

gRPC-এর communication-এর জন্য Protocol Buffer (Protobuf, developed by Google themselves) use করে। যেটা অনেক efficient কারণ এখানে binary data communication হয়।

RPC-এর ক্ষেত্রে একটা problem হচ্ছে এটা language specific। এছাড়াও এখানে method name mismatching-এর একটা প্রবল সম্ভাবনা থাকে। এই জন্য এটা একটু risky। কিন্তু gRPC language agnostic। gRPC-তে .proto file use করা হয়, যেটা মূলত একটা contract হিসেবে কাজ করে। এই contract থাকার কারণে আমি চাইলেই method mismatch হবে না। Compile time-এই error show করবে। এই ক্ষেত্রে runtime-এ অনেক error থেকে save করবে।

Protocol Buffers: Magic of binary data

Protocol Buffers হলো একটা data serializer। অন্যান্য data serializer (JSON, XML) text based formatting করে, কিন্তু protocol buffer binary format use করে data format করে। এর জন্য data size অনেক কম, speed অনেক high। তবে এর একটা downside হচ্ছে, এটা human readable না। Read করতে হলে কিছু tool use করতে হবে। যদিও এটাকে downside বলাটা ঠিক হবে না।
এখন একটা বিষয় চিন্তা করুন, আপনি যখন machine to machine communication করবেন তখন এই human readable serialization-এর দরকার আছে? অবশ্যই না।

gRPC-তে .proto file use করা হয়। নিচের একটা example দেখলে কিছুটা idea করতে পারবেন।

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

service UserService {
  rpc GetUser(UserRequest) returns (User);
}

এখন আপনার মাথায় একটা জিনিস আসবে, একটু আগে বললাম যে gRPC language agnostic। তাহলে নানা ধরনের language কীভাবে use হয়?

আসলে language-এ use করার জন্য, gRPC-তে by default code generator আছে, এই generator দিয়ে easily যেকোনো language-এর জন্য code generate করে use করা যায়।

এই Protocol Buffer একটু খেয়াল করলে দেখতে পারবেন যে ২ ধরনের code আছে। একটাতে schema আর আরেকটা অনেকটা class-এর মতো। মূলত এই schema-টা হচ্ছে data format বা type। আর service যে section-টা সেটার ভেতরে যেগুলো আছে ঐগুলো সবগুলাই method।

এই .proto file use করার কারণে, আপনার system-এ end-to-end type security ensure হচ্ছে। একবার schema লিখবেন সব language-এই কাজ করবে।

HTTP/2: The Underlying Technology

gRPC behind the scene-এ HTTP/2 protocol use করে। এটা HTTP/1.1-এর modern version যেটা ২০১৫ সালে standardize হয়। এই HTTP/2 use করার কারণেই মূলত gRPC তুলনামূলক অনেক fast। HTTP/2-এর কিছু feature সম্পর্কে জানলেই এটা বুঝে যাবেন।

HTTP/2-এর কিছু ফিচার:

Bidirectional streaming - client আর server দুইজনই একসাথে data পাঠাতে পারে।
Multiplexing - একটা connection-এই অনেক call।
Header compression - repeated headers compress হয়।

REST vs gRPC

এতক্ষণে কিছুটা idea পেয়ে গেছেন কখন gRPC আর কখন REST use করতে হবে।

gRPC use করুন যখন -

Internal microservice-to-microservice communication
High performance, low latency দরকার
Streaming data দরকার (real-time)
Strong contract/schema enforce করতে চান

REST use করুন যখন -

Public-facing API
Browser directly consume করবে
Simple integration, documentation সহজ রাখতে চান

gRPC browser থেকে directly call করা যায় না সহজে - gRPC-Web proxy লাগে। তাই public API-তে gRPC একটু ঝামেলার।

কিন্তু backend-to-backend? এখানে REST-এর সাথে gRPC-র কোনো তুলনাই হয় না।

বটম লাইন

আগের article-এ একটা কথা বলেছিলাম যে, option future-এ অনেক আসবে কিন্তু আমার যেটা দরকার, যেটা আমার requirement full করে সেটা choose করতে হবে। তাহলে একটা ভালো application বানানো possible।

এখানে আমি শুধুমাত্র gRPC সম্পর্কে একটু idea দিলাম। আপনি চাইলে নিচের document থেকে বিস্তারিত পড়তে পারেন।

Day 04 — GraphQL vs REST — কোনটা কখন? সত্যিকারের trade-off

Monirul Islam — Wed, 09 Sep 2026 04:20:00 +0000

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

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

এর পরে আপনি আরামে ট্যুরে চলে গেলেন। আপনার উদ্দেশ্য হাসিল হলো। সব কিছু একদম পারফেক্ট।

এখন আপনি বলবেন এখানে ট্যুরের সাথে টেকনোলজির সম্পর্ক কী? সম্পর্ক আছে। এখানে আপনি একটা জিনিস রিয়ালাইজ করতে পারবেন যে, ফ্লেক্সিবিলিটি যত বেশি, সেখানে প্রবলেম তত বেশি। এই প্রবলেম সলভ করতে হলে নলেজ এবং ফোকাস দুইটা জিনিসই দরকার।

REST এবং GraphQL, দুইটার ফান্ডামেন্টাল কাজ হচ্ছে সার্ভারের সাথে কমিউনিকেট করে ডাটা ট্রান্সফার করা। এখন আপনার সিদ্ধান্ত নেওয়া কিন্তু একটু প্রবলেমেটিক, কারণ দুইটাই প্রায় একই কাজের জন্য।

এই প্রবলেমকে সলভ করতে হলে আগে যে স্ট্র্যাটেজি ফলো করে একটা প্লেস সিলেক্ট হয়েছে, একই উপায়ে সলভ করতে হবে। আগে আপনার রিকোয়ারমেন্ট সম্পর্কে স্পষ্ট ধারণা নিতে হবে—আপনার অ্যাপ্লিকেশনের আসলে কী দরকার। এর পরে REST ও GraphQL সম্পর্কে নলেজ গ্যাদার করতে হবে, তাদের ইউজার কেস সম্পর্কে জানতে হবে। সবশেষে আপনার অ্যাপ্লিকেশন রিকোয়ারমেন্টের সাথে যার ইউজার কেস মিলে যাবে, সেটাই বেছে নিতে হবে।

REST-এর সমস্যাটা কোথায়?

একটা জিনিস চিন্তা করুন—একটা প্রবলেম সলভ করার জন্য যখন একাধিক অপশন থাকে, তখন স্বাভাবিকভাবেই বোঝা যায় যে অপশনগুলোর কিছু না কিছু ডিসঅ্যাডভান্টেজ থাকেই। এগুলো জানলেই আপনার অপশন চুজ করতে সুবিধা হবে।

REST সম্পর্কে তো আগেই জেনে গেছেন (আগের আর্টিকেল থেকে)। ওখানে REST-এর ডিসঅ্যাডভান্টেজ নিয়ে তেমন কোনো আলোচনা হয়নি।

মনে করুন আপনার একটা মোবাইল অ্যাপ আছে, ওই অ্যাপের প্রোফাইল পেজে নিচের এই জিনিসগুলো দেখাতে হবে:

ইউজারের নাম, ফটো
লেটেস্ট ৩টা পোস্ট
ফলোয়ার কাউন্ট

এখন এটা সলভ করতে হলে কতগুলো API Call লাগবে?

GET /users/5           → ইউজারের নাম, ফটো
GET /users/5/posts     → সব পোস্ট ফেচ করে, লজিক দিয়ে ফিল্টার করতে হবে।
GET /users/5/followers → ফলোয়ার কাউন্ট

৩টা API Call করা লাগবে। এখানে API Call সংখ্যার চেয়ে আরও একটা জিনিস ম্যাটার করছে।

এখানে কয়েকটি জিনিস খেয়াল করুন:

ইউজারের জন্য লাগবে শুধু নাম আর ইমেজ, কিন্তু ফেচ করতে হচ্ছে ইউজারের সব কিছু।
পোস্ট লাগবে মাত্র ৩টি, কিন্তু ফেচ হচ্ছে অনেকগুলো পোস্টের ডাটা।
ফলোয়ার কাউন্টের জন্য লাগবে জাস্ট একটা নম্বর, কিন্তু পুরো লিস্ট ফেচ করতে হচ্ছে।

এখানে অনেক অপ্রয়োজনীয় ডাটা ফেচ হচ্ছে, এই ডাটাগুলোর জন্য ব্যান্ডউইথ নষ্ট হচ্ছে, সাথে রেসপন্স সাইজ বড় হওয়ার জন্য API Call Latency-ও বেড়ে যাচ্ছে।

এই সমস্যার নামই হলো Over-fetching আর Under-fetching।

GraphQL কীভাবে এটা সলভ করে?

এই প্রবলেমটা সলভ করে GraphQL। কীভাবে সলভ করে? তাহলে GraphQL কীভাবে কাজ করে সেটা জানতে হবে।

মূলত GraphQL-এ একটি মাত্র Endpoint থাকে (/graphql), এই এন্ডপয়েন্টের মধ্যে Query পাস করতে হয়। GraphQL হলো একটি Schema-driven প্রযুক্তি। সার্ভার আগে একটি স্ট্রং টাইপ কন্ট্রাক্ট ডিফাইন করে যাকে Schema (SDL - Schema Definition Language) বলা হয়:

# ১. Server Schema (কন্ট্রাক্ট)
type Post {
  id: ID!
  title: String!
  date: String!
}

type User {
  id: ID!
  name: String!
  avatar: String!
  posts(limit: Int = 5): [Post!]!
  followerCount: Int!
}

type Query {
  user(id: ID!): User
}

আর ক্লায়েন্ট তার দরকার অনুযায়ী ঠিক যতটুকু ডেটা প্রয়োজন ততটুকুই ব্যাকএন্ড থেকে চেয়ে নেয়:

# ২. Client Query (অনুরোধ)
query {
  user(id: 5) {
    name
    avatar
    posts(limit: 3) {
      title
      date
    }
    followerCount
  }
}

এই একটা কলেই পুরো প্রয়োজনীয় ডাটা সার্ভার থেকে নির্দিষ্ট ফরম্যাটে চলে আসবে। কোনো ওভার-ফেচিং বা আন্ডার-ফেচিং থাকবে না।

GraphQL-এর মূল তিনটি অপারেশন ⚙️

REST-এ যেমন GET, POST, PUT, DELETE-এর মতো HTTP মেথড থাকে, GraphQL-এ তিনটি প্রধান রুট অপারেশন রয়েছে:

Query (Read): ডেটা রিড করার জন্য (REST-এর GET-এর অনুরূপ)।
Mutation (Write): ডেটা তৈরি, আপডেট বা ডিলিট করার জন্য (REST-এর POST, PUT, DELETE-এর মতো)।

mutation CreateNewPost {
  createPost(title: "GraphQL Mastery", content: "Backend deep dive") {
    id
    title
    createdAt
  }
}

Subscription (Real-time): সার্ভারে কোনো ইভেন্ট ঘটলে ক্লায়েন্টের কাছে লাইভ ডেটা পুশ করার জন্য। এটি ব্যাকগ্রাউন্ডে WebSockets ব্যবহার করে পারসিস্টেন্ট কানেকশন বজায় রাখে।

subscription OnNewComment($postId: ID!) {
  commentAdded(postId: $postId) {
    id
    author
    content
  }
}

Schema Introspection ও অটোমেটিক ডকুমেন্টেশন 🔍

GraphQL-এর দারুণ একটি সুবিধা হলো Introspection (__schema)। ক্লায়েন্ট বা ডেভেলপার সরাসরি সার্ভারকে কোড দিয়ে জিজ্ঞাসা করতে পারে: "তোমার কাছে কী কী টাইপ, কী কী কুয়েরি আর আর্গুমেন্ট আছে?"

এর ফলে:

GraphiQL / Apollo Studio: সার্ভার রান করলেই অটোমেটিক ইন্টারঅ্যাকটিভ API ডকুমেন্টেশন আর টেস্ট কনসোল তৈরি হয়ে যায়। কোনো ম্যানুয়াল Swagger ফাইল লিখতে হয় না।
Code Generation: ফ্রন্টএন্ডে GraphQL Code Generator ব্যবহার করে ব্যাকএন্ড স্কিমা থেকে হুবহু TypeScript Types এবং SDK স্বয়ংক্রিয়ভাবে তৈরি করে নেওয়া যায়।

তাহলে সব জায়গায় GraphQL ব্যবহার করব না কেন?

সবকিছুরই ট্রেড-অফ থাকে। GraphQL বেশ কিছু জায়গায় অতিরিক্ত জটিলতা তৈরি করে:

১. N+1 Problem

GraphQL-এ প্রতিটি ফিল্ডের জন্য আলাদা Resolver ফাংশন এক্সিকিউট হয়। যদি আপনি ৫০ জন ইউজারের লিস্ট চান এবং প্রতি ইউজারের সাথে তাদের posts চান, তাহলে ১টি কুয়েরি দিয়ে ইউজার ফেচ হবে এবং প্রতি ইউজারের পোস্টের জন্য ডাটাবেসে আলাদা আলাদা আরও ৫০টি কুয়েরি এক্সিকিউট হবে (১ + ৫০ = ৫১টি কুয়েরি!)।

এখানে উদ্ধারকর্তা হিসেবে কাজ করে Facebook-এর তৈরি DataLoader:

Batching: ইভেন্ট লুপের এক ফ্রেমে আসা সব রিকোয়েস্টকে জমা করে একটিমাত্র SELECT * FROM posts WHERE userId IN (...) কুয়েরি চালায়।
Caching: একই রিকোয়েস্টে একই ইউজারের ডেটা একাধিকবার প্রয়োজন হলে তা ডাটাবেস থেকে না টেনে মেমোরি থেকে দিয়ে দেয়। (Day 11-এ আমরা কোডসহ N+1 ও DataLoader-এর গভীর ব্যবচ্ছেদ দেখব)।

২. Caching জটিলতা

REST-এ URL ধরে ব্রাউজার ও CDN লেভেলে খুব সহজে HTTP ক্যাশিং করা যায়। কিন্তু GraphQL-এ সব রিকোয়েস্ট একই /graphql এন্ডপয়েন্টে POST মেথডে পাঠানো হয়। ফলে প্রথাগত HTTP ক্যাশিং সরাসরি কাজ করে না। এখানে জটিল Normalized Client Cache (যেমন Apollo Client InMemoryCache) বা Persisted Queries ব্যবহার করতে হয়।

৩. Query Complexity ও Security রিস্ক

GraphQL ক্লায়েন্টকে নিজের মতো করে কুয়েরি সাজানোর পূর্ণ স্বাধীনতা দেয়। কোনো ক্ষতিকর ইউজার বা হ্যাকার চাইলে এমন একটি রিকার্সিভ নেস্টেড কুয়েরি পাঠাতে পারে:

query MaliciousQuery {
  user {
    friends {
      friends {
        friends {
          friends { name }
        }
      }
    }
  }
}

এই কুয়েরি সার্ভার এবং ডাটাবেসের সিপিইউ ১০০% দখল করে পুরো অ্যাপ্লিকেশন ক্র্যাশ করিয়ে দিতে পারে (DDoS Attack)।

তাই প্রোডাকশন GraphQL সার্ভারে সবসময় Query Depth Limiting এবং Query Cost Analysis কনফিগার করে রাখতে হয়, যাতে নির্দিষ্ট লিমিটের বেশি জটিল কুয়েরি সার্ভার সরাসরি রিজেক্ট করে দেয়।

কখন কোনটা?

REST ব্যবহার করুন যখন —

Simple CRUD operations
Public API যেটা বাইরে বিভিন্ন থার্ড-পার্টি ডেভেলপাররা consume করবে
Caching critical (CDN লেভেলে স্ট্যাটিক ক্যাশিং দরকার)
টিম GraphQL-এর জটিলতায় ঢুকতে চায় না

GraphQL ব্যবহার করুন যখন —

Complex, deeply nested ডাটা রিলেশনশিপ দরকার
Multiple clients (web, mobile, smart watch) আলাদা আলাদা ডাটা সাইজ ও ফরম্যাট চায়
Rapid UI iteration দরকার—ফ্রন্টএন্ডের সামান্য পরিবর্তনের জন্য ব্যাকএন্ডে বারবার নতুন এন্ডপয়েন্ট বানানোর ঝামেলা এড়াতে চান

বটম লাইন

ভবিষ্যতে একটা প্রবলেম রিসলভ করার জন্য অনেক অপশন আসতে পারে। কিন্তু সিলভার বুলেট বলে কিছু নেই। রিকোয়ারমেন্ট অনুযায়ী বেস্ট অপশনটাই বেছে নিতে হবে।

আপনার Current Project-এ কোনটা ব্যবহার করছেন? কমেন্টে জানান! 👇

Day 3 — REST API Design — যেভাবে করলে কেউ কিছু বলতে পারবে না

Monirul Islam — Tue, 08 Sep 2026 04:20:00 +0000

আগে যখন কোনো web project develop করা হতো তখন typically server total content generate করে frontend-এ send করে দিত, then frontend এটা render করে display করতো। এখন একটা বিষয় চিন্তা করে দেখুন, একটা full page যদি প্রতিবার server থেকে load হয়, তাহলে network latency + bandwidth খরচ কিন্তু বেশি হবে। মোটামুটি সব user-ই কিন্তু almost similar জিনিস বারবার server থেকে load করবে। এখানে এই content-এর ভেতরে শুধুমাত্র user specific information-গুলোই change হবে, বাকিগুলো similar। তখন ইঞ্জিনিয়াররা ভাবলো, আমরা যদি এই fixed data-গুলো frontend-এই রেখে, শুধু user specific data-গুলোই server থেকে fetch করে ঐ যেখানে যেখানে লাগবে সেখানে বসিয়ে দিই তাহলে কেমন হবে? এতে করে cost reduce হয়ে যাবে + network latency-ও কমে যাবে।

এভাবেই মূলত API-এর শুরু হয়। API-এর মূল purpose হচ্ছে client-server communication হবে only necessary data-এর মাধ্যমে। No unnecessary data।

REST API কী?

Suppose, আপনি একটা ৫ তলা ঘর বানাচ্ছেন। এখন আপনি কি যেমন তেমনভাবে বানাবেন?
অবশ্যই না। আপনি একজন engineer নিয়ে এসে একটা design করে নেবেন। আপনাকে proper একটা architecture দিয়ে দেবে এবং সেই architecture-এ আপনি বাড়িটা বানাবেন।

Similar way-তে REST হলো API বানানোর একটা architecture style। REST-এর full form হচ্ছে Representational State Transfer। আর মজার ব্যাপার হচ্ছে আপনি চাইলে যেকোনো architecture fully follow-ও করতে পারেন আবার partially-ও use করতে পারেন। এর জন্য এই REST-কে rules বলার থেকে guidelines বলাটাই better।

REST-এর মূল concept হচ্ছে, সবকিছু resource। আর এই resource-এর উপরে HTTP method দিয়ে request করলেই হয়ে যাবে। এইটুকু করলেই হয়ে যাবে। HTTP নিয়ে তো already জানেন।

REST API কেন ডিজাইন করাটা জরুরি?

এটা একদম easy। তাহলে এটা নিয়ে এত ভাবার কী আছে? একটা জিনিস মাথায় রাখবেন, যে জিনিস যত flexible সেখানে problem-এর সংখ্যা তত বেশি। Initially আপনি simple way-তে API develop করবেন তখন কোনো problem হবে না। কিন্তু যখন একটু grow করবেন তখন যে কী ধরনের problem হবে আপনি experience না করলে বুঝতে পারবেন না।

আমার একটা real life experience share করি তাহলে বুঝতে পারবেন।

আমি যখন আমার development journey শুরু করি, তখন present time-এর মতো API development বা API-এর demand ছিল না। Just server থেকে সবকিছু ready হয়ে আসবে, সবকিছুই আরামসে চলে যাবে। এত বেশি প্যারা নেওয়ার দরকার নেই।
আস্তে আস্তে আমি API development-এর দিকে move করি। এই journey-এর শুরু হয় tutorial follow করে করে, সাথে practice করতাম। এভাবেই আস্তে আস্তে used to হয়ে যাই। একটা সময় যেয়ে tutorial দেখার থেকে documentation পড়া শুরু করি।

অনেকগুলো project করার পরে একটা সময় যেয়ে আমি একটা decision নিই যে, আমি একটা বড় project বানাবো যেটা real life work-টা reduce করবে and believe me, সেই project এই নিয়ে ৪ বার try করেও সেটা complete করতে পারিনি। এর অনেকগুলো reason ছিল, তার মধ্যে API properly design না করা একটা।

এখন বর্তমান সময়ে আমি ঐ project open করলে আমি নিজেই সেই project বুঝতে পারি না। এখন একটা বিষয় চিন্তা করেন আমার নিজের লেখা code & style, নিজেই বুঝতে পারছি না। এটা যদি অন্য কেউ দেখে তার কী অবস্থা হবে? আপনার team feature development করার বদলে project style বুঝতে বুঝতেই অনেক সময় চলে যাবে। এই জন্য API properly design করাটা জরুরি।

Resource Naming: নাম রাখার নিয়ম

আগের article-এ আপনি HTTP method নিয়ে already জেনে গেছেন। এই method থেকে আপনি বুঝে যাবেন যে আসলে এটা server থেকে data fetch করা হচ্ছে নাকি server-এ send করা হচ্ছে। এই ক্ষেত্রে আপনার resource-এর নামের সাথে get বা post লেখার প্রয়োজন হবে না। Method is explaining everything।

Resource naming-এর ক্ষেত্রে noun use করা হয়। আর verb word (create, get, update, delete) গুলো avoid করা হয়। কারণ HTTP method-গুলো এগুলো explain করে দেয়। নিচে একটা example দেয়া হলো, এটা দেখলে বুঝতে পারবেন।

❌ খারাপ:

POST /createUser
GET /getUsers
DELETE /deleteUser/5

✅ ভালো:

POST /users           # create new user
GET /users            # get all users
DELETE /users/5       # delete user with id 5

Resource naming-এর ক্ষেত্রে plural use করা হয়। এটা একটা convention।

Nested Resources: কতটা গভীরে যাবেন?

URL path + resource naming আরও convenient করতে nesting resource use করা হয়। নিচের example-এর মতো:

GET /users/5/posts/3/comments

কিন্তু কথা হচ্ছে এই nesting করলে তো URL অনেক বড় হয়ে যাবে এবং URL-এ unwanted data-এর প্রয়োজন হবে। For example: যখন আমার সবার জন্য post-গুলো দরকার হবে তখন কিন্তু users define করার কোনো প্রয়োজনীয়তা নেই। আবার same rules যায় single and specific resource-এর ক্ষেত্রে। একটা post-এর ID সম্পূর্ণ posts table-এ generally unique হয়। তাহলে post-এর ID দিয়ে direct access না করে এত nesting করে access করা make sense করে না।

এখন বলতে পারেন, এর জন্য কি nesting use করবো না? অবশ্যই use করবেন তবে maximum ২ level। নিচের example দেখলে বুঝতে পারবেন:

GET /users/5/posts       ✅
GET /posts/3/comments    ✅
GET /users/5/posts/3/comments/7/replies  ❌

এটা একটা convention, আপনার যদি মনে হয় আপনি nesting level আরও increase করবেন, it's all up to you।

Versioning: ভবিষ্যতের জন্য দরজা খোলা রাখা

মনে করুন আপনি একটা application বানিয়েছেন, যেটা সময়ের সাথে সাথে অনেক grow করেছে। একটা সময় যেয়ে আপনার API architecture + request + response + logic এগুলো change করা দরকার। আর আপনার application এত বড় হয়েছে যে আপনি existing API change করতে পারবেন না। এটা কিন্তু একটা problem।
এই problem-টা solve করার solution হলো versioning। Versioning করার মাধ্যমে এই problem-টা solve করা যায় easily।

API-কে ৩ way-তে versioning করা যায়:

using headers: এই way-তে request header-এর ভেতরে version define করে দিতে হয়। এর মাধ্যমে server versioning-টা manage করে। এর benefit হচ্ছে আপনার URL same থাকে but function + internal logic change হয়ে যায়।
url path: এটায় URL path-এর ভেতরে version define করতে হয়।
url query parameter: এটায় URL-এ query parameter হিসেবে version-টা define করে দিতে হয়। এটা অনেকটা header versioning-এর মতো।

url versioning:

/api/v1/users
/api/v2/users

Query versioning:

/users?version=1
/users?version=2

তবে practically URL versioning-টাই সবচেয়ে বেশি use হয়। কারণ এখানে complexity অনেক কম। তবে বিষয়টা এমন না যে সবাই use করছে বলে আপনাকেও use করতে হবে।

Idempotency: এই concept টা না জানলে খবর আছে!

মনে করুন, আপনার একটা ছোট ভাই জিজ্ঞাসা করছে, বাংলাদেশের রাজধানী (capital) কোথায়? আপনি normally বললেন ঢাকা। কিছুক্ষণ পরে এসে আবার same question করেছে। আপনিও same answer দিলেন। এভাবে next ১০ মিনিটে ১০-১২ বার জিজ্ঞাসা করা হয়ে গেছে। এবার আপনি আপনার মেজাজ হারিয়ে ফেললেন এবং রেগে রেগে বললেন যে রাজধানী জিনিসটা কোনো ছেলেখেলা না যে এত তাড়াতাড়ি change হয়ে যাবে।
তো এই change না হওয়ার concept-টাই হচ্ছে Idempotency। API-এর ক্ষেত্রে আপনি একটা specific resource access করছেন। এখন ঐ resource-টা idempotent হতে হলে সবসময় ঐ same response provide করতে হবে। সেটা ১০০ বার হোক বা ২০০ বার। [তবে এর ভেতরে data update করলে বিষয়টা আলাদা জিনিস]। Concept-টা hopefully clear হয়ে গেছে।

এখন চলুন HTTP method-এর idempotency নিয়ে কিছু আলোচনা করি:

POST: স্বাভাবিক কারণেই POST method idempotent করা possible না কারণ per request-এ এটা নতুন data return করবে। তবে এটাকেও idempotent করা সম্ভব। modern system-এ request এর header এ key provide করা হয়। সেই key থেকে server বুঝতে পারে যে এটা duplicate ডাটা কিনা।
GET - এটা idempotent হতেই হবে। না হলে duplicate data নিয়ে অনেক প্যারা খেতে পারেন।
PUT/PATCH - এখানে একটু confusing লাগতে পারে। এখানে ensure করতে হবে যেই resource-টা update করছি, always যেন সেই resource-টাই update হয়। তাহলে এটাকে idempotent বলা যাবে।
DELETE - এখানে concept-টা PUT method-এর মতো। তবে same ID দিয়ে first request-এ actual data delete হবে কিন্তু বাকি সব ক্ষেত্রে তা Not Found বা Already Gone show করবে।

এই idempotency-এর concept-টা API + আপনার application-কে অনেকটা stable এবং predictable করবে। এটা না জেনে যদি আপনি API develop করেন তবে অনেক unexpected problem face করতে পারেন।

Pagination Strategies

আপনার কাছে মিলিয়ন মিলিয়ন ডাটা আছে। এই ডাটাকে একবারে ফেচ করলে লেটেন্সি অনেক বেড়ে যাবে। আর ইউজারের পক্ষে এত ডাটা একবারে রিড করা সম্ভব না। তাই ইউজার এক্সপেরিয়েন্স প্রপারলি মেইনটেইন করার জন্য চাঙ্ক চাঙ্ক (টুকরো টুকরো) করে ডাটা রেসপন্স করাটা বেটার। এই চাঙ্ক চাঙ্ক আকারে ডাটা রেসপন্স করার সিস্টেমকেই বলে Pagination।

বিষয়টা এমন হবে যে—ইউজার বলবে আমাকে ১০টা করে আইটেম (limit) দাও এবং ১ম (page) ১০টা আইটেম দাও। তখন সার্ভার "১ম ১০টি" আইটেম প্রোভাইড করবে। এটা একটা সিম্পল স্ট্র্যাটেজি। সার্ভার এখানে সব ডাটাকে limit দিয়ে ভাগ করবে, তারপর যে পেজের ডাটা ইউজার চাইবে সেই পেজের ডাটা ইউজারকে প্রোভাইড করবে।

Pagination-এর জন্য বেশ কিছু স্ট্র্যাটেজি আছে।

Offset

এই স্ট্র্যাটেজি একদম সিম্পল—ইউজারের কাছ থেকে limit এবং offset (কয়টা আইটেম বাদ দিতে হবে) ইনপুট নেওয়া হয়। তারপর রেসপন্স করা হয়ে থাকে।

Example:

/api/v1/users?limit=10&offset=20

এই স্ট্র্যাটেজি সিম্পল কিন্তু বিশাল ডেটাসেটের ক্ষেত্রে বটলনেক তৈরি করতে পারে। এখানে যে offset আছে, এই offset কিন্তু ডাটাবেসে কুয়েরি করার সময় রিড হয়। এখন যদি ডাটাবেসে ১ মিলিয়ন ডাটা থাকে এবং offset-এর ভ্যালু হাফ মিলিয়নে চলে যায়, তখন কিন্তু এই হাফ মিলিয়ন ডাটাই রিড করতে হবে।
এখন আপনার পেজিনেশনের যে উদ্দেশ্য, সেটা কিন্তু অ্যাচিভ হচ্ছে না। ইনিশিয়ালি এটা ভালো মনে হলেও ডেটাসেট বিশাল হলে প্রবলেম শুরু হয়ে যায়।

Cursor

এই স্ট্র্যাটেজিতে একটা cursor (unique id, timestamp ইত্যাদি) ব্যবহার করা হয়। লাস্ট যে ডাটার cursor ভ্যালু হিসেবে প্রোভাইড করা হবে, তারপর থেকে ডাটা ফেচ করা হয়।

/api/v1/users?limit=10&cursor=123e4567-e89b-12d3-a456-426614174000

এই স্ট্র্যাটেজি অফসেটের সমস্যা সমাধান করে। কিন্তু এই স্ট্র্যাটেজি ইমপ্লিমেন্ট করা অফসেটের চেয়ে অনেকটাই কমপ্লেক্স। এ ছাড়াও এই স্ট্র্যাটেজিতে ডুপ্লিকেট ডাটা রিটার্ন হওয়ার পসিবিলিটি থাকে। এই স্ট্র্যাটেজিতে কেয়ারফুলি হ্যান্ডেল না করলে এই ইস্যু ফেস করতে হতে পারে।

Cursor Based Pagination বিশাল ডেটাসেটের জন্য বেস্ট চয়েস। আর ইন্ডাস্ট্রিতে এই স্ট্র্যাটেজি সবচেয়ে বেশি ব্যবহার হয়।

Time-Based Pagination

এই স্ট্র্যাটেজিতে limit-এর পরিবর্তে একটা timestamp-এর রেঞ্জ প্রোভাইড করা হয়ে থাকে।

Example:

/api/v1/users?limit=10&from_time=1234567890&to_time=1234567890

এই স্ট্র্যাটেজি সব ধরনের ডেটাসেটের সাথে সুইটেবল না। যেখানে ডাটাগুলো টাইমস্ট্যাম্পের ভেতরে থাকে, সেই ক্ষেত্রে এটা বেস্ট কাজ করে। যেমন: logs, analytics রিলেটেড ডাটা ইত্যাদি।

Final Thought

ওপরের সব স্ট্র্যাটেজিগুলো কিছু স্পেসিফিক প্রবলেম সলভ করে। তবে প্রোডাকশনে রিকোয়ারমেন্ট অনুযায়ী হাইব্রিড অ্যাপ্রোচ ব্যবহার করা হয়। কারণ এই স্ট্র্যাটেজিগুলো কিছু বেনিফিট দেয় + কিছু ওভারহেডও নিয়ে আসে। কোনো স্ট্র্যাটেজিই পারফেক্ট না। তবে ইন্ডাস্ট্রিতে সবচেয়ে বেশি ব্যবহার হয় cursor based pagination।

Error Response Strategy

একটা অ্যাপ্লিকেশনে সবকিছু নিখুঁতভাবে কাজ করবে না। ইউজার ইনভ্যালিড ডাটা ইনপুট দিতেই পারে। এখন ইউজার যে ইনভ্যালিড ডাটা দিয়েছে, কী ডাটা দিয়েছে, কী ভুল করেছে—এই সব ইনফরমেশন ইউজারকে প্রপারলি প্রোভাইড করতে হবে, এটাই স্বাভাবিক ব্যাপার।

এখন কোনো error তৈরি হলে, সেটা প্রপারলি হ্যান্ডেল করে ইউজারকে একটা গোছানো ফরম্যাটে error response প্রোভাইড করতে হবে। তবে এই error response যেন predictable হয়, সেটা নিশ্চিত করতে হবে।

Error response-এর জন্য RFC 9457 স্ট্যান্ডার্ড রয়েছে।

RFC 9457 ("Problem Details for HTTP APIs") হলো একটি স্ট্যান্ডার্ড স্পেসিফিকেশন, যা HTTP API-এর জন্য সহজে বোঝা যায় এমন JSON বা XML এরর ফরম্যাট নির্ধারণ করে।

এই স্ট্যান্ডার্ড অনুযায়ী কিছু ফিল্ড প্রোভাইড করতে হয়, তবে সব ফিল্ড দেওয়া বাধ্যতামূলক না। নিচে উদাহরণ দেওয়া হলো:

type (URI Reference): একটি লিঙ্ক বা URI যা স্পেসিফিক সমস্যার ধরনকে চিহ্নিত করে। আদর্শভাবে এটি এমন একটি ডকুমেন্টেশনের লিঙ্ক হওয়া উচিত যা দেখলে এরর সম্পর্কে বিস্তারিত বোঝা যায়। কিছু না দিলে এটি ডিফল্ট হিসেবে about:blank থাকে।
status (Number): এই সমস্যার জন্য সার্ভার থেকে জেনারেট হওয়া সঠিক HTTP status code (যেমন: 400, 404, 422)।
title (String): সমস্যার একটি সংক্ষিপ্ত ও সহজবোধ্য শিরোনাম। এটি প্রতিবার একই রকমের হওয়া উচিত এবং কেবল ভাষার পার্থক্যের জন্য পরিবর্তিত হতে পারে।
detail (String): এই নির্দিষ্ট এররের পেছনের কারণ নিয়ে বিস্তারিত ব্যাখ্যা। এটি একেক রিকোয়েস্টে একেক রকম হতে পারে এবং ডিবাগিংয়ে সাহায্য করে।
instance (URI Reference): একটি ইউনিক URI বা পাথ যা নির্দিষ্ট এই ঘটনাটিকে আইডেন্টিফাই করে। এটি সাধারণত ইন্টারনাল রিকোয়েস্ট লগ বা ট্রানজেকশনের ইউনিক রেফারেন্স লিংক হিসেবে কাজ করে।

{
  "type": "https://example.com/probs/out-of-stock",
  "title": "Out of Stock",
  "detail": "The requested product is out of stock.",
  "instance": "https://api.example.com/products/123",
  "status": 400,
  "extra": "You can add any extra information you want."
}

আপনি চাইলে কাস্টম ফিল্ডও প্রোভাইড করতে পারেন। এখানে ফিক্সড কোনো নিয়ম নেই। যেমন ওপরে "extra" ফিল্ড ব্যবহার করা হয়েছে।

HATEOAS: API design standard

API design নিয়ে অনেক কিছুই বললাম, কিন্তু কোনো standard বা architectural style নিয়ে কোনো কথাই বলিনি। না বলার main reason হচ্ছে industry-তে already একটা popular architectural style রয়েছে। সেটা শিখে নিতে পারলেই you are good to go।

বটম লাইন

এই article-এ আমি just basic and important topic-গুলো cover করার try করেছি। এছাড়াও REST API design-এর ক্ষেত্রে আরও অনেক জিনিস আছে যেগুলো help করবে। API design-এর ওপর Stack Learner-এর একটা 9hrs free workshop আছে। আপনারা চাইলে তাদের YouTube বা official website থেকে access করতে পারেন।

আপনি কি এখনও POST /getUser টাইপের API লেখেন? সৎভাবে কমেন্টে বলুন! 😄👇

Day 02 — HTTP Deep Dive — ইন্টারনেটের রাজপথ

Monirul Islam — Mon, 07 Sep 2026 04:20:00 +0000

একটা জিনিস চিন্তা করুন, আপনি যখন কোনো খাবার খান, তখন কিন্তু খাবারটা সব কিছুই ঠিকঠাক থাকে। কিন্তু একটু চিন্তা করে দেখুন এই tasty খাবারটা prepare করার জন্য কী করা হয়েছে। Raw material collect করে, সেগুলো clean করার পরে একটা shape-এ নিয়ে যেতে হবে। Then প্রয়োজন অনুযায়ী নানা ধরনের মশলা, ঝাল, নুন, oil ইত্যাদি দিয়ে cook করে prepare করার পরেই কিন্তু এই অবস্থায় আপনি consume করছেন বা খাচ্ছেন।

Web browser-এ HTTP মূলত এই cooking-এর কাজটা করে। Web server থেকে data আসে packet আকারে। সেটা আপনি দেখে বুঝতে পারবেন না। এটা decryption করে then prepare করে browser-কে দিবে, then browser render করার পরে আপনি দেখতে পারবেন। এখানে HTTP এই prepare করার কাজটা করে। Browser-এর জন্য একটা data prepare করে।

HTTP কী?

HTTP (HyperText Transfer Protocol) হলো ইন্টারনেটের ভিত্তি, যার উপর দাঁড়িয়ে আছে পুরো World Wide Web। HTTP হলো একটি application-layer protocol যা client এবং server-এর মধ্যে data আদান-প্রদানের নিয়ম নির্ধারণ করে।

আপনি যখন browser-এ কোনো website-এর address লেখেন, তখন আপনার browser সেই server-কে HTTP-র মাধ্যমে বলে: "এই website-এর data-গুলো আমাকে দাও।" আর server সেই নিয়ম মেনে response পাঠায়।

HTTP কীভাবে কাজ করে?

HTTP কাজ করে Request-Response মডেলে:

সহজভাবে বললে, দোকানদার এবং customer-এর কথা বলা যেতে পারে। Customer দোকানদারের কাছে গিয়ে যা চাইবে সেটাই দোকানদার দেবে। এখানে customer হচ্ছে client আর দোকানদার হচ্ছে server।
Suppose customer এমন একটা জিনিস দিতে বলল যেটা available নাই। তখন কী হয়? দোকানদার বলেন যে এটা available না। HTTP-এর ক্ষেত্রে এরকম হলে server তখন error message return করবে।

আমি এখানে খুব easily frank-ভাবে আলোচনা করছি, এই request পাঠানো এবং response receive করার জন্য অনেক rule and regulation follow করতে হয়। একটা standard way-তে এই কাজগুলো করতে হয়। এই standard follow করার জন্য অনেকগুলো বিষয় আছে, for example: Method, URL path, URL and Query parameters, Headers, Body, Status Code ইত্যাদি। এগুলো নিয়ে নিচে আলোচনা হবে।

Methods: শুধু GET আর POST না!

একটা বিষয় চিন্তা করেন, আপনি যখন দোকানদারের কাছে কোনো কিছু নেন, তখন কিন্তু আপনাকে বলে দিতে হয় যে, এটা আমাকে দিন। আর টাকা pay করার সময়, আপনি আবার বলেন এই জিনিসের জন্য টাকা নিন। এখানে কিন্তু আপনি সবকিছু নির্দিষ্ট করে বলে দিচ্ছেন।

Similar way-তে HTTP request করার সময়ও বলে দিতে হয় যে, আমার কী দরকার। আমি server থেকে নেব নাকি server-কে আমি দেব। এটার জন্য HTTP-তে method নামে একটা জিনিস আছে।

HTTP Method মূলত ২ ধরনের: Read Methods & Write Methods।

Read Methods-এর কাজ হচ্ছে server থেকে data fetch করে আনা। Server আপনাকে data provide করবে। আর Write method তার উল্টো কাজটা করে, আপনার কোনো data server-কে provide করতে হলে এই method-গুলো use করতে হয়।

Read Methods অনেকগুলোই আছে তবে সবচেয়ে বেশি use হয়:

GET method: এই একটা method দিয়ে read related সবকিছু করা যায়। সবসময় এই method-টা use হয়।
POST method: Enterprise অ্যাপ্লিকেশন যেখানে জটিল কুয়েরি দিয়ে ডাটা ফেচ করতে হয়, সেখানে অনেক সময় POST মেথড ব্যবহার করে ডাটা রিড করা হয়। এটি মূলত জটিলতা কমানোর জন্য করা হয়ে থাকে।

Write Methods:

POST method: এই method দিয়ে নতুন কোনো ডেটা create করার সময় use করা হয়। এর মাধ্যমে client থেকে server-এ data send করা হয়।
PUT method: এই method-টা অনেকটা POST-এর মতো, তবে এই ক্ষেত্রে নতুন data create করার বদলে existing কোনো data-কে update করা হয়।
PATCH method: PUT আর PATCH method একদম similar, এদের difference হচ্ছে PUT method সম্পূর্ণ data-কে replace করে দেয় আর PATCH method যতটুকু দরকার ঠিক ততটুকুই update করে। PUT-এর থেকে PATCH method বেশি use হয়।
DELETE method: নাম শুনেই বুঝে গেছেন, এর আসলে কাজ কী। এই method-এর কাজ হচ্ছে existing data-কে delete করা।

এখানে আপনি চাইলে যেকোনো method use করে কাজ চালিয়ে নিতে পারবেন। তবে long term এগুলো maintain না করলে problem-এর সম্মুখীন হওয়ার possibility থেকে যায়।

Status Codes: দ্য ওয়ে সার্ভার কমিউনিকেটস 📡

আপনি দোকানদারকে pay করলেন এবং দোকানদার বলল যে এখনও টাকা কম হয়ে গেছে, আরও টাকা লাগবে। এখন আপনাকে কথার মাধ্যমে বলেছে আপনি বুঝে গেছেন। কিন্তু computer কীভাবে বুঝবে? আর এই বলার ধরন কিন্তু একেক সময় একেক রকমের হতে পারে। এটা কিন্তু guess করা প্রায় impossible। Client computer যাতে easily বুঝতে পারে, এই জন্য একটা standard কোনো কিছু দরকার। সেই standard-টাই হচ্ছে Status Code।

Status-এর উপরে depend করে, একটা request fail, success, pending, redirect হয়েছে কি না। Client এই status code দেখেই বুঝবে আসলে request success হয়েছে নাকি fail হয়েছে। এই status code-গুলো কয়েকটা category-তে বিভক্ত:

2xx — Everything OK।

200 OK : কাজ হয়েছে।
201 Created : নতুন resource তৈরি হয়েছে।

3xx — Redirection।

301 Moved Permanently : URL পাল্টে গেছে চিরতরে।
302 Found : সাময়িকভাবে অন্য জায়গায়।

4xx — Client Side Error।

400 Bad Request : Request-এ কোনো সমস্যা আছে।
401 Unauthorized : এই resource access করার জন্য আগে login করতে হবে।
403 Forbidden : এই resource access করার permission আপনার নেই।
404 Not Found : Resource পাওয়া যায়নি।

5xx — Server Side Error।

500 Internal Server Error : Server-এ কোনো অভ্যন্তরীণ সমস্যা হয়েছে।
503 Service Unavailable : সার্ভার সাময়িকভাবে ডাউন বা ওভারলোডেড। কিছু সময় পর আবার চেষ্টা করুন।

HTTP status code এখানে সুন্দরভাবে গুছিয়ে সব কোডের details দেওয়া আছে।

Headers: খামের ওপরের তথ্য ✉️

আপনার নিশ্চয়ই idea আছে যে একটা letter কীভাবে লিখে অন্যের কাছে পাঠাতে হয়। এখানে main letter-এর content থাকে। আর চিঠির খামে receiver এবং sender-এর address + কিছু information লেখা থাকে। এগুলো কিন্তু খুবই important।

Similar way-তে HTTP request-এও কিছু important information header-এর মাধ্যমে server-এ পাঠানো হয়। এগুলোর উপরে server-এর অনেক decision depend করে। যেমন ধরুন আপনি response হিসেবে HTML চাচ্ছেন নাকি raw text চাচ্ছেন নাকি JSON data expect করছেন এটা header-এর ওপর depend করে। আবার আপনি কী type data client থেকে server-এ পাঠাবেন এটাও header-এর ওপর depend করে।

নিচের header-এর example তুলে ধরা হলো:

Content-Type: application/json — এটা দিয়ে বোঝানো হয় আমি JSON পাঠাচ্ছি।
Authorization: Bearer <token> — এই token দিয়ে আমাকে চেনো এবং access দাও।
Cache-Control: no-cache — cache করো না।

Header মূলত ২ ধরনের:

Request Header: এই header, request-এর সাথে client থেকে server-এ পাঠানো হয়।
Response Header: এই header, response-এর সাথে server, client-এর জন্য পাঠায়।

🔒 HTTP vs HTTPS

HTTPS = HTTP + SSL

SSL কীভাবে কাজ করে তা আগের article-এ খুব সুন্দর করে বুঝিয়েছি। এখন আর এখানে explain করার দরকার হবে বলে মনে হয় না।

HTTP/2: একের ভেতর সব এবং পারফর্ম্যান্স ট্রিকস 🚀

HTTP/1.1 বহু বছর রাজত্ব করলেও এর একটি বড় সমস্যা ছিল। এটি Text-based এবং একটি TCP কানেকশনে একবারে মাত্র একটি Request-Response process করতে পারতো। ফলে একটি request complete না হওয়া পর্যন্ত server পরের request process করতে পারতো না। ফলে latency অনেক বেড়ে যেত। এতে করে একটি রিকোয়েস্ট complete না হওয়া পর্যন্ত পরের রিকোয়েস্ট প্রসেস করতে পারতো না!

ধরুন, একটি সুপারমার্কেটের ক্যাশ কাউন্টারে অনেকজন কাস্টমার লাইনে দাঁড়িয়ে আছে। কিন্তু ক্যাশিয়ার কেবল একজন কাস্টমারের বিল বানিয়ে শেষ করার পরেই পরবর্তী কাস্টমারকে সামনে ডাকতে পারছে! এটাকে বলে Head-of-Line (HOL) Blocking। ওয়েবসাইটে ৫০টি ছবি ও স্ক্রিপ্ট থাকলে ৫০বার লাইন ধরে সার্ভিস নিতে হতো!

এই problem গুলার সমাধান করতে ২০১৫ সালে আসে HTTP/2। এর মূল feature গুলো হলো:

Multiplexing: এখন আর আগের মতো আলাদা লাইনে দাঁড়াতে হয় না। একটি মাত্র TCP কানেকশনের ভেতর দিয়ে একই সাথে অনেক Request ও Response parallelly আদান-প্রদান করা যায়!
Binary Protocol: ডাটা আর আগের মতো টেক্সট হিসেবে যায় না, বরং 0 ও 1 বাইনারি ফ্রেমে রূপান্তর হয়ে যায়। এতে প্রসেসিং অনেক ফাস্ট হয়।
HPACK Header Compression: প্রতি রিকোয়েস্টে বারবার একই হেডার পাঠানোর বদলে হেডার কমপ্রেস করে ব্যান্ডউইথ বাঁচানো হয়।

এইগুলো ছড়াও আরও অনেক ফিচার রয়েছে।

HTTP/3: TCP ছেড়ে UDP

HTTP/2 এসে speed অনেক বাড়ালেও একটা মূল problem থেকে যায়। এটি তখনও TCP Protocol-এর ওপর নির্ভরশীল ছিল! TCP-র স্বভাব হলো ডাটা পেকেট নিখুঁতভাবে পৌঁছানো নিশ্চিত করা। এখন কোনো কারণে ইন্টারনেটে একটি মাত্র পেকেট ড্রপ করলে বা হারিয়ে গেলে, TCP পুরো লাইন আটকে দেয় যতক্ষণ না সেই পেকেট পুনরায় রিসিভ হয়! ফলে HTTP/2-এর মাল্টিপ্লেক্সিংও আটকে যেতো!

এই problem টাকে solve করার জন্য আসে HTTP/3। এটি TCP পুরোপুরি বাদ দিয়ে UDP-র ওপর নির্মিত QUIC Protocol ব্যবহার করে।

এর feature হলো:

No Transport Head-of-Line Blocking: এখন আর একটা পেকেট হারালে পুরো ট্রাফিক থমকে দাঁড়ায় না! বাকি সার্ভিসগুলো নিজেদের মতো আপন গতিতে চলতে থাকে।
0-RTT Handshake (মুহূর্তের মধ্যে কানেকশন): TCP-র মতো বারবার ৩-ওয়ে হ্যান্ডশেক না করে অতি দ্রুত প্রথম রিকোয়েস্টেই রেসপন্স আনা সম্ভব হয়।
Connection Migration (নেটওয়ার্ক বদলালেও ডিসকানেক্ট হয় না!): মনে করুন, আপনি ওয়াইফাই থেকে বাড়ির বাইরে গিয়ে মোবাইল ডাটায় সুইচ করলেন। আপনার IP পরিবর্তন হয়ে গেল! প্রথাগত TCP সিস্টেমে কানেকশন ডিসকানেক্ট হয়ে ডাউন হয়ে যেতো। কিন্তু HTTP/3 IP-র বদলে ইউনিক Connection ID ব্যবহার করে, তাই নেটওয়ার্ক বদলালেও আপনার ডাউনলোডিং বা স্ট্রিম বিরামহীনভাবে চলতে থাকে!

বটম লাইন

HTTP শুধু GET/POST না, Methods, status codes, headers — এই পুরো জিনিসটা মাথায় না থাকলে API design-এ, debugging-এ বারবার ক্যাচাল লাগবে। এই জিনিসগুলো maintain করলে বিশেষ করে Team-এ কাজ করলে অনেক সমস্যা থেকে দূরে থাকা যায়। আমি এমনও সিচুয়েশন দেখেছি যেখানে data conflict-এর জন্য ২০০ status code return করছে!

বি:দ্র: HTTP হলো stateless — প্রতিটা request স্বাধীন। আগের request-এর কথা server মনে রাখে না। এই কারণেই আমরা JWT token, session, cookie ব্যবহার করি।

আপনার সবচেয়ে বেশি confuse করা status code কোনটা? কমেন্টে বলুন! 👇

Day 1 — ইন্টারনেট আসলে কীভাবে কাজ করে

Monirul Islam — Sun, 06 Sep 2026 04:20:00 +0000

আকাশ নামের এক ছেলের কাছে একটা ফোন এলো। ওপাশ থেকে একজন খুব সিরিয়াস গলায় বলল, "আমাদের ব্যাংকের server maintain করা হচ্ছে। আপনার অ্যাকাউন্টে একটু সমস্যা হয়েছে। এখনই ঠিক না করলে অ্যাকাউন্ট freeze হয়ে যাবে।" আকাশ ঘাবড়ে গেল।

"আপনাকে একটা OTP সেন্ড করেছি, জাস্ট ওটা বলেন। সব ঠিক হয়ে যাবে।" আকাশ কিছু না ভেবেই OTP টা দিয়ে দিল। পরের মুহূর্তেই ওর ফোনে মেসেজ এলো—অ্যাকাউন্টের পুরো টাকা গায়েব!

এখন আপনার মনে প্রশ্ন জাগতে পারে। আমি তো জাস্ট কয়েকটা সংখ্যা দিলাম। তাহলে—

আমার ব্যাংকের টাকাগুলো অন্য কারো কাছে চলে গেল কীভাবে?
এটা কীভাবে সম্ভব?
তারা কি জাদুকর?
নাকি আপনার ফোনের ভেতরে ঢুকে টাকা নিয়ে গেল?

আসলে কোনো জাদু নেই। সবকিছুই ঘটছে একটা বিশাল জালের মাধ্যমে। যেটার নাম Internet।

Internet জিনিসটা কী?

চিন্তা করেন, আপনি একটা পাড়াতে থাকেন। পাড়ার বাড়িগুলো একে অপরের সাথে রাস্তা দিয়ে কানেক্টেড থাকে। ইন্টারনেটও ঠিক এরকমই।
এখানে বাড়িগুলো হচ্ছে এক একটা computer বা machine। আর রাস্তাগুলো হচ্ছে তার বা cable। এই তারের মাধ্যমেই পুরো দুনিয়ার সব কম্পিউটার একসাথে কানেক্টেড থাকে।

এখন যেমন ইন্টারনেটকে সিম্পল এবং সহজ মনে হয়, আগে কিন্তু এত সহজ ছিল না। ১৯৬০-এর দশকের শেষের দিকে, যুক্তরাষ্ট্রের ডিফেন্স সিস্টেম নিজেদের ভেতরে সিক্রেট ডাটা শেয়ার করার জন্য একটা নেটওয়ার্ক তৈরি করে, যার নাম ছিল ARPANET। তখন এটা শুধুমাত্র সরকারি কাজের ব্যবহারের জন্য ছিল। এটাই মূলত পরবর্তীতে বিবর্তিত হয়ে internet হয়ে যায়।

Internet উন্মুক্ত হতে শুরু করে যখন Tim Berners-Lee World Wide Web (WWW)-এর প্রবর্তন করেন। আর আজকের দিনে আমরা যা দেখছি YouTube, Facebook, Google, Netflix, Cloud, Online Banking, সব এই internet-এর ফসল।

DNS: ইন্টারনেটের ফোনবুক

মনে করুন আপনার মা আপনাকে বলল, "ঐ মিস্টার মনসুর সাহেবের বাড়ির সামনে যে দোকান আছে সেখানে যাবি, গিয়ে লিস্টের মালামালগুলো নিয়ে আসবি।" সাথে কিছু টাকাও দিল। এখন আপনি কী করবেন?

আপনি সোজা চলে যাবেন সেই দোকানে আর যা কাজ আছে শেষ করে ফেলবেন। কিন্তু বিষয়টা যদি অন্য দূরের কাউকে করতে বলা হয় তাহলে সে কী করবে?

তার দোকানে যেতে হবে, skip করতে পারবে না। আর সে আপনার এলাকার কিছুই চেনে না। এখন তাকে যেতে হলে নিচের কাজগুলো করতে হবে:

এলাকা সম্পর্কে যে ভালো চেনে-জানে তার কাছে গিয়ে জিজ্ঞাসা করে জেনে নিতে হবে, then সেই instruction follow করে সেই দোকানে যাবে। এখন সেই জানা লোকটা আপনিও হতে পারেন।

DNS ঠিক এই কাজটাই করে।
একটু আগেই বললাম যে internet অনেক computer-কে একসাথে করে communicate করে। এই computer-গুলোকে identify করার জন্য unique IP address থাকে। এগুলো দিয়ে সেই computer-গুলো access করা যায়। IP address নিয়ে একদিন বিস্তারিত কথা হবে। কিন্তু কথা হচ্ছে, এই IP address মনে রাখা একটু কষ্টকর, এর জন্য Domain Name System (DNS) use করা হয়। এখন এই domain-এর বিপরীতে তো IP address-গুলো save করা লাগবে, যেমনভাবে আপনি আপনার এলাকার সবকিছু নিজের memory-তে save করে রেখেছেন।

DNS-এ আপনার domain name-এর বিপরীতে একটা IP address save করা থাকবে এবং আপনি URL-এ domain লিখে যখন hit করবেন তখনই, এই IP address resolve হয়ে যাবে এবং destinated computer-এ পৌঁছে যাবে।

আশা করা যায়, DNS সম্পর্কে idea হয়ে গেছে।

TCP/IP: ডেটার ডাকঘর

একটা বিষয় চিন্তা করুন, আপনি যখন আপনার কোনো friend বা senior বা কোনো ব্যক্তির সাথে কোনো conversation করতে চান তখন আপনি কী করেন?
normally তাকে ভালো-মন্দ জিজ্ঞাসা করে তার কাছ থেকে জেনে নেন যে সে free আছে কিনা বা তার সাথে কথা বলতে পারবে কিনা? সে যদি free থাকে বা রাজি হয় তাহলে কথাবার্তা শুরু হয় তারপর একটা সময় শেষ হয়ে যায়।
অনেক ক্ষেত্রে, সে কিন্তু আপনার এই request reject করে দিতে পারে, কারণ তার অন্য কাজ থাকতে পারে বা আপনার সাথে তার কথা বলার ইচ্ছা নেই।

similar-ভাবে, যখন ২টা computer connect করার try করা হয়, তখন কিন্তু এই বিষয়গুলো ভাবতে হয়। আসলে সেই machine কি free আছে বা আমার সাথে connect হবে কিনা। accept করলেই তারপর connect করতে হবে। এই connection তো আর এমনি মুখে বললেই হয়ে যাবে না। এর জন্য rules and regulation প্রয়োজন বা একটা Protocol প্রয়োজন। সেই protocol-টাই হচ্ছে TCP/IP।

TCP/IP হচ্ছে একটা protocol suite, যা ২টা computer-কে connect করতে help করে এবং data flow-কে regulate করে। এটা মূলত OSI model-এর Networking layer-এ কাজ করে। Data-কে packet-এ transform করে network-এর through-তে অন্য computer-এ send করার জন্য prepare করে।

TCP/IP big topic। এই simple একটা topic নিয়ে পুরা একটা book লিখে ফেলা যাবে। আমি simple-ভাবে বুঝানোর try করলাম।

Note: TCP/IP নিয়ে যদি কেউ বিস্তারিত পড়তে চান তাহলে আগে OSI model-টা ভালো করে পড়ে নিবেন। আর তারপর internet আর networking সম্পর্কে হালকা basic idea নিলেই আপনি TCP/IP বোঝার জন্য prepare।

HTTP: ভাষাটা শেখো

একটু আগেই বললাম যে TCP/IP দিয়ে ২টা computer connect করা যায়। আর সেখানে data-গুলো packet-এ transfer করা হয়। কিন্তু problem হচ্ছে এই packet-গুলোকে কিন্তু আপনি দেখতে পারবেন না। এই packet-গুলো সুন্দর করে সাজাতে হবে যাতে করে user বা client খুব easily এগুলো use করতে পারে।

এই কাজটাই করে HTTP (Hyper Text Transfer Protocol)। যখন আপনি browser-এ কোনো URL-এ hit করেন তখন সেটা server থেকে packet আকারে data client-এর কাছে আসে। এরপরে HTTP সেটাকে browser-এর জন্য ready করে এবং browser এই content-গুলো render করে তখন আপনি website-এর visual look-টাকে দেখতে পারেন।

HTTP মূলত এই কাজটাই করে থাকে।

SSL: Security

এতক্ষণ তো অনেক কিছুই বললাম। এখন কথা হচ্ছে সবাই যদি এই rules and regulation follow করে internet-এ data pass করা শুরু করে তাহলে কিন্তু যেকেউ চাইলেই একটু trick করে অন্য জনের data-র access নিতে পারবে। তাহলে solution কী?

Solution is SSL (Secure Sockets Layer)।

SSL-এর কাজ হচ্ছে ডাটাকে Encrypt করা। Encrypt করা, সেটা আবার কী জিনিস?

ধরুন, আপনি একটা চিঠিকে একটা বাক্সে তালাবদ্ধ করে পাঠালেন। এই তালার চাবি আছে শুধু আপনার আর প্রাপকের কাছে। মাঝপথে কেউ বাক্সটা পেলেও খুলতে পারবে না কষ্টে, কারণ তার কাছে চাবি নেই।

SSL মূলত এই কাজটাই করে। Data-কে key দিয়ে encrypt করে send করে এবং অন্য computer থেকে receive করার পরে key দিয়ে data-টাকে decrypt করে। এই ক্ষেত্রে মাঝখান থেকে কেউ data-কে পেলেও তা decrypt করতে পারবে না।

এই encryption decryption-এর জন্য অনেকগুলো algorithm রয়েছে। এখানে algorithm ভেদে এক বা একাধিক key ব্যবহার করা হয়ে থাকে encrypt/decrypt করার জন্য। এই নিয়ে অন্য একটা ব্লগে বিস্তারিত আলোচনা হবে।

Internet Protocol

HTTP-এর মতো, এটাও একটা protocol। এই protocol-এর কাজ হচ্ছে, দুইটা computer-এর মধ্যে connection establish করা এবং data transfer-এর জন্য ideal (short and less costly) path খুঁজে বের করা। Then data packet properly transfer করা।

Internet-এর through-তে যে data transfer হয়, তবে একটা জিনিস—এই protocol কিন্তু data loss হলে সেটার responsibility নিবে না। এটা জাস্ট data transfer করবে। That's it।

এই responsibility নেওয়ার জন্য transport protocol যেমন TCP ব্যবহার করা হয়।

IP Routing

IP Routing হচ্ছে internet-এর through-তে data transfer করার জন্য ideal path খুঁজে বের করা। এই routing করার জন্য কিছু algorithm ব্যবহার করা হয়। যেমন: OSPF (Open Shortest Path First), BGP (Border Gateway Protocol) ইত্যাদি।

যখন কোনো request কোনো machine-এ পাঠানো হয় তখন ওই machine-এর IP address-কে target করে request send হয়। তখন request intercept করে router। Router-এর local routing table ওই machine-এর IP address store করে রাখে। সেখান থেকে fetch করে router এই request particular ওই machine-এ transfer করে দেয়।

TCP (Transmission Control Protocol)

এই protocol-টার কাজ হচ্ছে, data-এর consistency এবং reliability ensure করা। Internet Protocol data transfer করতে help করে, কিন্তু data loss হলে তার responsibility নেয় না। Data যাতে loss না হয় এবং properly transfer হয় সেটা ensure করার জন্য TCP ব্যবহার করা হয়। Basically TCP একটা connection establish করে data transfer start করে। Receiver end-এ data receive হলে, সেখান থেকে একটা acknowledgment-এর message আসে। এইভাবেই data-র reliability ensure হয়।

TCP-র reliability ensure করার জন্য flow control এবং error control-এর ব্যবস্থা আছে। Present time-এ TCP এবং IP এই দুইটা protocol একসাথে ব্যবহার করা হয়।

N.B. TCP একটা huge topic। এর অনেকগুলো layer রয়েছে। প্রত্যেকটা layer different different responsibility carry করে। এখানে সে বিষয় নিয়ে আলোচনা করছি না। অন্য একদিন সেটা নিয়ে আলোচনা হবে।

UDP (User Datagram Protocol)

এটা TCP-র মতো একটা protocol। কিন্তু এখানে delivery check করা হয় না। অনেকটা fire and forget-এর মতো। এই protocol real-time communication যেমন Video streaming, Voice Calling, online Gaming ইত্যাদিতে ব্যবহার হয়।

তাহলে হ্যাক হলো কীভাবে?

এখন একটা প্রশ্ন থেকেই যায়, এত কিছু থাকার পরেও আকাশের টাকা গায়েব হলো কীভাবে?

এখানে hacker-রা internet break করেনি। Hacker আকাশের brain বা mobile hack করে টাকাটা গায়েব করেছে।

আসলে আকাশের account internet-এর মাধ্যমে access করার facility আছে। এখন ঐ account access করার জন্য একটা OTP দরকার ছিল যেটা মূলত আকাশের mobile-এ send হবে। সেটা পেলেই পুরা account-এর access পেয়ে যাবে। আর hacker-রা কিন্তু call করেই সেই OTP-টা collect করেছে।

এভাবেই মূলত টাকাগুলো গায়েব হয়েছে।

বটম লাইন

ইন্টারনেট মূলত অসংখ্য কম্পিউটারের একটা বিশাল নেটওয়ার্ক, যারা একে অপরের সাথে তারের মাধ্যমে কানেক্টেড। ডাটা ট্রান্সফার করার জন্য এখানে HTTP, TCP/IP-এর মতো প্রটোকল কাজ করে। আর ডাটাকে সিকিউর রাখার জন্য কাজ করে SSL বা Encryption।

এই বিষয়ে আরও গভীরে যাওয়ার ইচ্ছা থাকলে OSI model সম্পর্কে একটু রিসার্চ করার অনুরোধ রইল।

আপনার সবচেয়ে বড় challenge কী ছিল? কমেন্টে জানাবেন 👇

Agile Software Development Part-1 | Software Engineering

Monirul Islam — Sun, 11 May 2025 10:37:44 +0000

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

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

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

এখই এই পরিস্থিতে যদি Plan-driven বা Waterfall মডেল ব্যবহার করা হয়, যেটা অনেক সময় সাপেক্ষ , তাহলে দেখা গেল কাস্টমার এটা ব্যবহার করায় ছেড়ে দিছে।

দ্রুত সফটওয়্যার ডেভেলপমেন্ট করার এমন কিছুর প্রসেস দরকার যেটার দ্বারা পরিবর্তন গুলো সহজে পরিচালনা করা যায়। এজন্য একমাত্র সমাধান হচ্ছে Agile Development or Agile methods.

Agile methods

Agile methods হলো একটি incremental development method যেখানে increments গুলো ছোট ছোট এবং সাধারনভাবে ২-৩ সপ্তাহের মধ্যে মধ্যে নতুন নতুন ফিচার রিলিজ করা হয়ে থাকে। এখানে কাস্টমারকে সংযুক্ত করা হয় এবং তার ফিডব্যাকের প্রহন করা হয়। এই ফিডব্যাকের উপর নির্ভর করে নতুন ফিচার পরবর্তী রিলিজে অ্যাড বা রিমুভ করে দেওয়া হয়।

Plan Driven পদ্ধতি মূলত আবিষ্কার করা হয়েছিল, মূলত বড় টিমের জন্য। এই পদ্ধতিতে অনেক সময় লেগে যায়। Plan Driven পদ্ধতি ক্রিটিক্যাল সিস্টেম গুলো ডিজাইন করা জন্য ব্যবহার করা সব থেকে ভাল। কারন এই পদ্ধতিতে সব থেকে বেশি মাথাব্যাথা থাকে প্লানিং, জিজাইনিং এবং ডকুমেন্টশন এর উপর। এটা অবশ্যই যৈক্তিক। কারন এসব সিস্টেমে একটু এদিক ওদিক হয়ে গেলে বড় আকারে ক্ষতি হয়ে যেতে পারে। যেটা পূরন করা সম্ভব নয়।

এই ভারী পদ্ধতি ব্যবহার করে একধরনের অশান্তির সৃষ্টি হয় তখন আর্বিভাব ঘটে Agile methods এর। Agile methods এর দর্শন বা ফিলোসফি এর ম্যানিফেস্টতে বোঝা যায়।

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Visit Agile Manifesto

Agile এর সবগুলো methods একটা জিনিসের পরামর্শ দিয়ে থাকে, দ্রুত ডেভেলপমেন্ট এবং ডেলিভারি করা। এসব মেথডস গুলো বিভিন্ন পদ্ধতিতে কাজ করে থাকে কিন্তু এতের ভিতরে বিদ্যমান নীতি বা প্রিন্সিপাল গুলো একই ধরনের।

Agile methods গুলো দুই ধরনের সিস্টেম ডেভেলপ করা জন্য সব থেকে সফল।

প্রোডাক্ট ডেভেলপমেন্ট সেখানে কোন কোম্পানি বিক্রয় করা জন্য ছোট অবথা মিডিয়াম সাইজের প্রোডাক্ট ডেভেলপ করছে।
কোন সংগঠনের জন্য কাস্টম সিস্টেম ডেভেলপমেন্ট

Agile Development Techniques

Agile methods মুলত ডেভেলপ হয় নব্বই এর দশকে। সফটওয়্যার এর ডেভেলপমেন্ট কালচারে পরিবর্তন এক্সট্রিম প্রোগ্রামিং এর মধ্যে দিয়ে। এই পদ্ধতিতে বেস্ট প্রাক্টিস গুলো ফলো করা হয়, iterative ডেভেলপমেন্ট করা হয় এবং ডেভোলোপমেন্ট চরম পর্যায়ে পুশ করা হয়। একটা সিস্টেমের একটা নতুন ভার্সন একই দিনে আলাদা আলাদা প্রোগ্রামার ডেভেলপ, ইন্টিগ্রড এবং টেস্ট করবে।

extreme programming-এ requirements গুলোকে বিভিন্ন সিনারিও হিসেবে প্রকাশ করা হয়, যেগুলো মুলত সিরিজ টাস্ক হিসবে ইমপ্লিমেন্ট করা হয়। প্রোগ্রামাররা এই টাস্ক গুলোর উপর ভিত্তি করে বিভিন্ন টেস্ট কেস ডেভেলপ করে এবং টেস্ট কোড লেখার এই টেস্ট গুলো অবশ্যই পাস করাতে হয়।

প্রাক্টিক্যালি দেখলে, দেখা যাবে XP যেমন টা সহজ মনে হয়, আসলে এটা ততটায় কঠিন একটা প্রসেস। এখানে বেশিরভাগ কোম্পানির ক্ষেত্রে এই প্রসেস টা ইন্টিগ্রেট করা সম্ভব হয় না। বিভিন্ন ধরনের সমস্যা দেখা দেয়। ম্যানেমেন্ট করতে সব থেকে বেশি সমস্যার সৃষ্টি হয়। বর্তমানে বেশির ভাগ কোম্পানিই Scrum কে ব্যবহার করছে কারন এটা সম্পূর্ণ ম্যানেজমেন্ট ফোকাস।

User Stories

software requirements প্রতিনিয়ত পরিবর্তন হতে থাকে। এসব পরিবর্তনকে হ্যান্ডেল করা করা জন্য Agile methods এর আলাদা কোন requirements engineering আকটিভিটি নাই। মুলত requirements elicitation করা হয় ডেভেলপমেন্ট করার সময়। এই জিনিস টাকে সহজ করার জন্য উদ্ভব হয় “user stories”। “user stories” হল একটা সিনারিও যেখানে সিস্টেম ডেভেলপ হওয়ার পর একজন ব্যবহারকারীর কি রকম অভিজ্ঞতা হবে তার বিবরন।

কাস্টমার এবংডেভেলপমেন্ট টিম একসাথে আলোচনার মাধ্যমে একটা স্টোরি কার্ড ডেভোলোপ করে যেখানে সব কিছু বিস্তারিত উল্লেখ থাকে। story card গুলো নিচের মত হতে পারে,

user stories সিস্টেম ডেভেলপ করা জন্য প্লানের কাজে ব্যবহার করা যেতে পারে, যেখানে ইটারেটিভ ভাবে কাজ গুলো করা হবে। একবার story card গুলো ডেভেলপ হয়ে গেলে সেগুলো কে ভেঙ্গে আলাদা আলাদা টাস্ক এ পরিনত করা হয়। এখানে মুলত রিসোর্স requirements এস্টিমেট করা হয় এবং কাস্টমার এর সাথে আলোচনা করা হয় এবং দেখা হয়, কোন পরিবর্তন করার প্রয়োজন আছে কিনা। এখানে টাস্ক গুলোকে এমনভাবে বিভক্ত করা হয় যাতে সেগুলো ২ সপ্তাহের ভিতরে তৈরি করা সম্ভব হয়।

কোন কিছু যদি পরিবর্তন করা হয় তাহলে সেগুলো ২ সপ্তাহ পরে যে রিলিজ দেওয়া হবে সেখানে যুক্ত করে দেওয়া হয়। আর যদি কোন আগে থেকে ডেভেলপ করা থাকে তাহলে কাস্টমার এর ফিডব্যাক এর নির্ভর করে সিদ্ধান্ত নেওয়া হয়ে ওই নতুন ফিচার থাকবে নাকি আগের যেটা ছিল সেটাই থাকবে। আর যেগুলোর দরকার নেই সেগুলোকে মুছে ফেলা হয়।

user stories এর সব থেকে বড় সমস্যা হল এর পূর্ণতা নিয়ে। একটা সম্পূর্ন সিস্টেমের requirements পূরনের জন্য প্রয়োজনীয় সকল স্টোরি গুলো ডেভেলপ হয়ে কিনা তা বোঝা খুব কঠিন। আবার একটা স্টোরির সিস্টেমের কোন একটিভিটি সম্পুর্ণ রুপে আলোচনা করছে কিনা তাও বোঝা কঠিন। ইউজার প্রায়শ অনেক কিছুই উল্লেখ করতে ভুলে যান।

Refactoring

Software Engineering এর মৌলিক উদ্দেশ্য হচ্ছে সিস্টেম ডিজাইন করা পরিবর্তনের জন্য। এমন ভাবে সিস্টেমটাকে ডিজাইন করতে হবে , যাতে সহজে পরিবর্তন করা যায়। Refactoring এর মানে হচ্ছে, প্রগ্রামিং টিম সম্ভাব্য ইম্প্রুভমেন্ট গুলো খুজবে এবং তৎক্ষণাৎ সেগুলোকে ইমপ্লিমেন্ট করবে।

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

Incremental development একটি মৌলিক সমস্যা হচ্ছে, এখানে সিস্টেম স্ট্রাকচার ধীরে ধীরে খারাপে দিকে যেতে থাকে। একটা পর্যায়ে এমনও হতে পারে যে সিস্টেম এ আর কাজ করা সম্ভব হচ্ছে না। Refactoring সিস্টেম স্ট্রাকচার এর মান বৃদ্ধি করে বোধ্যগম করে তোলে এবং স্ট্রাকচার যাতে অবনতি না হয় সেদিকে লক্ষ্য রাখা হয়।

Refactoring এর উদাহরন অনেক রয়েছে। Code duplication remove, unused code remove, unwanted feature remove, make code organize ইত্যাদি। আরো ভালো করে বললে, কোড অনেক অংশ আছে যেগুলো বার ব্যবহৃত করে হয়েছে। একট কোড কপি পেস্ট করা হয়েছে। এক্ষেত্রে ওই কোডকে একটা ফাংশন বানিয়ে ব্যবহার করে কোড ডুপ্লিকেশন কমে যাবে।

Test Driven Development

Test Driven Development বা TDD একটা পদ্ধতি যেখানে কোন কিছু ইমপ্লিমেন্ট করার আগেই তার প্রয়োজনীয় টেস্ট কেস লেখা হয়। TDD একটা Extreme Programming এর একটি অংশ। XP তে টেস্টিং এর কিছু বৈশিষ্ট রয়েছে।

Test First Development
incremental test development from scenarios
user involvement in the test development and validation
the use of automated testing frameworks

Test Driven Development বা TDD সফটওয়্যার ইঞ্জিনিয়ারিং -এ একটি গুরুত্বপূর্ণ উদ্ভাবন। সাধারন ভাবে আমরা কি করি কোন ফিচারকে ইমপ্লিমেন্ট করি । তারপর তার জন্য প্রয়োজনীয় টেস্ট কেস লিখি। এখানে সমস্যা হচ্ছে আমরা অনেক কিছুই উপেক্ষা করতে পারি আবার কোড লেভেল ফোকাস করতে অনেক টেস্ট কেস এর কথা মাথায় থেকে চলে যেতে পারে। অনেক ক্ষেত্রে অনেক বাগ দেখা দিতে পারে। TDD কোন কিছু ইমপ্লিমেন্টশন করা আগে তার জন্য প্রয়োজনীয় সকল টেস্ট কেস গুলো লিখে ফেলা হয়। এবং তারপর কোড লেভেলে কাজ করা হয়। বাগ হওয়ার সম্ভাবনা কমে যায়। তাছার কোডার কে বেশি চিন্তা করা লাগে না। আর সব থেকে বড় কথা টেস্ট কেস গুলো যতক্ষন তা পাস হচ্ছে ততখন সেটা মূল সিস্টেমের সাথে যোগ করা হবে না।

TDD এর আরেক টা সুবিধা হচ্ছে কাস্টমারকে হ্যাপি রাখা যায়। আমি ব্যক্তিগত ভাবে কাজ করতে যেয়ে অনেক সমস্যার সম্মুখীন হয়েছি।

“এইটা কেন কাজ করছে, এইটা কেন কাজ হচ্ছে না? এই এমন হচ্ছে কেন? কাল রাতেই তো ঠিক ছিল আজকে আবার কি হল ? ইত্যাদি “

এখানে আমার ভুল ছিল আমি তার Story কে ভালো করে ব্যাখা করতে পারিনি। কিরকম ফিচার লাগবে সেটা নিয়ে তেমন আলোচনা করলেও সেগুলো অনেক হাই লেভেল এর ছিলো (কোড থেকে অনেক উপরে )। এখানে যদি TDD প্রয়োগ করা হয়, তাহলে কি হত, কাস্টমার এর ভাব পরিবর্তন হয়ে যেত। তখন তার কথা নিম্নরুপ হতে পার,

“এই ফিচার টা এমন করা যায় না? এই টা নিচে না দিয়ে উপরে দিকে দেওয়া যেতে পারে কিনা? এই ফিচার টা নতুন করে অ্যাড করা যায় কিনা ? ইত্যাদি”

কাস্টমার এর কথা টোনই পরিবর্তন হয়ে যাবে। কারন যখন তার story এর উপরে বেইজ করে Story card বানানো হয়েছিল, কাস্টমার এর সাথে মিলেমিশেই টেস্টকেস গুলো লেখা হয়েছিল। এখানে তার মাথায় অনেক টেস্ট কেস এর আর্বিভাব হতে পারে, যেগুলো ডেভেলপার এর মাথায় সহজে আসবে না। এখন যদি কোন কিছু হয় তাহলে কাস্টমার ব্লেম করা সুযোগ পাবে না। কারন সে নিজেও তো ছিল। আর সেহেতু সব শর্ত্যই পূরন হয়ে যাচ্ছে এর মানে আর কোন সমস্যা নেই। কোড মূল সিস্টেমের সাথে অ্যাড করা জন্য প্রস্তুত।

TDD এর জন্য টেস্ট আটোমেশন অত্যাবশীকীয়। টেস্ট গুলো লেখা হয় কম্পোনেন্ট গুলো তৈরি হওয়ার আগে execute করা জন্য। এই টেস্ট কেস গুলো অবশ্যই স্বতন্ত্র হতে হবে যাতে ইনপুট দিয়ে সহজে টেস্ট করা যায়। টেস্টিং কে অবশ্যই অটোমেশন করতে হবে যাতে যখন কোন পরিবর্তন হয় তখন যেন টেস্টিং শুরু হয়ে যায়। ফলাফল ইতিবাচক হলে মূল সিস্টেমে যুক্ত করতে দেওয়া হবে আর না হলে আবার কোড কর।

TDD তে কিছু সমস্যা আছে।

প্রোগ্রামার টেস্টিং কে অগ্রধিকার দেয় তবে অনেক ক্ষেত্রে টেস্ট লেখার সময় সটকাট ব্যবহার করে। এসময় অনেক টেস্ট কেস এড়িয়ে যায়। এক্ষেত্রে অনাকাক্ষিতে বাগের দেখা মিলে।
কিছু কিছু টেস্ট আছে যেগুলো লেখা খুবই কষ্টকর বিষয়।

TDD তে অনেক টেস্ট কেস লেখা হয়। কিন্তু তারপরও এটা বলা মুশকিল যে টেস্ট কেস গুলো সম্পূর্ণ সিস্টেমকে কভারেজ দিতে পারছে।

Pair Programming

Pair এর বাংলা হচ্চে জোড়া। যখন দুইজন প্রোগ্রামার একসাথে একই কম্পিউটারে বসে প্রোগ্রামিং করবে তখন তাকে Pair Programming বলা হবে। কোন টাস্ক সম্পূর্ন করা জন্য আপনার একজান পার্টানার থাকবে। তবে এই পেয়ার প্রতিবার ডায়নামিক্যালি তৈরি করা হবে।

Pair Programming এর কিছু সুবিধা আছে।

Collective Ownership: সিস্টেম সবাই একই সাথে কাজ করে তাই সিস্টেম এর Ownership সবার থাকে। কেউ কাউকে ব্লেম করতে পারে না। দায়িত্ব বা দায়ভার সবার থাকে।
Informal Reviews: যেহেতু একজন পেয়ার থাকে সেহেতু কোডের একটা Informal review হয়ে যায়। এখান থেকে সিস্টেম এ অ্যাড হওয়ার আগেই অনেক এরর বের হয়ে আসতে পারে। যদি এই প্রসেসে অনেক সময় লেগে যায় বিধায় ডেভেলপমেন্ট প্রসেস এ ডিলে তৈরি হয়।
Encourages Refactoring: নিজে নিজে কোড লিখলে অনেক সময় বোঝায় যায় না যে এখানে ইম্পূভ করা যেত । আর অন্য বিস্তারিত ভাবে বলে দেবে না। এখন একজন পেয়ার থাকলে দুইজনের মধ্যে আলোচনা অনেক ইম্পুভমেন্ট করা যেতে পারে।

এখানে যে কেউ মনে করবে যে, Pair Programming individual programming এর থেকে ভালো না। আসলে দুইজন আলাদা আলাদা ভাবে যে কোড লিখতে পারবে , Pair Programming -এ তা অর্ধেক হয়ে যাবে। অনেক কোম্পানি আছে যারা Pair Programming কে ব্যবহার করে তারা এই নিয়ে সন্দিহান এবং তার এটা আর ব্যবহার করে না। তবে ক্ষেত্রে বিশেষ সিনিয়র প্রোগ্রামার জুনিয়র প্রোগ্রামের সাথে এক সাথে কাজ করে।

Pair Programming সব থেকে সুবিধাজন হচ্ছে জুনিয়র এবং মিডলেভেল প্রোগ্রামারদের জন্য। কিন্তু সিনিয়র লেভেল প্রোগ্রামারদের জন্য একবারে যুক্তি যুক্ত নয়। এতে তাদের প্রোডাক্টিভিটি অনেক কমে যাবে।

Pair Programming ক্ষেত্র বিশেষ-এ এখনো ব্যবহার করা হয়। তবে বেশির ভাগই কোম্পানিই এতা ব্যবহার করতে চাইবে না।

To be continued...

Software Process

Monirul Islam — Thu, 08 May 2025 04:06:40 +0000

Introduction

Software Process হলো একগুচ্ছ পরস্পর সম্পর্কিত কার্যক্রম (activities) যা একটা একটি Software production এর দিকে নিয়ে যায়।

Software Process টা System এর ভিত্তি করে বিভিন্ন ধরনের হতে পারে। এর জন্য নিদির্ষ্ট কোন পদ্ধতি নেই। তবে process যেমনই হোক না কেন ৪টা জিনিস অবশ্যই তার ভিতরে রাখতে হবে।

১। Software Specifications

২। Software Development

৩। Software Validation

৪। Software Evolution

( নিচে এগুলো নিয়ে বিস্তারিত আলোচনা করা হবে। )

Software Process একটি জটিল বিষয় এবং অন্য একটি সৃজনশীল ( Creative) কাজগুলোর মত করে, মানুষের সিদ্ধান্ত এবং তাদের চিন্তার ধারার উপর নির্ভর করে। যেহেতু এখানে কোনো Universal কোন Process নায় এই জন্য, কম্পানিগুলো তাদের মত করে একটা Process তৈরি করে নেয় , যাতে তারা তাদের কম্পানিতে কর্মরত Engineer দের দক্ষতা ব্যবহার করে সর্বোচ্চ সুবিধা গ্রহন করতে পারে। তবে এক্ষেত্রে এই প্রসেস Engineer এবং System এর উপর নির্ভর করে সময়ের সাথে সাথে পরিবর্তন হতে পারে।

Roles reflect the responsibilities of the people involved in the process. For example: Project Manger, programmer , database designer etc.

Software Process Models

Software Process model হলো software process এর সহজ উপস্থাপনা। একে অনেক সময় SDLC (Software Development Life Cycle) Models ও বলা হয়ে। এই সকল মডেল গুলো High লেভেল এর হয়ে থাকে। এখানে শুধুমাত্র activity গুলো তুলে ধরা হয়। এই activity এর উপর নির্ভর বিভিন্ন কর্মপদ্ধতি চিন্তা করা হয়।

কিছু সাধারন মডেলঃ

১। The Waterfall Model

২। Incremental Development

৩। Integration and Configuration

এইগুলো সাধারন কয়েকটা মডেল। যেহেতু Universal কোন মডেল নেই সেহেতু কোন প্রতিষ্ঠান বা কম্পানি চাইলে তাদের মত এই সব মডেল ডিজাইন করে ব্যবহার করতে পারে। তবে এখানে তাদের মূল উদ্দেশ্য হবে সময়ের মধ্যে দ্রুত Software প্রস্তুত করে Delivery করা। তার চাইলে ২ বা ততোধিক মডেল একসাথে মডেল তৈরি করতে পারে। এতা সম্পূর্ণ নির্ভর করছে তাদের System এর ধরন এবং Developer দের দক্ষতার উপর।

The Waterfall Model

The Waterfall model মডেল হলো কয়েকটি ধাপ নিয়ে গঠিত হয়। এখানে মূলত একটা ধাপের কাজ শেষ হলে পরবর্তী ধাপের কাজ শুরু হয় । তবে প্রতিটি ধাপের কাজ গুলো Document এর মাধ্যমে সংরক্ষন করা হয়। এটা একট plan-driven মডেল। এখানে Software Development শুরু করার আগেই সব কিছু প্লান করা হয়।

The Waterfall model এর কিছু ধাপ যেগুলো মৌলিক Software Development এর কার্যক্রমঃ

১। Requirements Analysis and Definition: এখানে সিস্টেম এর সক্ষমতা , সীমাবদ্ধতা ইত্যাদি বিষয় নিয়ে আলাপ আলোচনা হয়।

২। System and Software Design: এই ধাপে সিস্টেম এর জন্য হার্ডওয়্যার ও সফটওয়্যার এর জন্য একটা Architecture তৈরি করা হয়।

৩। Implementation and Unit Testing: এই ধাপে এসে মুলত প্রোগ্রামিং করা হয় এবং প্রতিটি ছোট কম্পোনেন্টকে টেস্ট করা হয়।

৪। Integration and System testing: এই ধাপে সকল ছোট ছোট Unit কে একত্র করে , সম্পর্ণ সিস্টেমটাকে টেস্ট করা হয়। এই টেস্টিং সফল হলে সফটওয়্যার ডেলিভারি করা জন্য প্রস্তুত।

৫। Operation and Maintenance: এই ধাপ তো হল সব থেকে লম্বা ধাপ। সিস্টেম ডেলিভারি করা হয়ে গেছে এবং প্রাক্টিক্যালি ব্যবহার করা হচ্ছে। এখন অনেক Bugs , error থাকতে যেগুলো টেস্টিং এর সময় ধরা পড়ে নি। এই ধাপে এসে সেগুলো ঠিক করা হয়। এছাড়াও সিস্টেম সিকিউরিটি , পারফরমেন্স উন্নত করা চেষ্টা করা হয়।

এই বিষয় গুলো পরবর্তীতে আলোচনা হবে।

Problems of Waterfall Model

Waterfall model হার্ডওয়্যার ডেভোলপ করা জন্য ঠিক আছে। কারন এই পন্য একটা প্রস্তুত হয়ে গেল তা আর পরিবর্তন করা যায় না। এর জন্য সবকিছু ভালো মত ধাপে ধাপে কার্য সম্পাদন করা হয়। যেকোন একটা ধাপে যদি ভুল হয় , সেটা সম্পূর্ণ প্রডাক্টকে নষ্ট করে দিতে পারে।

তবে Software এর ক্ষেত্রে পরবর্তীতে পরিবর্তন করা সম্ভব। Software প্রতিনিয়তই পরিবর্তন করার প্রয়োজন হতে পারে। The Waterfall model-এ কোন ধাপে যদি সমস্যা হয় তাহলে সেটা আবার পূনরায় প্রথম ধাপ থেকে শুরু করা হয়। Software develop করার ক্ষেত্রে বিভিন্ন ধাপে প্রবলেম হবে। সেক্ষেত্রে প্রথম শুরু করা অনেক সময় লেগে যাবে। তার বড় বিষয় হচ্ছে এখানে একটা ঝুকি থেকে যায়। ঝুকি টা হচ্ছে, যদি Software ডেভেলোপ শেষ হওয়ার পরে সেটা কারও পছন্দ না হয়। User যদি গ্রহন না করে। তখন এই সময় টুকু নষ্ট হয়ে যাবে। তাছাড়া এই মডেলে কাজ করলে একটা ফিচার রিলিজ করতেও অনেক সময় লেগে যায়।

Applications of Waterfall model

১। Embedded Systems: Embedded Systems একবার ইমপ্লিমেন্ট করা হয়ে গেলে তা আর পরিবর্তন করার সুযোগ থাকে না। এজন্য প্রতিটা ধাপ খুব ভালো ভাবে রিসার্চ করে তারপর পার করা হয়। এর জন এই ধরনের সিস্টেম তৈরি করতে সময় ও লেগে যায়।

২। Critical System: critical system গুলোতে প্রতেক টি ডাটা প্রয়োজন এজন্য প্রতিটি ধাপ আস্তে আস্তে ভালো ভাবে পার করা প্রয়োজন, যাতে ভবিষ্যতে কোন অনাকাঙ্ক্ষিত ঘটনা না ঘটে।

Ending

বর্তমানে Waterfall model একবারে যৌক্তিক না , কারন সিস্টেম এর Requirements প্রতি নিয়ত পরিবর্তন হয়। এখন যদি Waterfall model ফলো করে সিস্টেম রেডি করা হয় তাহলে অনেক সময় লেগে যাবে। দিন যার ভ্যালু অনেক কমে যেতেও পারে। অতিতে এমন অনেক কেস আছে। দেখা গেছে, একজনের কাছে একটা খুব ভালো আইডিয়া আছে। কিন্তু সেই আইডিয়া সম্পর্ণ রুপ দিতে গেলে অনেক সময় লেগে যাবে। তার আইডিয়া ছিল সম্পূর্ণ রেডি করে তারপর ময়দানে নামবে। কিন্তু তার সেইম আইডিয়া অনেক পরে এসে অল্প অল্প করে ডেভেলোপ করে তারা আজ ধরা ছোয়ার বাইরে চলে গেছে।

So The Waterfall model is not suitable for current software development.

Incremental Development

Incremental Development -এ প্রথমে একটা প্রাথমিক প্রোডাক্ট বা software তৈরি করা হয় এবং পরবর্তীতের user এবং অন্যান্যদের মতামতের উপর ভিত্তি করে আস্তে আস্তে ডেভেলোপ হয়। এখানে ভার্সন ম্যানেজমেন্ট করে নতুন নতুন ফিচার যুক্ত করা হয়। নতুন ফিচার এর জন্য নতুন একটা ভার্সন রিলিজ দেওয়া হয়ে থাকে।

বর্তমানে এই ধরনের মডেল খুবই জন্যপ্রিয়। এখানে সকল ফিচার আস্তে আস্তে ধাপে ধাপে ডেভোলোপ করা করা হয়। প্রতিনিয়ত সব কিছু পরিবর্তন হচ্ছে। সাথে মানুষের চাহিদা , প্রয়োজন , দৈনন্দিন জীবন ব্যবস্থা সব কিছুই পরিবর্তন হচ্ছে। এখন একটি software কে যদি সার্ভাইভ করতে হয় তাহলে এই সকল বিষয় গুলো বিবেচনা করেই আগাতে হবে। এখানে যেহেতু পর্যায়ক্রমে সব কিছু ডেভেলোপ হয়, সেহেতু নতুন নতুন ফিচার নিয়ে ডেভোলোপ করা খুবই সহজ হয়। আবার পুরাতন ফিচার যেগুলোর আর দরকার নেই সেগুলোও বাদ দেওয়া যায়। নতুনত্বের সাথে তাল মিলিয়ে চলা যায়।

Incremental Development এর ক্ষেত্রে ভার্সন ম্যানেজ করা হয়। প্রথমে একটা মিনিমাল software রিলিজ দেওয়া হয়। এই ভার্সন গুলো user ব্যবহার করতে পারে। এর পরে নতুন নতুন ফিচার প্লান করা হয়। সেগুলো যুক্ত করা হয়ে গেলে সব কিছু টেস্ট করার পর নতুন একটা ভার্সন রিলিজ করা হয়। নতুন ফিচার, বাগ ফিক্সিং কোড পরিবর্তন করলেই সেটা নতুন ভার্সনে নিয়ে যাওয়া হয়। তবে প্রতিটি নতুন ভার্সন user এর কাছে expose না করলেও চলে। একবার অনেক গুলো ভার্সন রিলিজ দেওয়া যেতে । এটা নির্ভর করছে কম্পানি বা প্রতিষ্ঠানের উপর। এই ভার্সন ম্যানেজমেন্ট এর জন্য প্রসেস টা Waterfall Model এর তুলনায় অনেক সহজ করে দেই। তাছাড়া এই ভার্সনের মাধ্যমে বেটা টেস্টিং করা যায়।

Advantages

Incremental Development এ Waterfall model এর তুলনায় ৩ টা প্রধান সুবিধা রয়েছে।

১। খরচ কমে যায়ঃ Waterfall Model এ প্রতিটি ধাপে বিস্তারিত ভাবে সব কিছু ডকুমেন্ট করা হয়। এখন যদি কোন requirements এর পরিবর্তন হয় তাহলে তার খরচ Incremental Development model অনেক কম।

২। কাস্টমার ফিডব্যাকঃ Waterfall model-এ সম্পূর্ণ software তৈরি না হলে কাস্টমার থেকে ফিডব্যাক নেওয়া সম্ভব হয় না। আর ডকুমেন্টশন কাস্টমার পড়তে খুব বেশি স্বাছন্দ বোধ করে না। এই মডেল যেহেতু ধাপে ধাপে develop করা হয়, সেহেতু customer খুব সহজে তার ফিডব্যাক দিতে পারে।

৩। Early Delivery and Deployment : এই প্রসেস এ কাস্টমার দ্রুত একটা প্রোডাক্ট পেয়ে যায়। যদিও এটা সম্পূর্ন ফাংশনালিটি যুক্ত থাকে না। কিন্তু তা ব্যবহার এর উপযুক্ত হয়ে যায়। waterfall model এর তুলনায় এখানে সময় অনেক কম লাগে

Problems

Incremental Development এর সুবিধা থাকলেও ম্যানেজমেন্ট এর দিক থেকে চিন্তা করলে দুইটি অসুবিধা আছে।

১। এর মডেলে প্রসেস দেখা যায় না। এই জন্য ম্যানেজার কে প্রতিনিয়ত ডিলিভারি গুলো দেখতে হয় এবং এই অনুযায়ী প্রগ্রেস তৈরি করতে হয়। এ ক্ষেত্রে যদি সফটওয়্যার যদি খুবই দ্রুত প্রয়োজন হয় এবং প্রতিটি ভার্সনে ডকুমেন্টেশন করা লাগে তাহলে খরচ অনেক বেড়ে যায়।

২। সিস্টেম স্ট্রাকচার নষ্ট বা খারাপ হওয়ার সম্ভাবনা থাকে যখন নতুন ফিচার যুক্ত করা হয়। এখানে যেহেতু অনেক জন একসাথে কাজ করে সেক্ষেত্রে নতুন কিছু যুক্ত করতে গেলে সেখানে একটু সমস্যার সৃষ্টি হতে পারে। তাছাড়া সবার দক্ষতা সমান না। এই জন্য অনেক সময় সিস্টেম এর স্ট্রাকচার নিচের দিকে নেমে যায়। অনেক সময় নষ্ট ও হয়ে যায়।

এই সমস্যা গুলো সবথেকে বেশি দেখা দেয় বড় , জটিল এবং লম্বা সময় এর সিস্টেমে যেখানে এই সব বড় সিস্টেমের ছোট ছোট অংশ বিভিন্ন টিম কাজ করে । এই ধরনের সিস্টেম গুলোতে এই সমস্যাগুলো সব থেকে বেশি দেখা দেয়। মূলত এই ধরনের সিস্টেম এ কাজ করার জন্য আগেই থেকেই আর্কিটেকচার, ডকুমেন্টশন এবং আনুসাংঙ্গিক সব কিছুই আগে থেকে ঠিক ঠাক করে রাখতে হয়।

Integration and Configuration

Software Engineer এর দের মধ্যে একটা প্রিন্সিপাল খুব পরিচিত DRY, Don’t Repeat Yourself এই প্রিন্সিপাল মুল নীতি একই রকম কম্পোনেন্ট কে বার বার নতুন করে না বানিয়ে , সেটাকে বার বার ব্যবহার করা। বর্তমানে এই জিনিস টা খুবই জনপ্রিয়তা। সবাই এই সিম্পল প্রিন্সিপাল ফলো করার চেষ্টা করে। এই ভাবে একই জিনিস বার বার ব্যবহার করার হলো Re-use oriented পদ্ধতি।

Re-use oriented পদ্ধতি টা মুলত একটা পুনরায় ব্যবহার করা যাবে এমন সফটওয়্যার কম্পোনেন্ট (একাধিক হতে পারে) এবং একটা ফ্রেমওয়ার্ক যার দ্বারা এসব কম্পোনেন্ট কে একসাথে ব্যবহার করা যাবে তার উপর নির্ভর করে ।

একটা উদাহরনের মাধ্যমে বিষয়টা সহজ করা যাক।

আমাদের কাছে একটা Department Manage করার জন্য একটা সফটওয়্যার আছে। এখন এই সফটওয়্যার টা আমরা পুনরায় ব্যবহার করতে পারি (COTS)। এই সফটওয়্যার-এ নিচের এই ফিচার গুলো আছে,

Interactive Dashboard
Course Management
Students , Teacher and Staff Management
Online Exam
Online Quiz and Assignment
Calendar with Scheduling Facility
Report Generation
Setting and Preference Management

এখন সিভিল ডিপার্ট্মেন্ট থেকে বলা হলো ঠিক এইধরনের একটা সফটওয়্যার তৈরি করার জন্য। সেই সফটওয়্যার নিচের ফিচার গুলো থাকতে হবে,

Interactive Dashboard
Course Management
Students , Teacher and Staff Management
Calendar with Scheduling Facility
Attendance
Instrument Management
Report Generation
Setting and Preference Management

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

Software Components

তিন ধরনের সফটওয়্যার কম্পোনেন্ট রয়েছে।

Stand-alone applications: এই ধরনের অ্যাপ্লিকেশান গুলো সাধারনভাবে ব্যবহার করার জন্য ব্যবহৃত হয়। এখানে একসাথে প্রয়োজনীয় অপ্রয়োজনীয় অনেকগুলো ফিচার থাকে।
Collection of Objects: এই ধরনের সফটওয়্যার কম্পোনেন্টস গুলো বেশিরভাগ ক্ষেত্রেই প্যাকেজ হয়, যেটা আগে থেকে বিদ্যমান বিভিন্ন সফটওয়্যার এর সাথে কাজ করে থাকে।
Web services: এই বিভিন্ন ধরনের সার্ভিস যে ওয়েব এর মাধ্যমে অ্যাক্সেস করা যায়। যেমন Weather Api

Process Stages

নিচের এই স্টেপ গুলো উপরে ইতোমধ্যেই অনুসরণ করা হয়ে গেছে।

Requirements Specifications: এই ধাপে একটা Requirements এর তালিকা আসে । সাধারনভাবে কি কি লাগবে তার একটা বিবরন দেওয়া থাকে।
Software Discovery and Evaluation: এই ধাপে এসে খোজা হয় যে Requirements এর সাথে মেলে এমন কোন সফটওয়্যার আছে কিনা এবং এই সফটওয়্যার এর কি ফিচার আছে সেগুলোকে মূল্যায়ন করা হয়।
Requirements refinement: আগের ধাপে যদি কোন সফটওয়্যার খুজে পাওয়া যায় তাহলে সেটা ব্যবহার করতে হবে এবং এই ধাপে সেটা স্বাভাবিক ভাবেই Requirements এর পরিবির্তন করতে হবে।
Application System Configuration: এখন যদি Requirements অনুযায়ী একই ধরনের কোন সফটওয়্যার থাকে থাকলে এই ধাপে এসে কনফিগারেশন করা এবং সফটওয়্যার ডেলিভারি দেওয়া
Components Adaption and Integrations: যে সফটওয়্যার কম্পোনেন্টগুলো পাওয়া গেছে সেগুলো ব্যবহার এর জন্য প্রস্তুত করা এবং নতুন কম্পোনেন্টস গুলো তৈরি করা। সর্বশেষে এই দুইধরনের কম্পোনেন্টস গুলো একসাথে করা হয় এই ধাপে।

উপরে এই ধাপগুলোই কিন্তু অনুসরণ করা হয়েছিল।

Advantages

Development time কমে যায়
দ্রুত সফটওয়্যার ডেলিভারি করা যায়
সফটওয়্যার গুনগত মান ঠিক থাকে এবং বৃদ্ধি পায়।
ভবিষ্যতে ব্যবহার করা যায় এবং নতুন ফিচার সহজে যুক্ত করা যায়।

Disadvantages

এই ধরনের সিস্টেম কনফিগার করা একটু জটিল
Maintenance করা কষ্টদায়ক
নিরাপত্তা ঝুকি থাকে
অনেক কিছু পরিবর্তন করা যায় না

Ending

পরবর্তীতে integration and configuration model নিয়ে বিস্তারিত আলোচনা হবে।

Process Activities

সফটওয়্যার প্রসেস হল পর্যায়ক্রমে থাকা টেকনিক্যাল এবং ম্যানেজমেন্ট সহ জিজাইন, টেস্টিং ইত্যাদি বিষয়ের সুসংগঠিত কার্যাকলাপ। শুরু থেকে শুরু করে শেষ পর্যন্ত সব কিছুই উল্লেখ থাকে। বর্তমানে এসব কাজ গুলো সহজ করার জন্য অনেক টুল বিদ্যমান রয়েছে। এসব টুল ব্যবহার করা যায়।

তবে এসব activities এর মধ্যে ৪ টি মৌলিক activities বিদ্যমান।

Software Specifications
Software Design and Implementation
Software Validation
Software Evolution

Software Specifications

Software Specifications অথবা requirements engineering হল একটা প্রসেস, যা সফটওয়্যার এর প্রয়জনীয়তা সংগ্রহ , বিশ্লেষন, ডকুমেন্টেশন এবং বিভিন্ন প্রতিবন্ধকতা খুজে বের করা। এটা সফটওয়্যার ইঞ্জিনিয়ারিং এর প্রথম ধাপ। এটা দেখে মনে হবে খুবই সহজ জিনিস। কিন্তু এই ধাপের উপরে বাকি সব কিছু নির্ভর করে। এখানে একটু ত্রুটি হলে পরবর্তীতে সিস্টেম ডিজাইন করতে অনেক সমস্যার সম্মুখীন হতে হবে। এসে সমস্যা এড়াতেই প্রথম মার্কেট রিসার্স করা হয়, আদেও এই সফটওয়্যার কাজে দিবে কিনা। আদেও শ্রম এবং টাকা খরচ করে এই সফটওয়্যার কতটা যৌক্তিক তাও বোঝার চেষ্টা করা হয়।

Requirement Engineering-এ তিনটি প্রধান activities রয়েছে।

Requirement Elicitation and analysis: এই ধাপে মুলত সিস্টেম সম্পর্কে বিভিন্ন তথ্য সংগ্রহ করা হয়। এক্ষেত্রে বিদ্যমান কোন সিস্টেম ,ব্যবহার কারীর ফিডব্যাক ইত্যাদি বিষয়-এ তথ্য সংগ্রহ করে তা বিশ্লেষন করা হয়।
Requirement Specification: আগের ধাপের সংগ্রহ করা তথ্যের উপর ভিত্তি করে , এই ধাপে এসে কি কি জিনিস প্রয়োজন সেগুলোর ডকুমেন্ট করা হয়। এখানে User requirements এবং System requirements এই দুই ধরনের requirements এর ডকুমেন্ট থাকতে পারে।
Requirements Validation: এই ধাপে এসে যে requirements এর ডকুমেন্ট তৈরি করা হয়েছে তা বাস্তবিক কিনা, আদেও এই Consistency এর থাকবে কিনা, সম্পূর্ণ করা যাবে কিনা ইত্যাদি চেক করা করা হয়। এই ধাপে অনেক ভুল দেখা দিতে পারে। দেওয়াটায় স্বাভাবিক। এই ভুল গুলো সংশোধন করে পুনরায় এই ধাপের কাজ করা।

Software Design and Implementation

Software Design হলো সফটওয়্যার এর আর্কিটেকচার, ডাটা মডেল এবং অন্যনা কম্পোনেন্ট এর সাথে সিস্টেম কিভাবে ইন্টারফেস করবে তার বিস্তারিত বর্ণনা।

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

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

সিস্টেম এর প্রয়োজনীয়তার উপর নির্ভর করে এই সফটওয়্যার ডিজাইন এর প্রসেস ভিন্ন ভিন্ন হতে পারে। উদাহরন হিসবে একটা রিয়েলটাইম কমিউনিকেশন সফটওয়্যার এর জন্য ডাটাবেজের কোন প্রয়োজন নেই। এখানে ডাটাবেজ-এ কোন তথ্যই সেইভ করার প্রয়োজন হয় না।

Architectural design: এখানে সিস্টেম আর্কিটেকচার নির্ধারন করা হয়। কম্পোনেন্ট গুলো কিভাবে থাকবে এবং তাদের মধ্যে ইন্টাফেস কিভাবে হবে এই ধরনের কাজ গুলো নির্ধারন করা হয়।
Database design: সিস্টেম আছে মানেই ডাটা অস্তিত্ব আছে। এখন ডাটা গুলো কিভাবে সংরক্ষন করা হবে , তা এই portion-এ এসে নির্ধারন করা হয়।
Interface design: এখানে মুলত সিস্টেম কম্পোনেন্টগুলো ইন্টারফেস নির্ধারন করা হয়ে থাকে।
Component selection and design: এই ধাপে এসে, প্রয়োজনীয় বিভিন্ন কম্পোনেন্ট খোজার চেষ্টা করা হয়। যদি কম্পোনেন্ট বিদ্যমান থাকে তাহলে তা ব্যবহারের জন্য নির্ধারন করা হয়। আর যদি না থাকে তাহলে ডিজাইনের কাজ কাজ করা হয়। এখানে কম্পোনেন্ট এর জন্য তথ্য দিয়ে প্রোগ্রামার এর জন্য রেখে দেওয়া হয়। এক্ষেত্রে UML (Unified Modeling Language) এর ব্যবহার হয়ে থাকে।

সবগুলো activities এর সম্বনয়ে একটা ডিজাইন আউটপুট জেনারেট হয়। এটাকে ব্যবহার করে সফটওয়্যার এর কাজ সামনের দিকে অগ্রসর হয়।

Software Validation

Software Validation অথবা সাধারন ভাবে verification and validation এর উদ্দেশ্য হল software specification মেনে চলা এবং customer expectation ফুলফিল করা। এক্ষেত্রে software specification এর উল্লেখিত ফিচারগুলো চাহিদা মোতাবেক কাজ করছে কিনা তা নিশ্চিত করা হয় । এজন্য বিভিন্ন ধরনের টেস্ট করা হয়ে থাকে। এসব টেস্ট গুলো প্রথমে থেকে শেষ পর্যন্ত সকল ধাপে করা যেতে পারে।

প্রাথমিক ভাবে সব টেস্ট গুলো সিমুলেটেড ডাটা দিয়ে করা হয়ে থাকে। পরবর্তীতে বেটা টেস্টিং এর জন্য দেওয়া হয়। তবে এসব টেস্ট গুলো বড় সিস্টেমের সিংগেল ইউনিট হিসেবে একবারে টেস্ট না করে, কম্পোনেন্ট আকারে টেস্ট করা শ্রেয়।

Component testing: এই ধাপে প্রতিটি কম্পোনেন্টকে আলাদা আলাদা ভাবে টেস্ট করা হয়। এসব কম্পোনেন্ট গুলো ছোট ফাংশন ক্লাস ইত্যাদি হতে পারে। তবে এসব ছোট অনেকগুলো কম্পোনেন্ট একসাথে একটা কম্পোনেন্ট হতে পারে।
System testing: এই ধাপে পুরা সিস্টেম কে এক সাথে টেস্ট করা হয়। এখানে সব কিছু হাইলেভেল এ থাকে। সিস্টেমে requirement অনুযায়ী ইনপুটের বিপরীতে সঠিক আউটপুট আসছে কিনা তা টেস্ট করা হয়। এখানে internal coding বা এর implementation নিয়ে কোন কিছু করা হয় না। ইনপুটের বিপরীতে সঠিক আউটপুট নিশ্চিত করে।
Customer testing: Customer testing অনেক সময় বেটা টেস্টিংও বলা হয়ে থাকে। এই টেস্টিং কিছু সম্ভাব্য ব্যবহার কারীকে সফটওয়্যার এর আক্সেস দেওয়া হয় এবং তারা ব্যবহার করে তাদের ফিডব্যাক দিয়ে থাকে। বেশিরভাগ ক্ষেত্রেই সিমুলেটেড ডাটা দিয়ে টেস্ট করা কম্পোনেন্ট বা সিস্টেম, বাস্তবিক ভাবে ব্যবহারের ক্ষেত্রে অনেক ইসু দেখা যেতে পারে । এজন্য রিয়েল ডাটা দ্বারা টেস্টিং করা প্রয়োজন।

এসব স্টেজে বিভিন্ন ধরনের বাগ দেখা দিতে পারে। এসব বাগ গুলো ডিবাগ করা দরকার। এর জন্য আলাদা স্টেজ এর প্রয়োজন হতে পারে।

কম্পোনেন্ট টেস্টিং এর ক্ষেত্রে বেশিরভাগ সময় প্রোগ্রামার নিজেই টেস্ট কেস গুলো লিখে। কারন সেই কম্পোনেন্ট সম্পর্কে সব থেকে বেশি জ্ঞান রাখে। Test Driven Development এর ক্ষেত্রে প্রথমে টেস্ট কেস গুলো লেখা হয় এবং পরবর্তীতে টা ইমপ্লিমেন্ট করা হয়।

Testing in Plan Driven Architecture

PDA -এ কিছু নির্দিষ্ট প্লানের উপর নির্ভর করে সাম্নের দিকে আগ্রসর হয়। এখানে টেস্টিং এর জন্য একটা টিম থাকে যেখানে তার শুধু টেস্ট নিয়ে কাজ করে। উপরে চিত্রে দেখলেই বোঝা যাবে, এখানে প্রতিটি ধাপে টেস্টিং করা হয়ে থাকে।

Software Evolution

কোন একটা হার্ডওয়্যার প্রোডাক্ট একবারে তৈরি করা হয়ে গেলে সেখানে নতুন কোন পরিবর্তন করতে গেলে অতিরিক্ত মাত্রায় খরচ করতে হয়। কিন্তু সফটওয়্যার এর ক্ষেত্রে সেটা হয় না। সফটওয়্যার এর কোন কিছু পরিবর্তন করতে চাইলে অথবা নতুন ফিচার যুক্ত করতে চাইলে খুব বেশি খরচ করতে হয় না। হার্ডওয়্যার এর তুলনায় অনেক কম। এই জন্য একটা সফটওয়্যার সময়ের সাথে সাথে এর গ্রোথ বৃদ্ধি পায়। প্রাথমিক পর্যায় যা ছিল তার তুলনায় অনেক বেশি ফিচার সমৃদ্ধ হয়ে যায়। এভাবেই সফটওয়্যার evolve হতে থাকে।

Software Evolution কে maintenance এর সাথে তুলনা করা যেতে পারে। maintenance-এ মুলত ডিবাগিং করা হয়ে থাকে। বাগ ফিক্সিং এবং নতুন ফিচারের এর জন্যই সফটওয়্যার evolve হতে থাকে।

Coping with change

একটা বড় সফটওয়্যার প্রোজেক্ট-এ পরিবর্তন অনিবার্য। বিভিন কারনে সফটওয়্যার এর requirements পরিবর্তন হতে পারে। নতুন নতুন টেকনলজি তৈরি হচ্ছে এক্ষেত্রে নতুন পদ্ধতিতে সফটওয়্যার তৈরির করা হচ্ছে। নতুন পরিবর্তন সফটওয়্যার এর খরচ বৃদ্ধি করে কারন যে কাজ করা হয়ে গেছে সে কাজ আবার করতে হবে।

দুইটা পদ্ধতিতে এই খরচ কমানো সম্ভব।

Change anticipation: এই পদ্ধতিতে সফটওয়্যার এর ভবিষ্যতের কথা চিন্তা ভাবনা করা হয়। একটা সফটওয়্যার-এ এমন অনেক ফিচার থাকতে পারে, যে গুলো নিকট ভবিষ্যতে অযৌক্তিক হয়ে যেতে পারে। এই ধরনের সমস্যা এড়াতে, প্রথমে একটা প্রোটোটাইপ তৈরি করা যেতে পারে, যেখানে কিছু প্রধান প্রধান ফিচার থাকবে। এবার কাষ্টমার এটা টেস্টিং করার পর তার requirements পরিবর্তন করতে পারেন। এক্ষেত্রে প্রডাকশন খরচ কমে যাবে।
Change tolerance: সফটওয়্যার কে এমন ডিজাইন করতে হবে যেন খুব সহজেই এখানে পরিবর্তন করা যায়। এক্ষেত্রে Incremental Development পদ্ধতি অনুসরন করা হয়। নতুন পরিবর্তন বা আপডেট একটা increment হিসেবে অ্যাড করে দিলেই সফটওয়্যার প্রস্তুত।

এই পরিবর্তন কে মোকাবেলা অনেক ভাবেই করা যেতে পারে তবে এখানে ২ টা পদ্ধতি নিয়ে আলোচনা করা হবে।

System Prototyping: এখানে সম্পূর্ন সিস্টেম তৈরি করার পূর্বে মুল ফিচারগুলো নিয়ে অল্প সময়ের মধ্যে একটা সিস্টেম তৈরি করা এবং কাস্টমার ফিডব্যাক প্রদান করে। এখানে requirements পরিবর্তন হতে পারে।
Incremental delivery: এই পদ্ধতিতে সিস্টেম কে এমন ভাবে ডিজাইন করা হয় যাতে, খুব সহজেই পরিবর্তন বা পরিবর্ধন করা যায়। সফটওয়্যার তৈরি হওয়ার পর কোন পরিবর্তন আসলে সেখানে একটা নতুন একটা increment করলেই হয়ে যাবে।

Prototyping

Prototype হলো একটা সফটওয়্যার এর প্রাথমিক ভার্সন , যা ব্যবহার করা হয় সফটওয়্যারকে উপস্থাপন করতে, বিভিন্ন ডিজাইন try করতে এবং কোন সমস্যা থাকলে সেগুলো খুজে বের করে তার সম্ভাব্য সলুশন বের করার কাজে।

Prototype development এর জন্য development চলমান হতে হবে এই জন্য প্রতিনিয়ত development এর কাজ করতে হবে। নতুন নতুন ফিচার যুক্ত করতে হবে (অবশ্যই requirements অনুযায়ী প্রধান ফিচার গুলো)। এই Prototype একজন সম্ভাব্য ইউজারকে তার কাজে সাহয্য করবে। এখন তিনি যখন ব্যবহার করবেন তখন তার মাধায় নতুন নতুন requirement এর সৃষ্টি হতে পারে, যেগুলো অ্যাড করা প্রয়োজন। ব্যবহার করা ক্ষেত্রে অনেক এরর দেখা দিতে পারে যেটা requirement এ থেকে বাদ পড়ে গেছিলো।

একটা Prototype , প্রস্তাবিত ডিজাইন এর ফিসিবিলিটি টেস্টিং এর জন্য ব্যবহার করা যেতে পারে। উদারহর হিসবে, একটা সিস্টেম একসাথে একই সময়ে কত গুলো ইউজার এর request এর হ্যান্ডেল করতে সক্ষম তা চেক করা যেতে পারে।

Prototype Development

Prototype ডিজাইন করা শুরুতে এর উদ্দেশ্য ঠিক করতে হবে। এই উদ্দেশ্য হতে পারে , সফটওয়্যার এর ইন্টারফেস ডিজাইন, বিভিন্ন ভ্যালিডেশন চেক অথবফিসিবিলিটি টেস্টিং ইত্যাদি হতে পারে। একটা Prototype সকল উদ্দেশ্য পূরন করতে সক্ষম নয়। এই জন্য অনেক সময় ইউজার ভুল বুঝে থাকে। আসলে

Prototype এর উদ্দেশ্যই হলো মুল ফিচার গুলো নিয়ে একটা সিস্টেম বানানো। এখানে non-functional (response time, memory utilization etc) বিষয়গুলো ইচ্ছাকৃত ভাবে ইগনোর করা হয়ে থাকে। এখানে অনেক সময় এরর গুলো সঠিক হ্যান্ডেল নাও করা হতে পারে। এই সব কারনে সিস্টেম এর নির্ভরযোগ্যতা এবং মান কমে যেতে পারে।

সবশেষে Prototype তৈরি করা হয়ে গেলে , ইউজার এর ট্রেনিং এবং Prototype এর উদ্দেশ্যগুলো পূরন করার জন্য এই Prototype কে evaluate করা হয়। এক্ষেত্রে এসব ইউজারদের একটু সময় লেগে যায়। নতুন সিস্টেম ব্যবহার করতে সময় লাগাটায় স্বাভাবিক। তবে একবার সিস্টেম ব্যবহার এ comfortable হয়ে গেলে তখন তারা নতুন নতুন requirement আবিষ্কার করতে পারে।

তবে এখানে সমস্যা আছে, এই সব ইউজার ফাইনাল সিস্টেম কে যেভাবে ব্যবহার করতে চাই, সেভাবে এই Prototype কে সেইভাবে ব্যবহার নাও করতে পারে। এর কারন হতে পারে, slow response, slow processing, lots of errors ইত্যাদি।

Incremental Delivery

Incremental Delivery হলো এমন একটা পদ্ধতি যেখানে requirements গুলোকে অনেক গুলো ভাগে ভাগ করা হয়ে থাকে। এর ভিতরে কিছু ডেভোলোপ করা ভাগগুলো কাস্টমারের কাছে ডেলিভারি করা হয়েছে এবং তার মেশিনে ডেপলয় করা হয়েছে। এই ভাগ কিভাবে করা হবে, কোনটা আগে কোনটা পরে সেটা কাস্টমার ঠিক করে দেন। সবোর্চ প্রাইরিটির কাজগুলো আগে করা হয়।

যখন এসব কাজ গুলো হয়ে যায় , তখন প্রথম increment, ডেভোলোপ করা হয়ে গেছে তখন এই সিস্টেম ব্যবহার করা জন্য প্রস্তু হয়ে গেছে। তবে ডেভোলোপ করার সময় অনেক নতুন নতুন requirement এর দেখা দিতে পারে। এসব requirement গুলো প্রাইরিটি দিয়ে ডেভোলোপ করা হয়ে থাকে।

এবার সিস্টেম কে কাস্টমারে কম্পিউটারে রান করা জন্য প্রস্তুত। এখন কাস্টমার ব্যবহার করে দেখবে তার চাহিদা মোতাবেক কাজ হচ্ছে কিনা অথবা নতুন কোন ফিচার যুক্ত করা লাগবে কিনা। এখানে কাস্টমার সম্পূর্ণ সিস্টেমকে মূল্যায়ন করবেন এবং তিনি ফিডব্যাক দিবেন।

Advantages

Incremental Delivery এর কিছু সুবিধা আছে। যেমনঃ

প্রথম Increment হওয়ার পরপর কাস্টমার সফটওয়্যার ব্যবহার করতে পারে এবং তার মতামত দিতে পারে। এটা Prototype এর সম্পূর্ণ বিপরীত। এই Increment গুলো মূলত সিস্টেমের অংশ। একবার শুরু থেকে শুরু করার প্রয়োজন হয় না।
কাস্টমার কে সিস্টেম সম্পূর্ণ রেডি হওয়া পর্যন্ত অপেক্ষা করার প্রয়োজন হয় না। প্রথম Increment-এ প্রধান প্রধান ফিচার গুলো থাকে। এজন্য তৎক্ষণাৎ এই সিস্টেম ব্যবহার করা যায়।
যেহেতে সবোর্চ প্রাইরিটি সার্ভিস গুলো আগে আগেই ডেলিভারি করা হয়। এইজন্য এইসমস্ত সার্ভিস গুলো সব থেকে বেশি টেস্ট করা হয়ে থাকে। এক্ষেত্রে এরর বা বাগ এর পরিমান তুলনা মূলক ভাবে অনেক কমে যায়। অনেক ক্ষেত্রে থাকেই না।

Disadvantages

Incremental Delivery এর কিছু অসুবিধা রয়েছে। যেমনঃ

এই ধরনের পদ্ধতি নতুন সিস্টেম এর জন্য সব থেকে উপযুক্ত। যখন কোন বিদ্যামান সিস্টেমকে নতুন সিস্টেম দ্বারা replace করা জন্য এই পদ্ধতি ব্যবহৃত হয় তখন সমস্যার সৃষ্টি হয়। বিদ্যামান সিস্টেম অনেক ইউজার থাকে যার অনেকগুলো ফিচার ব্যবহার করে অভ্যস্ত। এখন হটাত করে যদি এসব ফিচার না থাকে অথবা ইউজার আক্সেস করতে না পারে তখন এসব ইউজার উক্ত সিস্টেম ব্যবহার করা বন্ধ করে দিতে পারে।
বেশির সিস্টেমেই কিছু বেসিক কিছু ফিচার থাকে যেগুলো প্রায় সব জায়গায় ব্যবহার করা হয়ে থাকে। এখন এই পদ্ধতিতে অনেক ডিটেলস এ থাকে না। সেক্ষেত্রে এই বেসিক ফিচার গুলো খুজে বের করা কষ্টকর হতে পারে। আবার অনেক ক্ষেত্রে একই কোড বার বার লেখার প্রয়োজন হতে পারে।
এখানে যেহেতু প্রতিনিয়তই ডেলিভারি করা হয়ে থাকে এবং এসব ডেলিভারির ফিডব্যাক গ্রহন করে সেখানে কাজ করা হয়। সেহেতু এখানে নো নির্দিষ্ট requirement থাকে না। এসব ক্ষেত্রে কাস্টমার এবং কম্পানির এর মধ্যে চুক্তি সংক্রান্ত বিভিন্ন সমস্যার সৃষ্টি হয়।

Ending

Incremental Delivery পদ্ধতি , বড় এবং জটিল সিস্টেমের জন্য সেরা পদ্ধতি নয়। মুলত এসব বড় সিস্টেম অনেক টিম একসাথে কাজ করে থাকে, এক্ষেত্রে অনিইচ্ছাকৃত ভাবে অনেক সমস্যার সৃষ্টি হতে পারে।

চুক্তি করার ক্ষেত্রে, প্রথমে একটা prototype ডিজাইন করে সেটার উপর বেজ করে একটা requirement specification এর ঠিক করে তার উপর বেজ করা চুক্তি সম্পন্ন করা যেতে পারে। নতুন কোন requirement আসলে সেটা পরবর্তী ফেজের জন্য রেখে দেওয়া যেতে পারে এবং পরবর্তী ফেজ একই ভাবে হ্যান্ডেল করা যেতে পারে

Process Improvement

Process Improvement এর মানে বিদ্যমান প্রসেস কে বোঝা এবং এসব প্রসেস পরিবর্তন করা যাতে প্রডাক্ট এর মান, খরচ এবং সময় কমে যায়।

দুই ধরনের পদ্ধতি ব্যবহার করা যেতে পারে।

The process maturity: এই পদ্ধতিতে প্রসেস এবং প্রজেক্ট ম্যানেজমেন্ট এর উপর ফোকাস করা হয় এবং নতুন নতুন ইঞ্জিনিয়ারিং নিয়ম প্রয়োগ করা হয়। এই পদ্ধতির প্রধান উদ্দেশ্য হচ্ছে, প্রোডাক্ট এর মান বাড়ানো।
The agile: এই পদ্ধতি মুলো ফোকাস করে প্রতিনিয়ত ডেভোলেপমেন্ট এর কাজ করে যাওয়া এবং প্রসেস এর অভারহেড কমিয়ে আনা। পরবর্তীতে এ নিয়ে বিস্তারিত আলোচনা হবে।

What is Software Engineering?

Monirul Islam — Sat, 26 Apr 2025 16:19:45 +0000

অনেক দিন আগে (আনুমানিক ২ বছর) আমি নিজের স্কিল বাড়ানোর জন্য একটা সফটওয়্যার (ওয়েব অ্যাপ্লিকেশান) বানায়। মোটামুটি সবকিছু ঠিক ঠাকই ছিল। ওইসময় সব কিছুই যেমন টা চেয়েছিলাম তেমনই টায় হয়েছিল। ওই অবস্থায় কোড যা আছে সব গিটহাবে রেখে দিয়েছিলাম। এখনো আছে।

এখন মনে হল , অনেক দিন তো হল, অ্যাপ তো বানিয়েছি এখন কিছু নতুন ফিচার অ্যাড করা জরুরি। আর প্যাকেজ গুলো আপডেটও করা দরকার। কবে প্যাকেজ গুলো deprecated করে দিবে কে জানে।

গিটহাবে রিপো ওপেন করলাম। ক্লোন করলাম । ক্লোন করার পর , প্রজেক্ট সেটাপ করতে যেয়ে পড়া এক মহাবিপদ।

প্রোজেক্ট সেটআপ এর জন্য ডকুমেন্টেশন নেই। এই প্রজেক্ট কিভাবে রান করতে হবে তার কোন গাইড লাইন নেই। প্রয়োজনীয় বিভিন্ন এনভায়রনমেন্ট ভ্যারিবল কি কি সেটা করা লাগবে তাও নেই।

এই অবস্থায় একটু কষ্ট করে সব কিছু সেটাপ করলাম। এখানে আমার প্রায় ১ঘন্টা সময় চলে গেল। যাক বাবা , ভালো ভাবে প্রজেক্ট রান করা গেছে। খুবই ভালো কথা। এবার তাহলে ফিচার অ্যাড করার কথা চিন্তা করা যায়।

কিন্তু যেই ফিচার অ্যাড করার জন্য কোড ওপেন করলাম। আবার পড়লাম আরেক বিপদে । বিপদটা হচ্ছে কোন ফাইল কোথায় রাখা আছে কিছুই তো জানি না। সব ভুলে গেছি। কি আর করা ফিচার তো অ্যাড করা লাগবে কিছু তো করার নেই। যাই হোক, লেগে পড়লাম ফাইল এক্সপ্লোর করতে। যেহেতু কোড আমি নিজেই করেছিলাম এই জন্য বেশি সময় লাগলো না। বেশি না, এই ৩০ মিনিট মত সময় লেগে গেল। এখন কোড গুলো মোটামুটি মাথায় ধরছে। সহজ কোথায় কোন জিনিস রাখা আছে সেগুলো মাথায় চলে আসছে।

তাহলে সব কিছু রেডি হয়ে গেছে। এখন ফিচার অ্যাড করার পালা। লেগে পড়লাম কাছে। দীর্ঘ ৪ ঘন্টা করার পর একটা ছোট ফিচার অ্যাড করলাম। গিটহাবে পুশ করলাম। সার্ভারে আপলোড করলাম সেখানে আরো ১ ঘন্টা লেগে গেল। সব কিছু ঠিকঠাক। যাক হাফ ছেড়ে বাচলাম।

এখানে অনেক গুলো বিষয় আছে যেগুলো না করার কারনে আমার অযথা প্রায় ৩-৪ ঘন্টা সময় নষ্ট হয়ে গেছে। তবে দুই বিষয় অতীব জরুরি।

প্রথমত, একটা পরিপূর্ণ ডকুমেন্টেশন থাকা প্রয়োজন ছিল।

দ্বিতীয়ত , রিপিটিভ কাজ গুলো অটোমেট করার প্রয়োজন ছিল।

এছাড়া খুটিয়ে দেখলে অনেক প্রবলেম সামনে আসবে।

এখন প্রশ্ন হছে, এত ফাউ তো বকচি, এর সাথে সফটওয়্যার ইঞ্জিনিয়ারিং এর সম্পর্ক কি?

সম্পর্ক আছে, অবশই আছে।

What is software?

সফটওয়্যার ইঞ্জিনিয়ারিং জানার আগে সফটওয়্যার সর্ম্পর্কে জানা তো প্রয়োজন,

সহজভাবে বললে , সফটওয়্যার হল একটু নির্দেশনা বা প্রোগ্রাম যা কম্পিউটারকে নির্দিষ্ট কার্য সম্পাদনের জন্য নির্দেশ করে এবং সমস্যা সমাধান করে থাকে।

সফটওয়্যার মুলত দুই ধরনেরঃ

১। জেনেরিক্স সফটওয়্যারঃ এই ধরনের সফটওয়্যার গুলো মুলত বিভিন্ন কোম্পানি বা প্রতিষ্ঠান ডেভোলোপ করে করে থাকে এবং সাধারন ব্যবহারকারীরা সেগুলো ব্যবহার করে। উদাহরনস্বরুপঃ MS Office, Google Chrome, VS Code ইত্যাদি। এখানে মূল বিষয় হচ্ছে কোম্পানি তাদের মত করে বিভিন্ন ফিচার অ্যাড করে থাকে।

২। কাস্টমাইজড সফটওয়্যারঃ এটা জেনেরিক্স এর সম্পূর্ন উলটা। এই সফটওয়্যার গুলো ব্যবহার কারীর (ক্লায়েন্ট) প্রয়োজন অনুসারে তৈরী করা হয়।

What is Software Engineering?

আমাদের দেশে অনেকেই মনে করে কম্পিউটার সায়েন্স এবং সফটওয়্যার ইঞ্জিনিয়ারিং একই জিনিস। কিন্তু মজার বিষয় হচ্ছে, দুইটা জিনিস একই রকম মনে হলেও এদের মধ্যে রয়েছে আকাশ পাতাল পার্থক্য।

সফটওয়্যার ইঞ্জিনিয়ারিং হলো একটা ইঞ্জিনিয়ারিং ডিসিপ্লিন যেটা একটা সফটওয়্যার তৈরি থেকে শুরু করে এটা ব্যবহারকারীর কাছে পৌছানোর পরে তা মেইনটেইন করা পর্যন্ত সকল বিষয় গুলো কে ডিল করে।

এখানে দুইটা বিষয় উল্লেখ্য

প্রথমত, ইঞ্জিনিয়ারিং ডিসিপ্লিন , ইঞ্জিনিয়াররা বিভিন্ন থিওরি , পদ্ধতির মাধ্যমে কার্য সম্পাদন করে থাকে। তারা চেষ্টা করে সব থেকে সেরা (যেটা ইঞ্জিনিয়ারিং জন্য অধিক গ্রহনযোগ্য) পদ্ধতি টা নির্বাচন করতে। অনেক সময় সমস্যা সমাধানের জন্য নতুন পদ্ধতি এক্সপ্লোর করার প্রয়োজন হয়। তবে তারা বিভিন্ন বাধ্যবাধকতার ভিতরে কাজ করে থাকে। এক্ষেতে তারা বাজেট এবং সময় কে মূল্যায়ন করে থাকে।
দ্বিতীয়ত, সসফটওয়্যার সকল বিষয়, সফটওয়্যার ইঞ্জিনিয়ারিং শুধুমাত্র প্রোগ্রামিং নিয়ে ডিল করে না। প্রজেক্ট ম্যানেজমেন্ট, পদ্ধতি, থিওরিস, বিভিন্ন টুল কিভাবে ব্যবহার করা যায়, প্রোজেক্ট প্লানিং ইত্যাদি বিষয় গুলো ডিল করে।

সফটওয়্যার ইঞ্জিনিয়ারিং মুলত পেশাগত সফটওয়্যার কে সাপোর্ট করার জন্য। কোন ব্যক্তিগত প্রোগ্রার কে সাপোর্ট করার জন্য এটা না। তবে একজন চাইলে সফটওয়্যার ইঞ্জিনিয়ারিং কে নিজের জন্য ব্যবহার করতেই পারেন।

প্রোজেক্ট ম্যানেজমেন্ট এর মধ্যে একটা গুরুত্ব পূর্ণ বিষয় হচ্ছে প্রোজেক্ট এর ডকুমেন্টশন তৈরি করা। আমার ওই প্রজেক্ট কি কোন ডকুমেন্টশন ছিল? ছিল না। যার কারনে অনেকটা সময় লাগিয়ে প্রোজেক্ট সেটআপ করতে হয়েছে। আবার একই কারনে ফোল্ডার এবং ফাইল ওপেন করে ফাইল স্ট্রাকচার বুঝতে হয়েছে। এর পরে কোড পুশ করার পর মানুয়ালি কোড সার্ভারে পুশ করতে হয়েছে।

আমি একজন ব্যক্তি এই কাজ করছি খুব বেশি প্রবলেম হচ্ছে না। কিন্তু একবার ভাবুন তো। এই প্রোজেক্ট এ ১০-১২ জন কাজ করছে। তখন বিষয়টা কেমন হবে। প্রতিবার যদি তাদের প্রজেক্ট সেটাপ করা লাগে তাহলে কতটা সময় নষ্টা হবে। সফটওয়্যার ইঞ্জিনিয়ারিং একটা গুরুত্বপূর্ণ বিষয় হলো বাজেট এবং সময়ের মাধ্যমে গুনমত মান সম্পন্ন সফটওয়্যার ডেলিভারি করা। এখন প্রজেক্টা সেটাপ থেকে শুরু করে ফিচার অ্যাড সহ সার্ভারে পুশ করা পর্যন্ত কতটা টা সময় নষ্ট হচ্ছে একবার চিন্তা করুন।

এখানে সমাধান হচ্ছে, প্রোজেক্ট এর জন্য একটা প্রোপার ডকুমেন্টশন তৈরি করা। রিপিটেটিভ কাজ গুলো অটোমেট করা।

Why software engineering is important?

একটা জিনিস , আমি তো আমার অ্যাপের নতুন ফিচার সার্ভারে পুশ করে দিয়েছে তার খবর নিবেন না? তার খবর খুবই খারাপ , অ্যাপ ক্রাশ করেছে। বিষয়টা একটা খতিয়ে দেখলাম, দেখে যা বুঝলাম তা হচ্ছে , নতুন কোড পুশ করার কারনে সিস্টেম এর রিসোর্স অধিকমাত্রায় ব্যবহৃত হচ্ছে। অন্য ব্যবহারকারীরা রিকুয়েষ্ট করলেই ক্রাশ করছে। বিষয় নিয়ে একটু ঘাটাঘাটি করলাম। করার পরে যা বুঝলাম তাতে আমার মাথায় হাত। আমি কোন রুলস ফলো করিনি, কোন ডিজাইন প্যাটার্ন ব্যবহার করি নি, ব্যাকএন্ডে কুয়েরি অপ্টিমাইজ করিনি, কোন ক্যাশ ব্যবহার করিনি, কোন CDN ব্যবহার করিনি নি। ফ্রন্টএন্ডেও একই অবস্থা।

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

প্রথম, সার্ভারে রিসোর্স এর পরিমান বৃদ্ধি করা
দ্বিতীয়, কোড অপটিমাইজ করা

আমার কি করা উচিত?

এখানে আমি যদি লম্বা সময়ের কথা চিন্তা করি তাহলে ভবিষ্যতে এই প্রোজেক্ট একটা মেইনটেইন করা সম্ভব না। সেজন্য অনেক লোক দরকার হবে। এই দিকে থেকে চিন্তা করলে আমার কোড অপ্টিমাইজ করা টা ভালো অপশন হবে। সব থিওরি ও মেথড ফলো করে যদি সিস্টেম টা ঠিক করতে পারি তাহলে, লম্বা সময়ের জন্য এই রকম মেজর কোন সমস্যা সৃষ্টির সম্ভাবনা কমে যাবে । আবার খরচ ও তুলনামূলক ভাবে কমে আসবে।

সফটওয়্যার ইঞ্জিনিয়ারিং মুলত এই দুইটা কারনের জন্যই গুরুত্বপূর্ণ।

১। বাজেট এবং সময়ের মধ্যে নির্ভরযোগ্য ও বিশ্বাস যোগ্য সিস্টেম তৈরি করতে হয়। এর জন্য সফটওয়্যার ইঞ্জিনিয়ারিংর মেথড গুলো অত্যাবশ্যকীয়।

২। যখন লম্বা সময়ের কথা চিন্তা করে সিস্টেম তৈরি করা হয়, সেক্ষেত্রে সফটওয়্যার ইঞ্জিনিয়ারিং এর মেথড খুব গুলো কাজে লাগে। মুলত সফটওয়্যার ইঞ্জিনিয়ারিং কারনে তুলনা মুলক ভাবে খরচ অনেক কমে যায়।

তবে এখানে মনে রাখার বিষয় হচ্ছে সফটওয়্যার ইঞ্জিনিয়ারিং কোন ব্যক্তিগত কোন প্রোজেক্ট বা প্রোগ্রামিং এর জন্য একদম না।

Fundamental to apply all systems
যেহেতু সফটওয়্যার ইঞ্জিনিয়ারিং কোন ব্যক্তিগত প্রোগ্রামিং এর জন্য না। সেহেতু যারা এর পদ্ধতি গুলো ব্যবহার করবে তাদের বেশির ভাগ হবে টিম, গ্রুপ অথবা কোন প্রতিষ্ঠান।

এখন তারা (এই সব গ্রুপ ) যদি কোন সফটওয়্যার তৈরি করে সেক্ষেত্রে কিছু জিনিস ব্যবহার করতে পারে।

১। তাদের উচিত হবে একটা বোধ্যগম্য এবং সহজে ম্যানেজ করা যায় এমন প্রসেস এর মধ্য দিয়ে সসফটওয়্যার তৈরির কাজ গুলো সম্পন্ন করা। তাদের উচিত হবে সফটওয়্যার তৈরি জন্য একটা সুন্দর প্লান তৈরি করা। প্লান টা কার্যকর করতে হলে অবশ্যই সফটওয়্যারটি কম্পিলিট হলে কেমন হবে তা সম্পর্কে একটা পরিষ্কার ধারনা থাকতে হবে। তবে ক্ষেত্র বিশেষে প্রসেস ভিন্ন ভিন্ন হতে পারে।

২। সফটওয়্যার কোন রকম কোন প্রবলেম অথবা ফেইলর ছাড়া কাঙ্ক্ষিত ফলাফল প্রদান করে এটা নিশ্চিত করা । সাথে সাথে যখন প্রয়োজন তখন যেন available থাকে সেটা নিশ্চিত করা।

৩। Software Specification and Requirements এ জানতে হবে যে গ্রাহক এই সফটওয়্যার থেকে কি চাই এবং তার এই চাহিদা গুলো ম্যানেজ করতে হবে। কোনটা সম্ভব ,কোনটা সম্ভব না , কতদিন লাগবে, কেমন খরচ হবে , ইত্যাদি বিষয়গুলো ম্যানেজ করা।

৪। রিসোর্স যা আছে , সেগুলো সর্বোচ্চ (যত টুকু সম্ভব) ব্যবহার করতে হবে। যে সফটওয়্যার অলরেডি তৈরি করা আছে, সে গুলো নতুন করে তৈরি না করে পূনব্যবহার করা। এতে রিসোর্স এর সুষ্ঠ ব্যবহার করা সম্ভব হবে।

Software engineering Ethics

Software engineering একটি সম্মানীয় এবং মর্যাদা সম্পন্ন পেশা। তাই এই সম্মান এবং মর্যাদা রক্ষার স্বার্থে একজন software engineer কে নীতি নৈতিকতা মেনে দৈনন্দিন কার্যক্রম চালিয়ে যেতে যায়। software engineer এর জন্য কিছু নীতি নৈতিকতা রয়েছে। তন্মধ্যে

১। গোপনীয়তা রক্ষা করাঃ আপনার কখনো উচিত হবে না, আপনার কম্পানি এবং কম্পানির ক্লায়েন্ট সম্পর্কে তথ্য ফাস করা।

২। যোগ্যতা বাইরে কাজ না করাঃ আপনি যে জিনিস পারেন না বা বোঝেন না, সেই জিনিস কাজ জেনে বুঝে করা কখনোই উচিত না। এক্ষেত্রে আপারকতা স্বিকার করা করা উচিত। তাদের বলা উচিত , এটা আমার জ্ঞানের বাইরে।

৩। intellectual property rights: আপনার উচিত intellectual property rights এর বিষয়ে স্থানীয় সরকারে কি ধরনের আইন কানুন বিদ্যমান রয়েছে এবং আপনার কোম্পানির এসব intellectual property rights এর ব্যাপারে সর্তক থাকা।

৪। কম্পিউটারের অপব্যবহারঃ অন্যের কম্পিউটারকে আপ্রাসঙ্গিক কাজে(গেম খেলা) ব্যবহার করা থেকে বিরত থাকা।

Marking Grading System with if-else-elif Part-09

Monirul Islam — Fri, 06 Sep 2024 06:00:00 +0000

আগের পার্টে একটা কাজ করতে দিয়েছিলাম। যারা করেছেন তাদেরকে ধন্যবাদ।

আর যারা করতে পারেন নি অথবা কোথাও বুঝতে সমস্যা আছে তার এই পার্ট টা স্কিপ করতে পারেন।

`Marking Grading System সিস্টেম বানাতে গেলে প্রথমে এই সিস্টেম কিভাবে কাজ করে সেটা জানতে হবে। আমরা সবাই জানি যে ১০০ এর ভিতরে ৮০ থেকে এর উপরে নাম্বার পেলেই A+`। নিচের টেবিল টা লক্ষ্য করুনঃ

মার্ক	ফলাফল
৮০ থেকে ১০০	A+
৭০ থেকে ৭৯	A
৬০ থেকে ৬৯	A-
৫০ থেকে ৫৯	B
৪০ থেকে ৪৯	C
৩৩ থেকে ৩৯	D
৩৩ এর নিচে	F

উপরে শর্ত্য গুলো মেনেই গ্রড নির্ণয় করা হয়।

এই বিষয়টা সমাধান করা জন্য পাইথন অপারেটর এর প্রয়োজন হবে।

এখানে কোড দেওয়া আছে। কোড থেকে বোঝার চেষ্টা করুন কিভাবে কি হয়েছে। তবে আগে নিজে নিজে চেষ্টা করে দেখুন।

marks = 55

if marks >= 80 and marks <= 100:
     print("You got A+")
else: 
    if marks >= 70 and marks <= 79:
        print("You got A")
    else:
        if marks >= 60 and marks <= 69:
            print("You got A-")
        else:
            if marks >= 50 and marks <= 59:
                print("You got B")
            else:
                if marks >= 40 and marks <= 49:
                    print("You got C")
                else:
                    if marks >= 33 and marks <= 39:
                        print("You got D")
                    else:
                        print("You got F")

Conditions (If-else-elif) Part-08

Monirul Islam — Wed, 04 Sep 2024 06:00:00 +0000

ছোট বেলায় আমি সন্ধার পর দেরি করে বাড়িতে যেতাম। প্রায় প্রতিদিন। এই জিনিস টা আমার মা ঠিক পছন্দ করে না। একদিন তো একটা warning দিয়েই দিলেন।

“কালকে থেকে যদি সন্ধ্যার আগে তুই বাড়ি না আসিস, তাহলে তোর খবর আছে।”

“আচ্ছা ঠিক আছে।”

“তোর না কালকে বললাম সন্ধ্যার আগে বাড়িতে আসবি। সন্ধ্যা কখন হয়েছে কোন খবর আছে”

“আর যদি ঠিক সময় মত চলে আসি তাহলে”

“তাহলে তোকে ২টা ডিম সিদ্ধ করে খেতে দিব”

পরের দিন সন্ধ্যাবেলা

অনেকদিনের অভ্যাস এত সহজে যায়। তারপর শুরু হল উত্তম মধ্যম। এভাবেই চলছে কিছুদিন। কোন কাজ হল।

তখন আমার মা বলল আমাকে একদিন ডেকে বলল

“শোন আমি একটা সিদ্ধান্ত নিয়েছি।”

“কি সিন্ধান্ত”। আমি একটু চিন্তিত। না যা জানি কি বলে বসে।

“কালকে থেকে তুই সন্ধ্যা হওয়ার ৫ মিনিটের মধ্যে বাড়িতে আসিস তাহলে তোকে ৫ টাকার ২ টা কেক দেওয়া হবে।”

আমি তো শুনেই সেই খুশি।

“থাম অত খুশি হওয়ার দরকার নেই। আর ১৫ মিনিট এর মধ্যে আছিস তাহলে ১ টা কেক পাবি”

“বাহ ভাল তো”

“আরেক টা জিনিস আছে। উপরের কোন টায় করতে না পারিস তাহলে কেক তো পাবিই না। সাথে তোর রাতে খাওয়া ও বন্ধ।”

“এই টা কিন্তু ঠিক হচ্ছে না।”

“ঠিক নাকি ভুল আমি সেটা বুঝব। তোর কাছে অপশন দিয়ে দিছি তোর যেই টা ভালো লাগবে সেইটা করবি ”

এখান থেকে কি কিছু বুঝতে পারছেন? আমার কপালে দুঃখ আছে। শর্ত অনুযায়ী কাজ না করলে তো থাকবেই। চাকরির ক্ষেত্রে চাকরিও চলে যেতে পারে।

এখানে লক্ষ্য করলে বুঝতে পারবেন যে,

প্রথম দৃশ্যে যদি লক্ষ করেন তাহলে খেয়াল করবেন এখানে কাজ ২ টা কিন্তু হবে যে কোন একটা। কোন কাজ টা হবে সেটা নির্ভর করছে একট শর্তের উপর (সন্ধ্যার আগে বাড়ি ফিরছি কিনা)।

আমি যেহেতু ওই দিন বাড়ি সময় মত ফিরতে পারি নি এই জন্য। আমার ক্ষেত্রে প্রথম কাজ টাই হয়েছে । উত্তম মধ্যম দিয়েছে আরকি।

এই একই বিষয়টা পাইথনেও আছে। নিচের কোড টা লক্ষ্য করুন

if condition:
    # condition সত্য হলে এই নিচের কোড রান হবে
    # expression
else:
    # condition সত্য না হলে বা মিথ্যা হলে এই নিচের কোড রান হবে
    # expression

এখানে if হল পাইথনের কিওয়ার্ড। if এর পরে একটা condition হবে এবং এই condition এর উপর ভিত্তি করে কোন ব্লকের কোড রান হবে তা নির্ধারিত হবে। condition সত্য হলে প্রথম ব্লক টা রান হবে আর সত্য না হলে পরবর্তী else ব্লকে চলে যাবে। নিচের কোড টা রান করলেই বুঝতে পারবেন।

if 1==1: # ১ আর ১ সমান
    print('Condition is true')
else:
    print('Condition is false')

বিঃদ্রঃ পাইথন অপারেটরের মাধ্যমে এখানে condition চেক করতে হবে।

এবার আসুন দ্বিতীয় দৃশ্যে

এখানে কিন্তু ২ টা condition আছে। এখন কি করবেন? খুব সহজ। আপনি একটু ভাবলেই পেরে যাবেন। আগে একটু ভাবেন।

এখানে প্রথম condition এর জন্য উপরে মত করে if else ব্যবহার করব। তারপর else ব্লক এর ভিতরে ২য় condition এর জন্য if else লিখবে। confusing লাগছে? নিচের কোড টা দেখলে বুঝতে পারবেন।

if 1==4: # 1st layer condition
    print('1st Condition is true')
else:
    if 2*3 == 6: # 2nd layer condition
        print('2nd Condition is true')
    else: 
        print('No Condition is true')

উপরে কোড কে পরিবর্তন করে নিজের মত করে কোন condition দেখতে পারেন।

কাজঃ আপনার এই if else ব্যবহার করে একটা Marking Grading System বানিয়ে ফেলুন। আর কোডের screenshot কমেন্ট এ শেয়ার করুন।

উপরে কোডে লক্ষ্য করলে দেখবেন এখানে 1st layer condition চেক করা পর 2nd layer condition এর চেক করছে । এখানে চাইলে একটু ভালোভাবে কোড লেখা যায়। নিচের কোড টা দেখুন

if 1==4:
    print('1st Condition is true')
elif 2*3 == 6:
    print('2nd Condition is true')
else: 
    print('No Condition is true')

এর আগের লেখা কোড আর এই কোডের আউটপুট একই আসবে। কিন্তু এই কোড আগের কোডের থেকে সহজে বোঝা যায়। পরবর্তীতে আমাদের সময় বাচাবে।

এখানে শুধু একটা নতুন condition add করেছি elif কিওয়ার্ড দিয়ে। এখানে খেয়াল করলে দেখবেন এখানে কিন্তু কোডের লেয়ার একটা কমে গেছে

কাজঃ এবার আপনার if else ব্যবহার করে Marking Grading System কে elif এ convert করে ফেলুন । আর কোডের screenshot কমেন্ট এ শেয়ার করুন।

আজ এই পর্যন্ত। এতক্ষন সাথে থাকার জন্য ধন্যবাদ। আপনার মতামত অবশ্যই জানাতে ভুলবেন না। কমেন্ট এ যদি বলতে সমস্যা হয় তাহলে আমার inbox তো খোলায় আছে।

Operators Part-07

Monirul Islam — Mon, 02 Sep 2024 06:00:00 +0000

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

চার্লস ব্যাবেজ ছিলেন একজন মেকানিক্যাল ইঞ্জিনিয়ার। এছাড়া অনেক সেক্টর ছিল যেমন গনিত অর্থনীতি এসব সেক্টরেও তার সমান পারদর্শীতা ছিল। তিনি প্রথম একটা যন্ত্র বানান যার দ্বারা গননা করা যেত। গণ্না এর ইংরেজি শব্দ compute । এখানে থেকেই পরবর্তীতে কম্পিউটার শব্দের উদ্ভব হয়।

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

কম্পিউটার জিনিস টাও একটু জটিল। এজন্য কম্পিউটার কে কাজ করাতে চাইলে প্রায় সবকিছুই বলে দেওয়া লাগে। না বললে কি হবে?

জগাখিচুড়ির সৃষ্টি হবে। আপনি ভাববেন এক, আর হবে আরেক। এসব সমাস্যার সৃষ্টি না সে জন্য কিছু সাংকেতিক চিহ্ন রয়েছে। এসব চিহ্নের মাধ্যমে যাব তীয় যৌক্তিক ও গানিতিক হিসাব নিকাশ সম্পন্ন করা হয়। এসব চিহ্নকে প্রোগ্রামিং লাংগুয়েজে অপারেটর বলে।

পাইথনে মোট ৭ ধরনের অপারেটর রয়েছে।

Arithmetic Operators: গানিতিক অপারশন সম্পন্ন করতে ব্যবহার করা হয়।
Relational Operators: দুই বা ততোধিক মানের ভিতর তুলনা করার জন্য ব্যবহার করা হয়।
Assignment Operators: ভেরিয়েবলে ভ্যালু আসাইন করার জন্য ব্যবহার করা হয়।
Logical Operators:দুই বা ততোধিক মানের ভিতর যৌক্তিক সম্পর্কের তুলনা করার জন্য ব্যবহার করা হয়।
Bitwise Operators: বিট ম্যানুপুলেশন এর জন্য ব্যবহার করা হয়।
Membership Operators: কোন ভ্যালু কোন লিস্ট-এ আছে কিনা তা চেক করা করার জন্য ব্যবহার করা হয়।
Identity Operators: ফলসি ভ্যালু চেক করার জন্য ব্যবহার করা হয়।

Arithmetic Operators

+ (Addition): দুটি সংখ্যা যোগ করতে ব্যবহার করা হয়।
- (Subtraction): একটি সংখ্যা থেকে অন্যটি বিয়োগ করতে ব্যবহার করা হয়।
* (Multiplication): সংখ্যা গুণ করতে বা স্ট্রিংকে একাধিক বার পুনরাবৃত্তি করতে ব্যবহার করা হয়।
/ (Division): সংখ্যা ভাগ করতে ব্যবহার করা হয়, এবং সবসময় একই ডিভাইজনের প্রকারভেদ দেয়।
% (Modulus): একটি সংখ্যা দিয়ে অন্যটি ভাগ করতে এবং মডুলোসহ প্রস্তুত হয়া বাকি অংশ হিসেবে নেওয়া হয়।
``** (Exponentiation): একটি সংখ্যা কে অন্যটি সংখ্যার পাওয়ার হিসেবে নেওয়া হয়।

নিচের কোড টি রান করলে বিষয়গুলো আরো ভালো ভাবে পরিষ্কার হবে।

a = 10
b =20
print(a + b)
print(a - b)
print(a * b)
print(a / b)
print(a % b)
print(a ** b)

Logical Operators:

and: দুটি শর্ত সত্য হলে সত্য প্রদান করে।
or: দুটি শর্ত যেকোনো একটি সত্য হলে সত্য প্রদান করে।
not: একটি শর্ত মিথ্যা হলে সত্য প্রদান করে

নিচের কোড টি রান করলে বিষয়গুলো আরো ভালো ভাবে পরিষ্কার হবে।

a = True
b =False
print(a and b)
print(a or b)
print(not a)
print(not b)

Comparison Operators:

== (Equal to): দুটি মান সমান হলে সত্য প্রদান করে।
!= (Not Equal to): দুটি মান সমান নয় হলে সত্য প্রদান করে।
< (Less than): একটি মান অপর মানের থেকে ছোট হলে সত্য প্রদান করে।
> (Greater than): একটি মান অপর মানের থেকে বড় হলে সত্য প্রদান করে।
<= (Less than or equal to): একটি মান অপর মানের থেকে কম বা সমান হলে সত্য প্রদান করে।
>= (Greater than or equal to): একটি মান অপর মানের থেকে বড় বা সমান হলে সত্য প্রদান করে।

নিচের কোড টি রান করলে বিষয়গুলো আরো ভালো ভাবে পরিষ্কার হবে।

a = 10
b =20
print(a == b)
print(a != b)
print(a >= b)
print(a > b)
print(a <= b)
print(a < b)

Assignment Operators:

= (Assignment): একটি মান একটি ভেরিয়েবলে সম্পাদন করতে ব্যবহৃত হয়।
+=, =, =, /=, //=, %=: ভেরিয়েবলে একটি মান যোগ, বিয়োগ, গুণ, ভাগ, পূর্ণাংশ ভাগ, বা মডুলো করতে এবং ফলাফলটি ভেরিয়েবলে সংরক্ষণ করতে ব্যবহৃত হয়।

নিচের কোড টি রান করলে বিষয়গুলো আরো ভালো ভাবে পরিষ্কার হবে। এই আপরেটর গুলো সামনে যখন লুপ ব্যবহার কর তখন কাজে লাগবে।

a = 10
print(a)
a+= 10
print(a)
a-= 10
print(a)
a*= 10
print(a)
a/= 10
print(a)

আপাতত নিচের দুইটা অপারেটর এর কোন উদাহরণ দিচ্ছি না এখন। সামনে যখন লিস্ট নিয়ে কাজ করা হবে তখন দেখানো হবে। ইনশাল্লাহ

Membership Operators:

in : একটি মান একটি সিকুয়েন্সে বিদ্যমান থাকলে সত্য প্রদান করে।
not in: একটি মান একটি সিকুয়েন্সে বিদ্যমান না থাকলে সত্য প্রদান করে।

Identity Operators:

is: একটি অবজেক্ট আরেকটি অবজেক্টের সাথে একই অবস্থানে আছে কিনা তা চেক করতে ব্যবহার করা হয়।
is not: একটি অবজেক্ট আরেকটি অবজেক্টের সাথে একই অবস্থানে নেই কিনা তা চেক করতে ব্যবহার করা হয়।

আপনার মতামত দিতে ভুলবেন না। এতক্ষন সাথে থাকার জন্য ধন্যবাদ।