အခန်း ၁ :: စတင်ခြင်း


ပထမဆုံး Software တွေ ကို မဖန်တီးခင်မှာ ကျွန်တော် တို့ တွေဟာ ဘာကြောင့်  Software Engineering ကို သိဖို့ လိုလဲ။ ဘာကြောင့် လိုအပ်တာလဲ ဆိုတာကို နားလည်ဖို့ သမိုင်း ကို အရင်လေ့လာဖို့ လိုပါတယ်။ 


၁.၁ Software Crisis သို့မဟုတ် ပညာရပ်တစ်ခု မွေးဖွားခြင်း

1960 ကာလမှာ computer တွေက စပြီး အသုံးပြုလာကြပြီ။ Hardware တွေလည်း စပြီး တိုးတက်မှု ရှိလာသည့် ကာလ လို့ ဆိုရမယ်။ ဒါပေမယ့် Software တွေ က အခုခေတ်လို အများကြီး မရှိသည့် ကာလပေါ့။ အဲဒီ ကာလ ကို “Software Crisis” လို့  လူသိများပါတယ်။ 

အဲဒီ စကားလုံးက ၁၉၆၈ မှာ ပထမဆုံး NATO Software Engineering Conference မှာ စပြီး သုံးဆွဲခဲ့တာပါ။ အဲဒီ အချိန်မှာ ဘာတွေ ပြဿနာရှိလဲ ဆိုတော့ Software တွေ ဖန်တီးရတာ အရမ်းကို ခက်ခဲတယ်။ ပြဿနာ မျိုးစုံ ရှိတယ်။ ဖြစ်သည့် ပြဿနာတွေက


ဥပမာ အနေနဲ့ IBM System/360 Operation System  က ဥပမာပဲ။ IBM ရဲ့ mainframe computer တွေ အတွက် OS/360 ကို လုပ်ခဲ့တယ်။ Fred Brooks က ဦးဆောင်ပြီး programmer တွေ ထောင်ပေါင်းများစွာ ပါဝင်ခဲ့တယ်။ အဲဒီခေတ်ကာလ မှာ တော့ အကြီးဆုံး software project တစ်ခု လို့ ဆိုရမှာပဲ။ Brooks ရေးထားသည့် The Mythical Man-Month  စာအုပ်ထဲမှာ နောက်ကျနေသည့် software project ထဲ ကို programmer အသစ် ထပ်ဖြည့်ခြင်းဟာ ပိုပြီး နောက်ကျ စေတယ် ဆိုပြီး မှတ်ချက်ပေးထား ပါတယ်။ dead line ကို နှစ်ပေါင်းများစွာ ကျော်ခဲ့ပြီးတော့ Budget ကလည်း ထင်ထားတာ ထက် အများကြီး ကုန်ကျခဲ့တယ်။

“Software Crisis” က code ရေးရုံ နဲ့ မလုံလောက်ဘူး။  ပိုပြီးကောင်းမွန်သည့် စနစ်တစ်ခု Engieering ဆန်သည့် နည်းစနစ် လိုအပ်ဆိုတယ် ဆိုတာကို နားလည်စေခဲ့တယ်။ ဒါကြောင့် “Software Engineering” က ပေါ်ပေါက်လာခဲ့ပါတယ်။


၁.၂ အစောပိုင်းကာလများ: Structured Programming And Waterfall Model


“Software Crisis” ကို ဖြေရှင်းဖို့ ပထမဆုံး အနေနဲ့ ပေါ်ပေါက်လာတာကတော့ Structured Programming နှင့် Waterfall Model ပဲ။

Structured Programming

အဲဒီ ခေတ်ကာလ က code တွေကို GOTO  နဲ့ အသုံးများပါတယ်။ ကျွန်တော်တို့ C ကို သင်ခဲ့သည့် အချိန် တုန်းကလည်း GOTO  တွေကို ရေးခဲ့ကြသေးပါတယ်။ ဒါပေမယ့် GOTO က လက်ရှိ code တွေကို ရှုပ်ထွေးစေပြီး code တစ်ခု က ဘယ် line ကို ခုန်ကူး သွားတယ် ဆိုတာ ကို ဘယ်လိုက်ရှာ ဖတ်နေရပါတယ်။ အခုခေတ် စကား နဲ့ ပြောရရင်တော့ “spaghetti code” တွေ ဖြစ်စေခဲ့ ပါတယ်။ 

Edsger Dijkstra ကဲ့သို့သော Computer Science သမား တော်တော်များများက Program ကို ဖန်တီးရာမှာ ရိုးရှင်းလွယ်ကူဖို့ အခြေခံ ၃ မျိုး နဲ့ တည်ဆောက်ဖို့ အကြံပြုခဲ့ကြတယ်။


  1. Sequence  : တစ်ခု ပြီးမှ တစ်ခု လုပ်ဖို့
  2. Selection  : ရွေးချယ်ခွင့် (if - else - then )
  3. Iteration  :   ထပ်ခါ ထပ်ခါ ပြုလုပ်ခြင်း ( for , while loop)

GOTO ကို ဖယ်ရှားပြီးတော့ အထက်ပါ ၃ ချက်ကို အသုံးပြုခြင်းအားဖြင့် Programmer တွေကို code တွေ ဖတ်ရှု ရတာ ပိုပြီး နားလည်လွယ်ကူ စေပြီး ထိန်းသိမ်းရတာလည််း ပိုလွယ်ကူ စေသည့် code တွေ ရေးလာစေနိုင်ပါတယ်။ ဒါကြောင့် အခုခေတ် language တွေမှာ GOTO  ကို မတွေ့ရပဲ အထက်ပါ အချက် ၃ ချက် ကို အခြေပြုပြီး ရေးသားကြပါတယ်။


Waterfall Model

Software Engineering အကြောင်း ပြောရင် မပါမဖြစ် ကတော့ Waterfall Model ပါပဲ။ သူက ရှေးအကျဆုံး နဲ့ လူ အသိအများဆုံးဖြစ်ပြီး ယနေ့ အထိ အချို့ Corporation ကြီးတွေမှာ အသုံးပြုနေဆဲပါပဲ။ Waterfall Model ၏ အစောဆုံး ပုံစံ ကို ၁၉၇၀ ခုနှစ်မှာ Winston W. Royce က သူ၏ "Managing the Development of Large Software Systems" ဟုအမည်ရသော စာတမ်းတစ်စောင်တွင် စတင်ဖော်ပြခဲ့ပါတယ်။ Royce က Waterfall Model မှာ အားနည်းချက်များရှိနိုင်ကြောင်း နှင့် ပြုပြင်ထားတော့ iterative ပုံစံ ကို အသုံးပြုဖို့ အကြံပြုခဲ့ပေမယ့် သူ ရဲ့ မူလ ရိုးရှင်းသည့် Sequential ပုံစံ ကို တွင်တွင်ကျယ်ကျယ် အသုံးပြုခဲ့ ကြပါတယ်။ ထိုအချိန်တုန်းက Software Project တွေဟာ အစိုးရ နှင့် NASA ကဲ့သို့ ကြီးမားသည့် အဖွဲ့အစည်းများ အတွက် ရည်ရွယ်ပြီး ရေးသားပြီး Hardware ထုတ်လုပ်သည့် အပိုင်းမှာလည်း စည်းမျည်း စည်းကမ်းများဖြင့် လုပ်ဆောင်ရသည့် အတွက် Waterfall Model က ထိုခေတ်ကာလ နဲ့ ကိုက်ညီ ခဲ့သည် လို့ ဆိုရမှာပဲ။




Water fall မှာ ပုံမှန် အားဖြင့် အဆင့် ၆ ဆင့် ပါဝင်ပါတယ်။ ဒါပေမယ့် အသုံးပြုသည့် အဖွဲ့ အစည်း ပေါ်မှာ မူတည်ပြီး ကွာခြားပါတယ်။


Waterfall စနစ်မှာ တစ်ဆင့် ပြီးသွားမှ နောက်တဆင့်ကို သွားပါတယ်။ အဆင့်တွေ ကျော်သွားလို့ မရသလို အဆင့်တိုင်း ကို အချိန်ပေးပြီး လုပ်ဖို့ လိုအပ်တယ်။ ဥပမာ Testing အဆင့်မှာ requirement အသစ်တွေ ထပ်လာလို့ မဖြစ်ပါဘူး။ လာခဲ့ရင် အစ ကနေ ပြန်စရပါတယ်။ အားနည်းချက်တွေ ရှိသလို အားသာချက်တွေလည်း ရှိပါတယ်။ အခန်း ၂ မှာတော့ Waterfall အကြောင်း ပိုမို ပြီး အသေးစိတ် ရေးသွားပါမယ်။


၁.၃ Object Oriented Programming

၁၉၇၀ ဝန်းကျင်မှာ Object Oriented Programming ဆိုတာ မရှိသေးပါဘူး။ OOP အတွေးအခေါ်ဟာ ၁၉၈၀ ပြည့်နှစ်အလွန် ၁၉၉၀ ပြည့် ဝန်းကျင်လောက်မှာ စတင်ပေါ်ပေါက်လာသည့် အတွေးအခေါ်တစ်ခုပါ။

Program တွေကို sequence instructions အစား OOP ဟာ developer တွေကို object အခြင်းခြင်း ပူးပေါင်းပြီး အလုပ်လုပ်သည့် ပုံစံ ပြောင်းလဲ စဥ်းစားလာကြပါတယ်။  Object Oriented Programming ဆိုတာ အခုခေတ် programming language တော်တော်များများမှာ မဖြစ်မနေ ပါဝင်နေပါပြီ။ 

OOP က အဓိက  ပါဝင်တာတွေကတော့


Encapsulation

Class တစ်ခုထဲမှာ data (properties) တွေ , method (function) တွေကို capsule လိုမျိုး အလုံပိတ်ထားသလို ထည့်သွင်း သိမ်းဆည်း ခြင်းလို့ ဆိုလို့ရမယ်။ Class အပြင်ဘက်ကနေ data တွေကို တိုက်ရိုက် ဝင်ရောက်ခွင့် မပြုပဲ  class ထဲမှာ သတ်မှတ်ထားသည့် method တွဤေ ကနေ တဆင့်သာ ဝင်ရောက်အသုံးပြု  စေတာပါ။ ဒါကြောင့် data လုံခြုံရေး ကို ပိုကောင်းစေပြီး မမျှော်လင့်ပဲ မှားယွင်း ပြောင်းလဲ မိတာမျိုးကနေ ကာကွယ် ပေးနိုင်တယ်။

ဥပမာ

ကားတစ်စီးမှာ Engine, Break စတာတွေကို ကားမောင်းသူက အသေးစိတ် သိဖို့ မလိုဘူး။​သိဖို့ လိုတာက ဘယ် function တွေက ဘာလုပ်သလဲ ဆိုတာပါပဲ။ Break နင်းရင် ကားရပ် မယ် ဆိုတာမျိုးပေါ့။  ဒီမှာ ကား  ရဲ့ အတွင်း ပိုင်း ဖွဲ့စည်း ပုံက Encapsulation လုပ်ထားပြီး driver က သုံးခွင့် ပေးထားသည့် funciton တွေကို အသုံးပြုနေသည့် သဘောပေါ့။


class BankAccount {
    // private property ကို class အပြင်ကနေ တိုက်ရိုက်ခေါ်သုံးလို့မရပါ
    private balance: number;

    constructor(initialBalance: number) {
        this.balance = initialBalance;
    }

    // public method ကနေတစ်ဆင့် private property ကို ဝင်သုံးခွင့်ပေးခြင်း (Getter)
    public getBalance(): number {
        return this.balance;
    }

    // public method ကနေတစ်ဆင့် private property ကို ပြောင်းလဲခွင့်ပေးခြင်း
    public deposit(amount: number): void {
        if (amount > 0) {
            this.balance += amount;
            console.log(`Deposited: ${amount}. New balance: ${this.balance}`);
        }
    }

    public withdraw(amount: number): void {
        if (amount > 0 && amount <= this.balance) {
            this.balance -= amount;
            console.log(`Withdrew: ${amount}. New balance: ${this.balance}`);
        } else {
            console.log('Insufficient funds or invalid amount.');
        }
    }
}

const myAccount = new BankAccount(1000);

// console.log(myAccount.balance); // Error! 'balance' is private. တိုက်ရိုက်ခေါ်လို့မရပါ။

console.log(myAccount.getBalance()); // 1000

myAccount.deposit(500); // Deposited: $500. New balance: $1500
myAccount.withdraw(200); // Withdrew: $200. New balance: $1300

Inheritance

အမွေဆက်ခံခြင်းလို့ ပဲ အလွယ်ပြောရမှာပဲ။ ရှိပြီးသား class (parent class ဒါမှမဟုတ် base class) တစ်ခုရဲ့ property တွေ method တွေကို တခြား class အသစ် တစ်ခု (child class or derived class) တစ်ခု က အမွေ ဆက်ခံပြီး ပြန်လည် အသုံးပြုနိုင်သည့် သဘောမျိုးပါ။ ဒါကြောင့် code တွေ ထပ်ခါ ထပ်ခါ ရေးစရာ မလိုပဲ ပြန်လည် အသုံးပြုနိုင်စွမ်း (code reusability) ကို မြှင့် တင်ပေးပါတယ်။

ဥပမာ

Animal ဆိုသည့် ယေဘူယျ class တစ်ခုမှာ စားသည် အိပ်သည် ဆိုသည့် method ရှိမယ်။ Dog class က Animal class ကို inheritance လုပ်လိုက်ရင် eat(), sleep() ဆိုသည့် function တွေက Dog class မှာ ပါပြီး သား ဖြစ်သွားပါမယ်။ Dog မှာ ကတော့ ကိုယ်ပိုင် bark() ဆိုသည့် functrion တစ်ခု ထပ်ဖြည့် ရုံပါပဲ။


// Parent Class (Base Class)
class Animal {
    name: string;

    constructor(name: string) {
        this.name = name;
    }

    eat(): void {
        console.log(`${this.name} is eating.`);
    }

    sleep(): void {
        console.log(`${this.name} is sleeping.`);
    }
}

// Child Class (Derived Class) - Animal class ကို အမွေဆက်ခံခြင်း
class Dog extends Animal {
    // ကိုယ်ပိုင် method အသစ်
    bark(): void {
        console.log('Woof! Woof!');
    }
}

class Cat extends Animal {
    // ကိုယ်ပိုင် method အသစ်
    meow(): void {
        console.log('Meow!');
    }
}

const myDog = new Dog('Aung Net');
myDog.eat();   // "Aung Net is eating." (Animal class ကနေ အမွေရထားတာ)
myDog.sleep(); // "Aung Net is sleeping." (Animal class ကနေ အမွေရထားတာ)
myDog.bark();  // "Woof! Woof!" (Dog class ရဲ့ ကိုယ်ပိုင် method)

const myCat = new Cat('Mee Phyu');
myCat.eat();   // "Mee Phyu is eating."
myCat.meow();  // "Meow!"

Polymorphism

Polymorphism ဆိုတာ ကတော့ ပုံစံ အမျိုးမျိုး ရှိခြင်း လို့ ဆိုနိုင်ပါတယ်။ class တွေက parent class တစ်ခုတည်းက ဆင်းသက်လာပေမယ့် method တစ်ခုတည်းကို တစ်ကောင်ခြင်းစီရဲ့ ကိုယ်ပိုင် ပုံစံ နဲ့ မတူ ပဲ ကွဲပြားစွာ အလုပ်လုပ်နိုင်ပါတယ်။ တနည်းဆိုရင် Method Overriding ပေါ့။

ဥပမာ

Animal class မှာ makeSound()  ဆိုသည့် method ရှိတယ်။ Dog class က Woof လို့ ဟောင်သည့် ပုံစံ လုပ်ပြီး Cat class က Meow ဆိုပြီး အလုပ်လုပ်စေပါတယ်။

class Animal {
    makeSound(): void {
        console.log('Some generic animal sound');
    }
}

class Dog extends Animal {
    // Parent class က makeSound() method ကို Override လုပ်ခြင်း
    makeSound(): void {
        console.log('Woof! Woof!');
    }
}

class Cat extends Animal {
    // Parent class က makeSound() method ကို Override လုပ်ခြင်း
    makeSound(): void {
        console.log('Meow!');
    }
}

class Cow extends Animal {
    // Parent class က makeSound() method ကို Override လုပ်ခြင်း
    makeSound(): void {
        console.log('Moo!');
    }
}

const animals: Animal[] = [new Dog(), new Cat(), new Cow()];

// animals array ထဲက object တစ်ခုချင်းစီဟာ Animal အမျိုးအစားဖြစ်ပေမယ့်၊
// makeSound() ကို ခေါ်လိုက်တဲ့အခါ သူ့ရဲ့ မူလ class အစစ် (Dog, Cat, Cow) က
// override လုပ်ထားတဲ့ method ကိုပဲ အလုပ်လုပ်သွားပါတယ်။
animals.forEach(animal => {
    animal.makeSound();
});

// Output:
// Woof! Woof!
// Meow!
// Moo!


Abstraction

Abstraction ဆိုတာကတော့ object တစ်ခု ရဲ့ ရှုပ်ထွေးသည့် တည်ဆောက်ပုံကို မရေးသားထားတော့ လိုအပ်သည့် class ကသာ ရေးသားခြင်းပါ။ တစ်နည်းပြောရင် Class ကို သုံးမယ့် သူတွေက Class က ဘာအလုပ်လုပ်တယ် ဆိုတာ သိရင်ရပြီ။ ဘယ်လို အလုပ်လုပ် ဆိုတာ သိဖို့ မလိုဘူး။ ဒီ Class မှာ ဒီ function ပါတယ် ဆိုတာ သိရင် ရပြီ။ နောက်တစ်မျိုး ကတော့ ဒီ class ကို extend လုပ် သုံးမယ် ဆိုရင် ဒီ function တွေ မဖြစ်မနေ ထည့်သွင်း ပေးရမယ် ဆိုတာမျိုးကို ဖော်ပြခြင်းပါ။

Typescript မှာ abstract မရှိသည့် အတွက် Java ဖြင့် code ဖော်ပြလိုက်ပါတယ်။

// Shape.java

public abstract class Shape {

    // Concrete Method (Implementation ပါတဲ့ သာမန် method)
    // ဒီ class ကို extend လုပ်တဲ့ class တိုင်း ဒီ method ကို အလိုအလျောက် ရရှိပါမယ်။
    public void displayInfo() {
        System.out.println("This is a geometric shape.");
    }

    // Abstract Method (Implementation မပါတဲ့ method)
    // ဒီ class ကို extend လုပ်တဲ့ class တိုင်းက ဒီ method ကို မဖြစ်မနေ implement လုပ်ပေးရပါမယ်။
    public abstract double calculateArea();
}

// Circle.java

public class Circle extends Shape {
    private double radius;

    public Circle(double radius) {
        this.radius = radius;
    }

    // Shape class က abstract method ကို Override လုပ်ပြီး implement လုပ်ခြင်း
    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }
}

// Rectangle.java

public class Rectangle extends Shape {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    // Shape class က abstract method ကို Override လုပ်ပြီး implement လုပ်ခြင်း
    @Override
    public double calculateArea() {
        return width * height;
    }
}

// Main.java

public class Main {
    public static void main(String[] args) {
        // Shape myShape = new Shape(); // Error! Abstract class ကို object တိုက်ရိုက်ဆောက်လို့ မရပါ။

        // Concrete class တွေကနေ object ဆောက်ခြင်း
        Shape circle = new Circle(5.0);
        Shape rectangle = new Rectangle(4.0, 6.0);

        // Circle object က သူ့ရဲ့ calculateArea() ကို ခေါ်သုံးခြင်း
        System.out.println("Area of Circle: " + circle.calculateArea());

        // Rectangle object က သူ့ရဲ့ calculateArea() ကို ခေါ်သုံးခြင်း
        System.out.println("Area of Rectangle: " + rectangle.calculateArea());

        // Parent class (Shape) က concrete method ကို ခေါ်သုံးကြည့်ခြင်း
        circle.displayInfo();
    }
}

//output
/*
Area of Circle: 78.53981633974483
Area of Rectangle: 24.0
This is a geometric shape.
*/

၁.၄ Agile Manifesto

၁၉၉၀ ပြည့် နောက်ပိုင်းမှာတော့ Waterfaill model နှင့် အခြား model တွေက ခေတ်နောက်ကျ လာပါတယ်။ အဓိကတော့ နှေး ပြီး ထိန်းချုပ်မှုတွေ များပါတယ်။​ စီးပွားရေးမှာ အမြန်ပြောင်းလဲနေသည့် ခေတ်ကို ရောက်လာသည့် အမျှ Waterfall model က လိုအပ်ချက်တွေ ကို မဖြေရှင်းပေးနိုင်တော့ပါဘူး။

၂၀၀၁ ခုနှစ်မှာ Software Developer ၁၇ ဦး က အမေရိကန် Uta က နှင်းလျှောစီး အပန်းဖြေ စခန်းတစ်ခုမှာ တွေ့ဆုံပြီးတော့ ပြဿနာ ကို ဆွေးနွေးခဲ့ကြပါတယ်။ ပြီးနောက်မှာတော့ မတူညီသည့် နောက်ခံများမှ လာသော်လည်း လက်ရှိ Software Development အခြေအနေ မှာ တူညီသည့် ပြဿနာများကို ဆွေးနွေးခဲ့ကြတယ်။ ပြီးတော့ အစည်းအဝေး ရလဒ် မှာ ကျွန်တော်တို့ အခု နောက်ပိုင်း ခေတ်စားလာသည့် Agile Software Development အတွက် ကြေညာစာမ်း  ကို ထုတ်ပြန်ခဲ့သည်။ 

Agile Manifesto မှာ အဓိက တန်ဖိုး လေး ခု ကို အခြေခံထားသည်။



မြန်မာလို ဘာသာပြန်ရရင်တော့



Waterfall နဲ့ လုံးမတူပဲ ကွဲထွက်နေတာ ဖြစ်ပါတယ်။ Agile Development က ပြောင်းလွယ် ပြင်လွယ်မှု ရှိတယ်။ အတူတူ ပူးပေါင်းဆောင်ရွက်မှု နှင့် မကြာခဏခဏ sofwtare တွေကို deliver လုပ်နိုင်မှု တို့ကို အလေးပေးတယ်။ Scrum နှင့် Kanban စသည့် Agile နည်းစနစ် တွေကို အခန်း ၃ မှာ ဖော်ပြပေးပါမယ်။


၁.၅ DevOps, Cloud , AI


Software Engineering ပြောင်းလဲမှု တွေက တောက်လျှောက်ဖြစ်ပေါ်နေပြီးတော့ အခုနောက်ပိုင်းမှာ ပုံမှန် လမ်းကြောင်းအပြင်  DevOps, Cloud တို့ဟာ Software Engineering ပိုင်းမှာ ပါဝင်လာပြီးတော့ AI ကလည်း အရေးပါသည့် အခန်း တစ်ခု ဖြစ်လာပါပြီ။


DevOps

Software Development လုပ်သည့် Developer နှင့် IT Operation အကြား အတားအတီး ကို ဖယ်ရှားရန် ရည်ရွယ်ပြီး ဖြစ်ပေါ်လာသည့် ယဥ်ကျေးမှု တစ်လို့ ဆိုရမှာပဲ။ DevOps က အဖွဲ့အစည်းများ အတွက် Sofwtare တွေကို မြန်မြန် ယုံယုံကြည်ကြည် deployment လုပ်နိုင်အောင် အထောက်အကူ ပြုသည့် သူတွေပါ။ အဓိက CI/CD pipeline တွေ တည်ဆောက်ခြင်း Development, Staging, Production environment စသည်တို့ ကို အလိုအလောက် deployment လုပ်ပေးနိုင်အောင် ဆောင်ရွက်ပေးထားတာ မျိုးပေါ့။


Cloud

အခုခေတ်မှာ Cloud Computing ကို အပြည့်အဝ အသုံးချပြီး System တော်တော်များများဟာလည်း Cloud ပေါ်မှာ အလုပ်လုပ်နေကြပါပြီ။ Microservice ကဲ့သို့သော စနစ် များအတွက် Cloud က မဖြစ်မနေ လိုအပ်ပါသည်။ Docker Container , Kubernetes ကဲ့သို့သော နည်းပညာများဟာလည်း cloud အတွက် အဓိက ကျသည့် အစိတ်အပိုင်း တွေပါပဲ။ AWS , Azure, Google Cloud တို့ဟာ Software Engineer တစ်ယောက် အနေနဲ့ နားလည် ထားသင့်သည့် အထဲမှာ ပါဝင်လာပါတယ်။


AI

ဒီစာအုပ်ရေးသည့် အချိန် ၂၀၂၅ ခုနှစ် အောက်တိုဘာလ မှာ AI က အရေးကြီးသည့် အစိတ်အပိုင်း တစ်ခု စတင်ဖြစ်လာပါပြီ။ Vibe Coding , LLM , RAG , Fine Tuning စသည် တို့ဟာလည်း developer တိုင်း နဲ့ မစိမ်းတော့ပါဘူး။ Github Copilot, Claude စသည့် AI အကူအညီ နဲ့ Software များ  မြန်မြန် ရေးနိုင်ခြင်း Error များကို ရှာဖွေခြင်း code review လုပ်ခြင်း တို့ ကို လုပ်ပေးနိုင်ခြင်းကြောင့် Software Engineering အပိုင်း ကို နောက်နှစ် အနည်းငယ် အတွင်းမှာ ထပ်ပြီး ပြောင်းလဲမှု တွေ ဖြစ်လာပါအုံးမယ်။


အခန်း ၁ ဟာ မိတ်ဆက်သဘော အကျဥ်းချုပ်ဖြစ်ပြီး နောက်ပိုင်း အခန်းတွေမှာ Software Engineering နဲ့ သက်ဆိုင်ရာ အကြောင်းအရာများကို အကျယ် ဖော်ပြပေးသွားပါမယ်။