Software engineering কী — কোড লেখা থেকে টেকসই software বানানো

১ · কোড লেখা বনাম software engineering

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

দ্বিতীয় দৃশ্যে একটি কাল্পনিক বিশ্ববিদ্যালয়ের ফলাফল পোর্টাল। এটি চলবে দশ বছর বা তারও বেশি। প্রতি বছর নতুন নিয়ম আসবে — নতুন grading পদ্ধতি, নতুন বিভাগ, নতুন ফোন, নতুন browser. যাঁরা প্রথম কোড লিখেছিলেন, তাঁদের অনেকে তিন বছর পর অন্য চাকরিতে চলে যাবেন। নতুনরা এসে এমন কোড বদলাবেন, যা তাঁরা নিজে লেখেননি। আর একটি ভুল মানে হাজার শিক্ষার্থীর ভুল ফলাফল।

দুটি দৃশ্যেই কোড লেখা হচ্ছে। কিন্তু দ্বিতীয়টিতে প্রশ্নগুলো আলাদা: ছয় মাস পরে এটি বদলাতে পারব তো? অন্য কেউ বুঝবেন তো? বদলাতে গিয়ে পুরোনো কিছু ভেঙে যাবে না তো? দশজন একসাথে কাজ করলে একে অপরের কাজ মুছে ফেলবেন না তো? এই প্রশ্নগুলোর উত্তর খোঁজার বিদ্যাই software engineering.

“সময়ের সাথে যোগ করা programming”

২০২০ সালে প্রকাশিত Software Engineering at Google বইয়ে (Titus Winters, Tom Manshreck ও Hyrum Wright সম্পাদিত) একটি সংক্ষিপ্ত সংজ্ঞা জনপ্রিয় হয়েছে — মোটামুটি এরকম: software engineering হলো সময়ের সাথে যোগ করা programming (“programming integrated over time”). অর্থাৎ একটি মুহূর্তে কোড কাজ করছে কি না, শুধু সেটি নয়; কোডটি তার পুরো জীবনকাল ধরে কতটা সহজে বদলানো যায়, সেটিই আসল মাপ। বইটি তিনটি দিকের কথা বলে: সময় (কোড কত দিন বাঁচবে), মাপ (কতজন মানুষ, কত কোড) আর trade-off (কোন সিদ্ধান্তের দাম কী)।

আনুষ্ঠানিক সংজ্ঞা

IEEE-র পুরোনো মান IEEE Std 610.12 (১৯৯০) আর পরে software engineering-এর শব্দকোষ হিসেবে প্রকাশিত ISO/IEC/IEEE 24765-এ যে সংজ্ঞা দেওয়া আছে, তার সারকথা: software-এর development, operation আর maintenance-এ একটি নিয়মতান্ত্রিক (systematic), শৃঙ্খলাবদ্ধ (disciplined) ও মাপা যায় এমন (quantifiable) পদ্ধতির প্রয়োগ — অর্থাৎ software-এ engineering-এর প্রয়োগ। (শব্দের হুবহু রূপ সংস্করণভেদে সামান্য আলাদা হতে পারে; মূল ভাবটি এটাই।)

২ · Software কেন স্বভাবগতভাবে কঠিন

সেতু বানাতেও তো জটিলতা আছে। তাহলে software-এর বিশেষত্ব কী? ১৯৮৬ সালে The Mythical Man-Month-এর লেখক Fred Brooks একটি বিখ্যাত প্রবন্ধ লেখেন — “No Silver Bullet: Essence and Accident in Software Engineering”. সেখানে তিনি কঠিনতাকে দুই ভাগে ভাগ করেন:

• Essential complexity (মৌলিক জটিলতা) — সমস্যার নিজের ভেতরের জটিলতা। ব্যাংকের সুদের নিয়মে ৪০টি ব্যতিক্রম থাকলে কোডেও সেই ৪০টি থাকবে, যে ভাষাতেই লিখুন।
• Accidental complexity (আনুষঙ্গিক জটিলতা) — আমাদের টুল ও পদ্ধতির কারণে আসা জটিলতা। Assembly-তে লিখলে memory-র হিসাব নিজে রাখতে হয়; উচ্চস্তরের ভাষা সেটি সরিয়ে দেয়।

Brooks-এর যুক্তি ছিল, ভালো ভাষা, ভালো টুল আর দ্রুত কম্পিউটার accidental অংশ অনেক কমিয়েছে; কিন্তু essential অংশ থেকে যায়, তাই কোনো একক আবিষ্কার একাই দশ গুণ উন্নতি এনে দেবে — এমন “silver bullet” আশা করা ঠিক নয়। তিনি essential কঠিনতার চারটি বৈশিষ্ট্য বলেন:

এই কোর্সের প্রায় প্রতিটি হাতিয়ার এই চারটির কোনো একটির জবাব। Modularity আর design principle জটিলতা ভাগ করে (মডিউল ৫); requirement engineering conformity সামলায় (মডিউল ৪); test আর version control বদলকে নিরাপদ করে (মডিউল ৮ আর ২); UML আর architecture diagram অদৃশ্যকে দৃশ্যমান করে (পর্ব ২৯–৩০, ৩৮)।

৩ · Software lifecycle এক নজরে — আর এই কোর্সের মানচিত্র

প্রতিটি software, ছোট হোক বা বড়, মোটামুটি একই ধাপগুলো পার হয়। একে বলে software development life cycle বা SDLC. ধাপগুলোর নাম বই ও প্রতিষ্ঠানভেদে কিছুটা আলাদা, কিন্তু মূল কাঠামো এরকম:

1. Requirement — কী বানাতে হবে, কার জন্য, কেন। এখানে stakeholder-দের কথা শোনা হয়।
2. Design — কীভাবে বানাব: কোন অংশ, কোন ডেটা, কোন interface.
3. Construction — কোড লেখা, unit test, code review.
4. Testing — সবকিছু একসাথে ঠিকমতো কাজ করছে কি না যাচাই।
5. Deployment — ব্যবহারকারীদের জন্য production-এ চালু করা।
6. Maintenance — চালু software-এ ভুল সারানো, মানিয়ে নেওয়া, নতুন চাহিদা যোগ করা — যা থেকে আবার নতুন requirement জন্ম নেয়।

লক্ষ করুন, এটি একটি সরলরেখা নয়, একটি চক্র। এই ধাপগুলো কোন ক্রমে, একবারে না বারবার, বড় টুকরোয় না ছোট টুকরোয় করা হবে — সেটিই process model-এর প্রশ্ন: waterfall-এ একবারে একেকটি ধাপ, Scrum-এ প্রতি দুই-চার সপ্তাহে পুরো চক্রের একটি ছোট ঘূর্ণি। বিস্তারিত পর্ব ০৪ · SDLC আর process model, পর্ব ০৫ · Agile আর Scrum আর পর্ব ০৬ · Kanban আর lean-এ।

এবার একটি ছোট feature-কে ধারণা থেকে production পর্যন্ত অনুসরণ করা যাক। কাল্পনিক ফলাফল পোর্টালে শিক্ষার্থীরা চাইছেন: “নিজের ফলাফল PDF আকারে নামাতে চাই।” “পরে” চাপুন, অথবা “চালান” চাপলে নিজে থেকেই এগোবে।

৪ · দেরিতে ধরা ভুলের দাম

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

Software-এও একই ধারণা বহুল প্রচলিত: একটি defect যত পরের ধাপে ধরা পড়ে, তা ঠিক করতে সাধারণত তত বেশি rework লাগে। কারণগুলো সহজ: ভুল requirement-এর ওপর নকশা, নকশার ওপর কোড, কোডের ওপর test আর documentation দাঁড়িয়ে যায় — ভিত ভুল হলে ওপরের সব কিছু ভাঙতে হয়। আর production-এ ধরা পড়লে যোগ হয় ব্যবহারকারীর ক্ষতি, জরুরি release, ডেটা ঠিক করা আর আস্থা হারানো।

নিচের প্রোগ্রামটি ১,০০০টি কাল্পনিক bug নিয়ে খেলা করে। প্রতিটি bug requirement ধাপে জন্মায়, তারপর প্রতিটি ধাপে কিছু সম্ভাবনায় ধরা পড়ে, না পড়লে পরের ধাপে গড়িয়ে যায়; production-এ গেলে সেখানে তো ধরা পড়বেই — ব্যবহারকারী ধরিয়ে দেবেন। প্রতিটি ধাপে ঠিক করার খরচ (১, ২, ৪, ৮, ৩০ একক) আর ধরার সম্ভাবনা দুটোই অনুমান। দুটি দল তুলনা করা হয়েছে: একটি দল প্রায় শুধু শেষে test করে, আরেকটি requirement আর design ধাপেও review করে। এলোমেলো সংখ্যা আসে নির্দিষ্ট seed-এর mulberry32 থেকে, তাই প্রতিবার একই ফল।

// Where is a bug caught, and what does fixing it cost? A toy simulation.
// Stage costs and catch chances are ASSUMPTIONS for illustration, not measured facts.
let seed = 2026;
function rand() {                         // mulberry32: small seeded PRNG
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const STAGES = ["requirements", "design", "coding", "testing", "production"];
const COST   = [1, 2, 4, 8, 30];          // assumption: units of rework if the bug is caught here

function simulate(catchChance, bugs) {    // catchChance[i] = chance a stage catches a bug still alive
  const caught = [0, 0, 0, 0, 0]; let cost = 0;
  for (let b = 0; b < bugs; b++) {
    let s = 0;
    while (s < 4 && rand() >= catchChance[s]) s++;   // slips to the next stage
    caught[s]++; cost += COST[s];                     // production (s = 4) always "catches" it
  }
  return { caught, avg: cost / bugs };
}
const testOnly  = simulate([0.0, 0.0, 0.2, 0.6], 1000);  // assumption: almost no early review
const withReview = simulate([0.3, 0.3, 0.4, 0.6], 1000); // assumption: reviews in early stages

for (const [name, r] of [["test only  ", testOnly], ["with review", withReview]]) {
  console.log(name + "  caught per stage " + r.caught.join(" / ") + "   avg cost " + r.avg.toFixed(2));
}
console.log("stages: " + STAGES.join(" / "));

test only    caught per stage 0 / 0 / 213 / 455 / 332   avg cost 14.45
with review  caught per stage 287 / 213 / 201 / 179 / 120   avg cost 6.55
stages: requirements / design / coding / testing / production

৫ · Maintenance — জীবনকালের সবচেয়ে বড় খরচ

নতুনরা প্রায়ই ভাবেন, software বানানোর আসল কাজ প্রথম সংস্করণ লেখা, আর পরেরটা “ছোটখাটো ঠিকঠাক”। বাস্তব প্রায় উল্টো। বিভিন্ন বই ও জরিপে software-এর জীবনকালের মোট খরচের মধ্যে maintenance-এর ভাগ সাধারণত বড় করে দেখানো হয় — Robert Glass তাঁর Facts and Fallacies of Software Engineering (২০০২) বইয়ে ৪০% থেকে ৮০% পরিসরের কথা বলেছেন। সঠিক অনুপাত project, সময়কাল আর “maintenance” কাকে বলা হচ্ছে তার ওপর অনেক বদলায়, তাই কোনো একটি সংখ্যা মুখস্থ না করে পরিসর আর কারণটি বুঝুন।

আরেকটি গুরুত্বপূর্ণ পর্যবেক্ষণ: maintenance-এর বড় অংশ ভুল সারানো নয়। Lientz আর Swanson-এর ১৯৮০ সালের পরিচিত গবেষণা থেকে শুরু করে maintenance-কে সাধারণত কয়েক ভাগে দেখা হয় — corrective (ভুল সারানো), adaptive (নতুন OS, নতুন আইন, নতুন পরিবেশে মানিয়ে নেওয়া), perfective (নতুন feature, দ্রুততর করা), আর পরে ISO/IEC 14764-এ যোগ হওয়া preventive (ভবিষ্যতের সমস্যা ঠেকাতে কোড গুছানো)। বহু জরিপে দেখা গেছে, নতুন চাহিদা মেটানোর কাজই বড় ভাগ নেয়। অর্থাৎ maintenance মানে আসলে software-এর বেড়ে ওঠা।

কেন খরচ সময়ের সাথে বাড়ে? প্রতিটি তাড়াহুড়োর সমাধান একটু করে technical debt জমায় — ঋণের মতো, যার সুদ প্রতিটি পরের পরিবর্তনে দিতে হয়। Meir Lehman ১৯৭০-এর দশক থেকে software বিবর্তনের কয়েকটি “সূত্র” দিয়েছিলেন, যার একটির সারকথা: ব্যবহৃত software-কে ক্রমাগত বদলাতে হয়, আর আলাদা করে চেষ্টা না করলে বদলের সাথে তার জটিলতা বাড়ে। বিস্তারিত পর্ব ৪৩-এ।

নিচের খেলনা-মডেলে সব সংখ্যা ধরা যাক: প্রথম সংস্করণ বানাতে ১০০ একক; প্রথম বছরের maintenance তার ১৫%; প্রতি বছর কোড ৫% বেশি কঠিন হয়, তাই maintenance-ও ৫% করে বাড়ে; software চলে ১০ বছর।

// A toy lifetime-cost model. ALL numbers below are assumptions ("dhora jak"), not facts.
const DEV = 100;        // assumption: building version 1 costs 100 units
const YEARS = 10;       // assumption: the software is used for 10 years
const MAINT0 = 0.15;    // assumption: year-1 maintenance = 15% of DEV (fixes, small changes)
const GROWTH = 0.05;    // assumption: each year the code is 5% harder to change

function lifetime(years, maint0, growth) {
  let maint = 0;
  for (let y = 1; y <= years; y++) maint += DEV * maint0 * Math.pow(1 + growth, y - 1);
  return { maint, total: DEV + maint, share: maint / (DEV + maint) };
}

const base = lifetime(YEARS, MAINT0, GROWTH);
console.log("base case: dev " + DEV + ", maintenance " + base.maint.toFixed(1) +
  ", total " + base.total.toFixed(1) + ", maintenance share " + (100 * base.share).toFixed(1) + "%");

console.log("years  share(growth 0%)  share(growth 5%)  share(growth 10%)");
for (const y of [1, 3, 5, 10, 15]) {
  const row = [0, 0.05, 0.10].map((g) => (100 * lifetime(y, MAINT0, g).share).toFixed(1) + "%");
  console.log(String(y).padStart(5) + row.map((s) => s.padStart(18)).join(""));
}
// What if a cleaner design costs 20% more up front but grows only 2% a year?
let m2 = 0;
for (let y = 1; y <= YEARS; y++) m2 += DEV * MAINT0 * Math.pow(1.02, y - 1);
console.log("cleaner design: total " + (DEV * 1.2 + m2).toFixed(1) + " vs base " + base.total.toFixed(1));

base case: dev 100, maintenance 188.7, total 288.7, maintenance share 65.4%
years  share(growth 0%)  share(growth 5%)  share(growth 10%)
    1             13.0%             13.0%             13.0%
    3             31.0%             32.1%             33.2%
    5             42.9%             45.3%             47.8%
   10             60.0%             65.4%             70.5%
   15             69.2%             76.4%             82.7%
cleaner design: total 284.2 vs base 288.7

৬ · দল বড় হলে কী ভাঙে — n(n−1)/2

একা কাজ করলে সব তথ্য আপনার মাথায়। দুজন হলে একটি যোগাযোগ লাগে। তিনজনে তিনটি, চারজনে ছয়টি। প্রতিটি নতুন মানুষ বাকি সবার সাথে কথা বলতে পারেন, তাই n জনের দলে সম্ভাব্য communication path-এর সংখ্যা

কারণ: প্রত্যেকে বাকি (n−1) জনের সাথে যুক্ত, তাতে n(n−1); কিন্তু “ক-খ” আর “খ-ক” একই পথ, তাই ২ দিয়ে ভাগ। কাজ মানুষের সংখ্যার সমানুপাতে বাড়ে, কিন্তু যোগাযোগ বাড়ে প্রায় বর্গের হারে। Fred Brooks ১৯৭৫ সালে The Mythical Man-Month বইয়ে এই হিসাব দিয়েই ব্যাখ্যা করেন কেন “মাস × মানুষ” দিয়ে কাজ মাপা বিভ্রান্তিকর। নিচের ডায়াগ্রামে দল ১ জন থেকে ৮ জনে বাড়ছে — প্রতিটি নীল রেখা একটি যোগাযোগের পথ।

শেষ ক্যাপশনের হিসাবটি বড় দলে কেমন দাঁড়ায়? নিচের প্রোগ্রাম দুটি মডেল তুলনা করে: সবাই সবার সাথে, আর ৭ জনের বেশি নয় এমন ছোট দল — প্রতিটি দলের ভেতরে সবাই সবার সাথে, আর দলগুলোর প্রধানেরা (team lead) একে অপরের সাথে একটি করে সংযোগে। এটি একটি সরল মডেল: বাস্তবে দলের বাইরেও কিছু কথা হয়, আর প্রধানদের ওপর চাপ বাড়ে।

// Communication paths in a team: everyone-with-everyone vs small teams + leads.
const paths = (n) => n * (n - 1) / 2;          // every pair of people = one path

function splitTeams(n, maxSize) {              // fewest teams of size <= maxSize, sizes as equal as possible
  const k = Math.ceil(n / maxSize);
  const sizes = [];
  for (let i = 0; i < k; i++) sizes.push(Math.floor(n / k) + (i < n % k ? 1 : 0));
  return sizes;
}
function teamPaths(n, maxSize) {
  const sizes = splitTeams(n, maxSize);
  const inside = sizes.reduce((s, x) => s + paths(x), 0);  // paths inside each team
  const leads = paths(sizes.length);                       // one link between each pair of team leads
  return { sizes, inside, leads, total: inside + leads };
}

console.log(" n  all-pairs  teams(max 7)        inside  leads  total");
for (const n of [2, 3, 5, 7, 8, 10, 15, 20, 30, 50]) {
  const t = teamPaths(n, 7);
  console.log(String(n).padStart(2) + String(paths(n)).padStart(11) + "  " +
    t.sizes.join("+").padEnd(18) + String(t.inside).padStart(7) +
    String(t.leads).padStart(7) + String(t.total).padStart(7));
}
const a = paths(50), b = teamPaths(50, 7).total;
console.log("50 people: " + a + " -> " + b + " paths (" + (100 * b / a).toFixed(1) + "% of all-pairs)");
console.log("adding the 11th person to 10 adds " + (paths(11) - paths(10)) + " new paths");

 n  all-pairs  teams(max 7)        inside  leads  total
 2          1  2                       1      0      1
 3          3  3                       3      0      3
 5         10  5                      10      0     10
 7         21  7                      21      0     21
 8         28  4+4                    12      1     13
10         45  5+5                    20      1     21
15        105  5+5+5                  30      3     33
20        190  7+7+6                  57      3     60
30        435  6+6+6+6+6              75     10     85
50       1225  7+7+6+6+6+6+6+6       132     28    160
50 people: 1225 -> 160 paths (13.1% of all-pairs)
adding the 11th person to 10 adds 10 new paths

৭ · দলের ভূমিকা আর Git কোথায় বসে

বিয়েবাড়ির আয়োজনে বাবুর্চি, ডেকোরেটর, হিসাবরক্ষক, অতিথি আপ্যায়নকারী — প্রত্যেকের কাজ আলাদা, কিন্তু একটি তালিকা আর একজন সমন্বয়কারী ছাড়া সব গুলিয়ে যায়। Software দলেও কয়েকটি সাধারণ ভূমিকা থাকে। নাম আর ভাগ প্রতিষ্ঠানভেদে অনেক আলাদা; ছোট দলে একজন মানুষ একাধিক ভূমিকা পালন করেন।

এতগুলো মানুষের কাজ এক জায়গায় মেলে কোথায়? উত্তর: version control-এ — আজকের দিনে প্রায় সব জায়গায় Git. Git প্রতিটি পরিবর্তনের ইতিহাস রাখে (কে, কখন, কেন), প্রত্যেককে আলাদা branch-এ নিরাপদে কাজ করতে দেয়, আর পরে সবার কাজ মেলায়। এর ওপর দাঁড়িয়ে থাকে code review, স্বয়ংক্রিয় test আর release. মুদি দোকানের হিসাবের খাতার মতো — প্রতিটি লেনদেন তারিখ আর নামসহ লেখা, তাই মাস শেষে হিসাব না মিললে খুঁজে বের করা যায় কোন দিনের কোন লেখায় গোলমাল।

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

ধাপ ২ আর ৩-এর Git কমান্ডগুলো কেমন দেখায়? নিচের transcript এই মেশিনে Git ২.৫৩-এ চালিয়ে পাওয়া (লেখকের নাম ও সময় নির্দিষ্ট রাখা হয়েছে, তাই commit-এর hash একই আসে)। এখন শুধু চোখ বুলিয়ে নিন — প্রতিটি কমান্ড মডিউল ২-এ ধাপে ধাপে শিখবেন।

$ git switch -c fix/42-empty-marks
Switched to a new branch 'fix/42-empty-marks'
$ git commit -am "fix: handle an empty marks list (#42)"
[fix/42-empty-marks 46acbc9] fix: handle an empty marks list (#42)
 1 file changed, 2 insertions(+)
$ git log --oneline --decorate --all
46acbc9 (HEAD -> fix/42-empty-marks) fix: handle an empty marks list (#42)
d34ac42 (main) feat: add average marks

শেষ দুই লাইন পড়ুন: নতুন commit 46acbc9 আছে শুধু fix/42-empty-marks branch-এ (HEAD মানে আপনি এখন এখানে), আর main এখনো আগের d34ac42-তে। ঠিক স্টেপারের ধাপ ৩-এর অবস্থা। (git switch এসেছে Git ২.২৩-এ; পুরোনো টিউটোরিয়ালে একই কাজ git checkout -b দিয়ে দেখবেন।) Version control কেন আর কীভাবে — শুরু মডিউল ২-এর পর্ব ০৭ থেকে; দলের কাজের ধারা, pull request আর branching strategy মডিউল ৩-এ (পর্ব ১৪–১৯)।

৮ · Software engineering-এর জ্ঞানের মানচিত্র — SWEBOK আর এই কোর্স

Software engineering-এ কী কী জানতে হয়, তার একটি স্বীকৃত তালিকা আছে: IEEE Computer Society-র SWEBOK (Guide to the Software Engineering Body of Knowledge). এর সংস্করণ ৪ প্রকাশিত হয় ২০২৪ সালে। আমাদের জানামতে এতে ১৮টি knowledge area আছে — requirements, architecture, design, construction, testing, operations, maintenance, configuration management, engineering management, process, models and methods, quality, security, professional practice, economics আর তিনটি foundation (computing, mathematical, engineering). আগের সংস্করণের (২০১৪) তুলনায় architecture, operations আর security আলাদা ক্ষেত্র হিসেবে এসেছে বলে জানা যায়; হুবহু তালিকার জন্য SWEBOK-এর সরকারি নথিই দেখুন।

এই কোর্স SWEBOK-এর বেশিরভাগ ক্ষেত্র ছোঁয়, আর configuration management-এর কেন্দ্রে থাকা Git-কে খুব গভীরে নিয়ে যায়। ৭০টি পর্ব ১১টি মডিউলে সাজানো:

কোর্সের মানচিত্র — ১১টি মডিউল, ৭০টি পর্ব

কোর্সটি কাদের জন্য

কোর্স শেষে আপনি যা পারবেন

• একটি অস্পষ্ট চাহিদা থেকে মাপা যায় এমন requirement আর user story লিখতে
• coupling, cohesion, SOLID আর design pattern দিয়ে নকশা যাচাই ও সমালোচনা করতে, আর সঠিক নিয়মে UML আঁকতে
• অর্থবহ test লিখতে, coverage আর complexity হিসাব করতে
• Git দিয়ে branch, merge, rebase, ভুল শোধরানো আর হারানো commit উদ্ধার করতে — কোন কমান্ড কী বদলায় জেনে
• COCOMO II, function point, CPM-PERT-এর মতো numerical সমাধান করতে, আর একটি পুরো project requirement থেকে release পর্যন্ত নিয়ে যেতে (পর্ব ৬৫)

৯ · AI-এর যুগে software engineering

AI এখন কয়েক সেকেন্ডে কোড, test, commit message, এমনকি UML লিখে দেয়। তাহলে কি software engineering-এর দরকার কমল? উল্টো — কোড লেখা যত সস্তা হচ্ছে, কোন কোড রাখব, কোনটি বিশ্বাস করব, কীভাবে বছরের পর বছর বদলাব — এই সিদ্ধান্তগুলোর গুরুত্ব তত বাড়ছে। Brooks-এর ভাষায়, AI বিশেষভাবে accidental জটিলতা কমায়; requirement-এর অস্পষ্টতা, conformity আর বদলের চাপ — essential অংশ — আপনার দায়িত্বেই থাকে।

Software engineering-এ AI সাধারণত যেসব ভুল করে

AI-এর পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• পরামর্শের প্রতিটি অংশ নিজের ভাষায় ব্যাখ্যা করতে পারি — না পারলে merge করিনি
• কোনো Git কমান্ড আগে একটি আলাদা throwaway clone-এ চালিয়ে দেখেছি, আর reset --hard, push --force, clean -fd দেখলে দুবার ভেবেছি
• Diff লাইন ধরে পড়েছি, আর test চালিয়েছি; test-এ ইচ্ছা করে ভুল ঢুকিয়ে দেখেছি সেটি সত্যিই ব্যর্থ হয়
• উল্লিখিত standard, version বা flag অফিশিয়াল documentation-এ মিলিয়েছি
• কোডের উৎস আর license নিয়ে সন্দেহ থাকলে খোঁজ নিয়েছি
• Prompt-এ কোনো secret, password বা ব্যক্তিগত ডেটা দিইনি