সফটওয়্যার ইঞ্জিনিয়ারিং কী ও Git কেন গুরুত্বপূর্ণ
এই পাঠে যা শিখবেন
- সফটওয়্যার ইঞ্জিনিয়ারিংয়ের সংজ্ঞা এবং এটি নিছক "কোড লেখা" থেকে ঠিক কীভাবে আলাদা
- ভার্সন কন্ট্রোল (বিশেষত Git) কেন আধুনিক সফটওয়্যার প্র্যাক্টিসের ভিত্তি-অবকাঠামো
- এই কোর্স ঠিক কী কভার করে — সফটওয়্যার লাইফসাইকেলের ধাপ থেকে Git-এর দক্ষতা পর্যন্ত সম্পূর্ণ মানচিত্র
- Python দিয়ে একটি ছোট্ট Git কমিট-হিস্ট্রি সিমুলেশন — M7-এ আসা Git-এর অভ্যন্তরীণ মডেলের একটি প্রিভিউ
১ · সফটওয়্যার ইঞ্জিনিয়ারিং কী
সফটওয়্যার ইঞ্জিনিয়ারিংSoftware Engineeringসফটওয়্যার ডিজাইন, ডেভেলপমেন্ট, টেস্টিং ও রক্ষণাবেক্ষণের জন্য প্রকৌশল-নীতি প্রয়োগ করার নিয়মতান্ত্রিক শৃঙ্খলা — শুধু "কোড লেখা" নয়, বরং নির্ভরযোগ্য, রক্ষণাবেক্ষণযোগ্য সফটওয়্যার প্রোডাক্ট তৈরির সম্পূর্ণ প্রক্রিয়া। হলো সফটওয়্যার তৈরির সেই নিয়মতান্ত্রিক পদ্ধতি, যা শুধু "কাজ করে এমন কোড লেখা"-র চেয়ে অনেক বেশি কিছু কভার করে। একটি ব্যক্তিগত ছোট স্ক্রিপ্ট লেখা আর একটি সফটওয়্যার প্রোডাক্ট বানানোর মধ্যে বড় পার্থক্য — প্রোডাক্টে থাকে একাধিক ডেভেলপার, বদলে যাওয়া রিকোয়ারমেন্ট, বছরের-পর-বছর রক্ষণাবেক্ষণ, এবং হাজারো ব্যবহারকারীর উপর নির্ভরযোগ্যতার দায়িত্ব — এই জটিলতা সামলানোর জন্যই "ইঞ্জিনিয়ারিং" শব্দটি এখানে ব্যবহৃত হয়, ঠিক যেভাবে সিভিল ইঞ্জিনিয়ারিং শুধু "ইট গাঁথা" নয়, বরং নিয়মতান্ত্রিক ডিজাইন ও নিরাপত্তা নিশ্চিত করা।
২ · Git কেন এই কোর্সের নামেই আছে
GitGitএকটি ডিস্ট্রিবিউটেড ভার্সন কন্ট্রোল সিস্টেম — কোডের প্রতিটি পরিবর্তনের ইতিহাস ট্র্যাক করে, একাধিক ডেভেলপারকে একই কোডবেসে নিরাপদে সমান্তরালভাবে কাজ করতে দেয়। হলো সফটওয়্যার ইঞ্জিনিয়ারিংয়ের সবচেয়ে ব্যাপকভাবে ব্যবহৃত ভার্সন কন্ট্রোল সিস্টেম — এবং এই কোর্সের নামেই এটি আলাদাভাবে উল্লেখ থাকার কারণ হলো: Git ছাড়া এই কোর্সের বাকি প্রায় সবকিছুই ব্যবহারিকভাবে অসম্ভব হয়ে পড়ে। কোড রিভিউ (M11/L52) করতে হলে পরিবর্তনগুলো আলাদাভাবে দেখা দরকার — Git সেটি দেয়। একাধিক ডেভেলপার একসাথে ভিন্ন ফিচারে কাজ করতে হলে নিরাপদে আলাদা "ব্রাঞ্চ" দরকার (M8) — Git সেটি দেয়। CI/CD (M12) চালু করতে হলে "কোড পুশ হলেই স্বয়ংক্রিয়ভাবে টেস্ট চলবে" এমন একটি ট্রিগার পয়েন্ট দরকার — Git-এর রিমোট রিপোজিটরি (M9) সেটি দেয়।
৩ · এই কোর্স ঠিক কী কভার করে
SDLC মডেল (M2), রিকোয়ারমেন্ট ইঞ্জিনিয়ারিং (M3), ডিজাইন প্রিন্সিপল ও প্যাটার্ন (M4-M5), সফটওয়্যার আর্কিটেকচার (M6), টেস্টিং (M10), কোড কোয়ালিটি (M11), প্রজেক্ট ম্যানেজমেন্ট (M13) — কীভাবে একটি সফটওয়্যার প্রোডাক্ট পরিকল্পনা ও ডিজাইন করা হয়।
Git ফাউন্ডেশন (M7), ব্রাঞ্চিং ও মার্জিং (M8), কোলাবোরেশন ওয়ার্কফ্লো (M9), CI/CD প্রসেস (M12) — কীভাবে একটি টিম একই কোডবেসে নিরাপদে, সংগঠিতভাবে একসাথে কাজ করে।
Data Structures & Algorithms কোর্স শেখায় কীভাবে একটি সমস্যার সঠিক, দক্ষ সমাধান লিখতে হয় — কিন্তু সেই সমাধানকে একটি বাস্তব, দীর্ঘমেয়াদী প্রোডাক্টে পরিণত করতে এই কোর্সের প্রসেস ও প্রিন্সিপলও লাগে। আর Cloud Computing & DevOps কোর্স CI/CD-এর আসল বাস্তবায়ন (পাইপলাইন কনফিগারেশন, কন্টেইনার, Kubernetes) শেখায় — এই কোর্স শুধু CI/CD-এর "কেন" ও মূলনীতি কভার করে, "কীভাবে" নয়।
৪ · একটি ছোট্ট Git কমিট-হিস্ট্রি প্রিভিউ
নিচের কোড সেলে Git-এর সবচেয়ে মৌলিক ধারণা — একটি কমিট হিস্ট্রি — এর একটি সরলীকৃত প্রিভিউ দেখা যাক। বাস্তব Git বাইনারি এই ব্রাউজার-স্যান্ডবক্সে চলে না, তাই আমরা এর অভ্যন্তরীণ মডেল (প্রতিটি কমিট তার আগের কমিটকে "পয়েন্ট" করে) Python দিয়ে সিমুলেট করছি — M7-এ এটিই বিস্তারিতভাবে আসবে।
# একটি সরলীকৃত Git কমিট-হিস্ট্রি সিমুলেশন -- বাস্তব git বাইনারি এই স্যান্ডবক্সে নেই,
# তাই আমরা Git-এর অভ্যন্তরীণ মডেল (প্রতিটি কমিট তার parent-কে পয়েন্ট করে) নিজেরা বানাচ্ছি -- M7-এ বিস্তারিত।
def make_repo():
return {"commits": {}, "head": None}
def commit(repo, message):
parent = repo["head"]
commit_hash = f"c{len(repo['commits']) + 1}"
repo["commits"][commit_hash] = {"message": message, "parent": parent}
repo["head"] = commit_hash
return commit_hash
repo = make_repo()
commit(repo, "প্রথম কমিট: প্রজেক্ট শুরু")
commit(repo, "README যোগ করা হলো")
commit(repo, "লগইন ফিচার যোগ করা হলো")
print("Git commit history (HEAD থেকে পেছনের দিকে, ঠিক 'git log'-এর মতো):\n")
current = repo["head"]
while current:
c = repo["commits"][current]
print(f" {current} {c['message']}")
current = c["parent"]parent ফিল্ড), পুরো হিস্ট্রি
না। এই সরল "প্রতিটি কমিট তার আগেরটাকে পয়েন্ট করে" ধারণাটিই Git-এর পুরো কমিট-গ্রাফের ভিত্তি — M7-এ আমরা এর
সাথে ব্রাঞ্চ (একাধিক স্বাধীন HEAD) ও মার্জ (দুটো হিস্ট্রি একসাথে করা) যোগ করব।
সফটওয়্যার ইঞ্জিনিয়ারিং ও Git একসাথে দেখায় কীভাবে একটি আইডিয়া ধাপে ধাপে একটি নির্ভরযোগ্য, টিম-চালিত সফটওয়্যার প্রোডাক্টে পরিণত হয় — শুধু ব্যক্তিগত কোড লেখার দক্ষতা নয়, বরং প্রক্রিয়া, ডিজাইন সিদ্ধান্ত, ও নিরাপদ কোলাবোরেশনের একটি সম্পূর্ণ চর্চা। এই কোর্স ধাপে ধাপে সেই পুরো চর্চাটিই দেখাবে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ একজন ব্যক্তি একা একটি ছোট স্ক্রিপ্ট লিখলে কি তাকে "সফটওয়্যার ইঞ্জিনিয়ারিং" করছে বলা যায়? কেন বা কেন নয়?
সাধারণত না — অন্তত এই কোর্সের অর্থে নয়। একটি একবার-ব্যবহারযোগ্য, একজনের জন্য লেখা ছোট স্ক্রিপ্টে রিকোয়ারমেন্ট পরিবর্তন, দীর্ঘমেয়াদী রক্ষণাবেক্ষণ, একাধিক ডেভেলপারের কোলাবোরেশন, বা নির্ভরযোগ্যতার দায়িত্ব — এসবের কোনোটিই সাধারণত থাকে না। সফটওয়্যার ইঞ্জিনিয়ারিং তখনই আসল গুরুত্ব পায় যখন এই জটিলতাগুলো বাস্তবে দেখা দেয় — অর্থাৎ স্কেল ও সময়ের সাথে সাথে।
প্র ০২ "SE প্রসেস ও প্রিন্সিপল" ও "Git ও কোলাবোরেশন" — এই কোর্সের দুটো দিক আসলে কীভাবে একে অপরকে সমর্থন করে?
SE প্রসেস (যেমন কোড রিভিউ, M11/L52) ব্যবহারিকভাবে সম্ভবই হয় না Git-এর মতো কোনো টুল ছাড়া — কোড রিভিউ করতে হলে "ঠিক কী পরিবর্তন হয়েছে" তা আলাদা করে দেখা দরকার, যা Git-এর diff/branch মেকানিজম দেয়। উল্টোদিকে, Git নিজে থেকে কোনো "ভালো প্র্যাকটিস" নিশ্চিত করে না — কখন ব্রাঞ্চ করবেন, কখন মার্জ করবেন, কীভাবে কমিট মেসেজ লিখবেন — এসব সিদ্ধান্ত আসে SE প্রসেস থেকে। দুটো একসাথে মিলেই একটি কার্যকর টিম-ওয়ার্কফ্লো তৈরি হয়।
প্র ০৩ উপরের কোড সেলে কমিট হিস্ট্রি c3, c2, c1 — এই ক্রমে প্রিন্ট হলো, c1, c2, c3 ক্রমে নয় কেন?
কারণ ট্রাভার্সাল repo["head"] থেকে শুরু হয়েছে, যা সর্বশেষ কমিট c3-কে পয়েন্ট করে — তারপর
প্রতিটি ধাপে parent ফিল্ড অনুসরণ করে পেছনের দিকে হাঁটা হয়েছে (c3→c2→c1→None)। এটি ঠিক বাস্তব
git log-এর আচরণের মতো — সবসময় সবচেয়ে সাম্প্রতিক কমিট থেকে শুরু করে ইতিহাসে পেছনের দিকে
যায়, কারণ প্রতিটি কমিট শুধু তার নিজের parent-কে চেনে, কোনো "পরের" কমিটকে নয়।
অনুশীলন
-
চিন্তা করুন: আপনি যদি একটি টিম প্রজেক্টে কাজ করেন যেখানে ৫ জন ডেভেলপার একসাথে একই কোডবেসে কাজ করছে, Git ছাড়া (যেমন সবাই একই ফোল্ডার শেয়ার করে সরাসরি ফাইল এডিট করছে) কী কী সমস্যা হতে পারে তার একটি তালিকা করুন।
সম্ভাব্য সমস্যা: দুইজন একই ফাইলে একসাথে কাজ করলে একজনের পরিবর্তন আরেকজনের দ্বারা মুছে যেতে পারে; কোন পরিবর্তন কে করেছে তা ট্র্যাক করা অসম্ভব; একটি বাগ ধরা পড়লে ঠিক কোন পরিবর্তনটি সেই বাগ এনেছে তা খুঁজে বের করা কঠিন; একটি এক্সপেরিমেন্টাল ফিচার চেষ্টা করতে গিয়ে পুরো কোডবেস ভেঙে গেলে আগের কার্যকর অবস্থায় ফিরে যাওয়ার কোনো নির্ভরযোগ্য উপায় থাকে না। M7-M9-এ দেখব কীভাবে Git ঠিক এই প্রতিটি সমস্যার সমাধান দেয়।
-
পরীক্ষা করুন: উপরের কোড সেলে একটি চতুর্থ
commit(repo, "...")কল যোগ করে (আপনার নিজের মেসেজ দিয়ে) Run চেপে দেখুন হিস্ট্রি প্রিন্ট কীভাবে বদলায়।নতুন কমিট (c4) হবে নতুন HEAD, এবং হিস্ট্রি এখন c4, c3, c2, c1 ক্রমে প্রিন্ট হবে — নতুন কমিটটি সবার উপরে (সবচেয়ে সাম্প্রতিক হিসেবে) যোগ হবে, কিন্তু বাকি হিস্ট্রি অপরিবর্তিত থাকবে, কারণ প্রতিটি আগের কমিট এখনও ঠিক একই
parentচেইন বজায় রাখছে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৮টি পাঠ এখন সবগুলো পাঠ উপলব্ধ — SDLC, SOLID, ডিজাইন প্যাটার্ন, Git ব্রাঞ্চিং/মার্জিং থেকে শুরু করে চূড়ান্ত প্রজেক্ট-সিমুলেশন প্রকল্প পর্যন্ত।
- Data Structures & Algorithms কোর্স সহোদর কোর্স এই কোর্স শেখায় কীভাবে একটি সমাধানকে টিম-চালিত প্রোডাক্টে পরিণত করা হয়, সেই কোর্স শেখায় কীভাবে সমাধানটি সঠিক ও দক্ষভাবে লেখা হয়।
- Cloud Computing & DevOps কোর্স সঙ্গী কোর্স CI/CD-এর মূলনীতি এই কোর্সে, আর সেই মূলনীতির আসল বাস্তবায়ন (পাইপলাইন, কন্টেইনার, Kubernetes) সেই কোর্সে।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design ও Software Engineering & Git — সব এক জায়গায়।