1. Home
    2. »
  2. blog
    3. » ชีวิต(การเขียนโค้ด)ดีขึ้น 100% ด้วยหลักการ Separation of Concerns

ชีวิต(การเขียนโค้ด)ดีขึ้น 100% ด้วยหลักการ Separation of Concerns

blog
boon

เวลาเราเจอร้านอาหารอร่อยๆ เคยสังเกตไหมว่าทำไมเขาถึงไม่ให้แม่ครัวเดินไปรับออเดอร์เอง?

เพราะถ้าแม่ครัวต้องวิ่งไปรับออเดอร์ ล้างจาน คิดเงิน เปิดประตูรับลูกค้า… เดี๋ยวก็สต็อกวัตถุดิบพัง เดี๋ยวจานล้างไม่ทัน เดี๋ยวทอดปลาไหม้ โกลาหลไปหมด

ร้านอาหารที่รุ่งจึงแบ่งหน้าที่ชัดเจน พนักงานรับออเดอร์ แม่ครัว ล้างจาน แคชเชียร์ ต่างคนต่างทำ ไม่ก้าวก่ายกัน

หลักการนี้แหละครับ ที่ในวงการพัฒนาซอฟต์แวร์เขาเรียก “Separation of Concerns” (SoC)

enter image description here

🍳 Separation of Concerns คืออะไร?

“แบ่งแยกหน้าที่ให้ชัดเจน แต่ละส่วนรับผิดชอบแค่เรื่องเดียว ไม่ยุ่งกัน”

ตอนเราเขียนโปรแกรม เราอยากให้ส่วนที่คิดเรื่อง “ดึงข้อมูลจากฐานข้อมูล” ไม่ต้องไปสนใจว่า “หน้าตาเว็บจะเป็นสีฟ้าหรือสีเขียว”

และเราอยากให้ส่วนที่จัดการ “Logic ทางธุรกิจ” ไม่ต้องไปรู้ด้วยซ้ำว่าข้อมูลที่ได้มา มาจากฐานข้อมูล MySQL หรือ PostgreSQL หรือแม้แต่ไฟล์ข้อความ

มันคือการจัดบ้านให้เป็นระเบียบ ไม่เอารองเท้าไปเก็บไว้ในตู้เย็น

🧹 แล้วมันดีกับเรายังไง?

  1. แก้ไขง่าย – อยากเปลี่ยนระบบจ่ายเงินจาก TrueWallet เป็น Rabbit Card? แก้แค่ที่เดียว
  2. หาบั๊กง่าย – โปรแกรมพัง? รู้ทันทีว่าต้องไปดูส่วนไหน
  3. ทีมทำงาน parallel ได้ – คนเขียน Frontend ไม่ต้องรอ Backend เสร็จ
  4. เทสต์ง่าย – ทดสอบระบบจ่ายเงิน โดยไม่ต้องเปิดเว็บก็ได้
  5. ยืดหยุ่น – พรุ่งนี้เปลี่ยนจาก React เป็น Vue? เอาส่วน UI ออกไปทั้งดุ้น แล้วเอาอันใหม่มาใส่

🧩 ตัวอย่าง Separation of Concerns ที่เห็นกันบ่อยๆ ในชีวิตจริง

1. MVC – ตำราที่เด็กรุ่นใหม่ต้องเคยเจอ

Model (ข้อมูล) – View (หน้าตา) – Controller (ตัวประสาน)

เหมือนร้านอาหาร: - Model = ตำรับอาหาร + วัตถุดิบ (ข้อมูล) - View = จานที่จัดเสิร์ฟ (หน้าตา) - Controller = พนักงานเสิร์ฟ (รับออเดอร์ บอกครัว)

ถ้าไม่มี Separation of Concerns:
แม่ครัวต้องปลูกผักเอง เชือดไก่เอง ล้างจานเอง รับออเดอร์เอง กระบวนการทำงานเป็นไปด้วยความวุ่นวาย ไร้ประสิทธิภาพ

ถ้าเขียนโค้ดแยกกัน:
เปรียบได้กับการแก้สูตรต้มยำกุ้งที ไม่ต้องไปยุ่งกับวิธีการจัดเรียงจาน

2. Backend vs Frontend – สงครามที่คน 90% เคยเข้าใจผิด

สมัยก่อนคนเขียน PHP มักจะเขียน HTML ปนกับ SQL อยู่ในไฟล์เดียวกัน

<?php
$result = mysqli_query("SELECT * FROM users");
echo "<h1>สวัสดี " . $result['name'] . "</h1>";
?>

นี่คือต้นตอของความหายนะ! วันไหนอยากเปลี่ยนจาก Bootstrap เป็น Tailwind? ต้องควานหาคำสั่ง SQL ที่ซ่อนอยู่ใน HTML วันไหนเปลี่ยนชื่อฟิลด์ฐานข้อมูล? ต้องไล่เปลี่ยน HTML ทีละบรรทัด

Separation of Concerns แก้โดย: - Backend: ส่งแค่ JSON - Frontend: ค่อยเอาข้อมูลไปวาง

// Frontend fetch ข้อมูลจาก Backend
fetch('/api/users/1')
  .then(res => res.json())
  .then(user => {
    document.querySelector('h1').textContent = `สวัสดี ${user.name}`;
  });

Backend จะเป็น PHP, Python, Go หรืออะไรก็ช่าง Frontend ไม่สน

enter image description here

3. Business Logic แยกจาก Infrastructure

สมมติว่าเราสร้างระบบสมัครสมาชิก ที่ต้องส่งอีเมลต้อนรับ

BAD:

def register_user(email, password):
    # ... save to database ...
    smtp = smtplib.SMTP('smtp.gmail.com', 587)
    smtp.sendmail('admin@myapp.com', email, 'ยินดีต้อนรับ...')
    # ...

ดีที่ตรงไหน? พรุ่งนี้เราเปลี่ยนจาก Gmail SMTP เป็น SendGrid หรือเปลี่ยนเป็นส่ง LINE Notify เราต้องมาเปิดไฟล์นี้แก้ทั้งที่ Business Logic (การสมัครสมาชิก) ไม่ได้เปลี่ยนเลย!

GOOD:

def register_user(email, password, notifier):
    # ... save to database ...
    notifier.send(email, 'ยินดีต้อนรับ...')
    # ...

“ไม่ต้องสนว่า notification จะส่งผ่านอะไร แค่ส่งให้ได้ก็พอ”

4. UI แยกจาก Business Logic – เหตุผลที่แอป LINE ยังรอดแม้เปลี่ยนดีไซน์บ่อย

แอปธนาคารบนมือถือ: การคำนวณดอกเบี้ย การโอนเงิน Logic เหล่านี้อยู่ลึกในระบบ ส่วนหน้าตา UI จะเป็น iOS style, Android Material Design, หรือเว็บ มันแค่เรียก Logic เดียวกัน

นี่คือ Separation of Concerns ไม่ว่าคุณจะแตะปุ่มตรงไหน ยังไงเงินก็ต้องไปเข้าอีกบัญชีแบบเดียวกัน

🛑 ข้อควรระวัง: แยกจนขาดใจ

Separation of Concerns คือการแยกหน้าที่ แต่ไม่ใช่การตัดสะพานทิ้ง

บางโปรเจกต์แยกจนเกินไป:

  • เว็บ 2 หน้าจอ แต่สร้าง 5 microservices
  • เพิ่มฟิลด์ในตาราง ต้องแก้ 7 ชั้น กว่าจะถึง Database

จำไว้ว่า: แยกให้ดี แต่ต้องใช้งานได้จริง

🔥 สรุป

Separation of Concerns ไม่ใช่แค่เรื่องการเขียนโค้ด มันคือวิธีคิด

เวลาเราเจออะไรยุ่งๆ ให้ถามตัวเอง:

  1. ตอนนี้มันปนกันอยู่ตรงไหน?
  2. ถ้าแยกส่วนนี้ออก จะทำให้อีกส่วนยืดหยุ่นขึ้นไหม?

เริ่มจากเล็กๆ
วันนี้ลองแยก HTML กับ Logic ให้ห่างกันหน่อย พรุ่งนี้ลองแยก Business Logic ออกจาก Database Driver พอชำนาญ คุณจะตกใจว่าแต่ก่อนตัวเองเขียนโค้ดรวมกันเละเทะขนาดไหน

แล้วคุณจะรู้ว่า “การแยก” คือของขวัญที่ดีที่สุดที่มอบให้กับตัวคุณในอีก 6 เดือนข้างหน้า

ภาพประกอบ: 1 , 2

Tags