Architecture: ไม่เขียน spaghetti code

สวัสดีครับ,

ไม่ได้เขียนซะนาน แต่วันนี้ตกผลึกอะไรบางอย่าง เลยอยากเล่าให้ฟัง

จริงๆ อยากเปิดเป็นคอส Design Patterns & Solution Architecture

สำหรับสอนวิธีคิดของคนที่อยากเป็น Solution Architect

แต่คงต้องใช้เวลาเตรียมตัวอีกซักพักใหญ่ๆ

วันนี้เลยมาเขียนเป็น introduction ให้ดูก่อน

–

เวลาเราเขียน code คุณรู้มั้ยเรากำลังทำอะไรอยู่…???

.

.

.

.

.

.

.

.

–

เรากำลังควบคุมเครื่องคอมให้ทำงานตามที่ code เราสั่งรึป่าวครับ?

คำตอบคือ “ใช่”

แต่เราควบคุมเครื่องคอมไปทำไมกันหล่ะ ???

 

เพื่อประมวลผลข้อมูล แล้วเอาผลลัพท์นั้นมาใช้แก้ปัญหาต่างๆใช่รึป่าว ?

–

ดังนั้น เราเขียน code เพื่อประมวลผลข้อมูล แล้วเอาผลลัพท์นั้นมาใช้แก้ปัญหาต่างๆ

เช่น การลงบัญชีรับจ่าย และสรุปยอดเงินคงเหลือ

สมัยก่อน ถ้าไม่มีคอมพิวเตอร์ เราก็ได้แต่ดีดลูกคิดแล้วจดไว้ในกระดาษ

แต่พอมีคอมพิวเตอร์ เราก็กรอกลงบนคอมพิวเตอร์ แล้วมันก็คำณวนสรุปยอดเงินคงเหลือให้อัตโนมัติ

–

แต่พอ code เรายาวขึ้น ยาวขึ้น ยาวขึ้น

เพราะเราแก้ปัญหา เยอะขึ้น เยอะขึ้น เยอะขึ้น

สุดท้าย ปัญหาที่เราแก้ ก็ถูกอธิบายโดย code

แต่พอ code เยอะขึ้น มันก็เลยพันกันไปหมด

–

แล้วฝรั่งที่เรียกตัวเองว่า “Gang of Four” ไม่ใช่ F4 ที่เป็นสี่เสี่ยวข้าวเหนียวนึ่งบ้านเรานะ

เลยออกหนังสือชื่อ design patterns ขึ้นมา

–

ถ้าเราแปลกันตามศัพท์

pattern แปลว่า รูปแบบ

design แปลว่า ออกแบบ

ถ้ารวม 2 คำ design pattern จะแปลว่า fucking up ว่า “รูปแบบการออกแบบ”

–

พอแปลแล้ว fucking up มากๆ เลยแปลครึ่งๆกลางๆแบบนี้ดีกว่า

“pattern ในการ design” ฟังดูดีขึ้นมั้ย???

ซึ่งในหนังสือมันก็ออกเราว่า รูปแบบปัญหาแบบนี้ มี guideline ให้ design แบบนี้

–

พอเอา design pattern มาใช้กับ code ที่แก้ปัญหาต่างๆของเรา

เราจะพบว่า code ของเรา ถ้าแก้ปัญหาเดิมๆ เราจะใช้ design pattern เดียวกัน

หรือพูดง่ายๆว่า “รูปแบบ” การเขียน code จะเป็นรูปแบบเดียวกัน

–

ถึงจุดนี้คำถามครับ?

ถ้า “รูปแบบ” การเขียน code ในการแก้ปัญหาเดิมๆ ที่ pattern เดียวกันนั้นเหมือนกัน

code เราจะยังเป็น spaghetti มั้ย?

คงจะตอบในใจกันได้อยู่แล้วสินะ

.

.

.

.

.

.

.

มันก็ต้องไม่เป็น spaghetti อยู่แล้วแหละ

เพราะมันดูมีทางออกมากขึ้น

–

คำเตือน “design pattern” ของ Gang of Four ไม่ใช่ สรณะ ในการแก้ปัญหานะ

ถ้าเขียน Java EE แล้วไม่เคยอ่าน Core J2EE Patterns

หรือใช้ Spring แต่ไม่เคยอ่าน expert one-on-one J2EE Development without EJB

ผมว่าคุณกำลังหลงทางแล้วนะ

–

แต่ก็อีกนั่นแหละครับ ถึงอ่านทั้งหมดข้างบนนี่

ทุกอย่างมันก็ “ไม่ใช่สรณะ” ในการแก้ปัญหา

ดูปาก ณัชชา อีกครั้งนะค่ะ “ไม่ใช่สรณะ” ในการแก้ปัญหา

–

เพราะ coding แต่ละอันที่คุณกำลังทำ มันแก้ปัญหาเฉพาะทางใน business domain หนึ่งๆ

ดังนั้น มันก็ต้องมี design pattern เฉพาะทางในการแก้ปัญหาของ domain นั้นๆ

แค่หนังสื่อที่กล่าวมานี่ เป็นหลักยึดสำหรับศึกษา ในการแก้ปัญหาทั่วๆไปในการเขียนโปรแกรม

–

พอเราเริ่มมีรูปแบบในการแก้ปัญหาทั่วๆไปจาก design pattern แล้ว

แต่อย่าลืมว่า design pattern มันมีหลายอัน เพราะปัญหาเรามีหลายรูปแบบ

แล้วมันก็ยังต้องอยูร่วมกันใน code ของโปรแกรมชุดเดียวกัน

ดังนั้น เราต้อง “ตกลง” ว่า design pattern เหล่านั้น จะอยู่ร่วมกันยังไง

ไม่งั้น design pattern หลายๆอัน จะกลายเป็น spaghetti code อีก

–

เราจึงต้องมีการคุยเรื่อง “software architecture” ว่าจะให้ design pattern เหล่านั้น อยูร่วมกันยังไง

โดยคำว่า “architecture” นั้น Robert C. Martin ได้ให้ความหมายสั้นๆว่า

“how the things work”

หรือแปลว่า “ทำอย่างมันทำงานร่วมกันยังไง?” นั่นเอง

–

เมื่อเรา “ตกลง” กันแล้วว่า design pattern ทุกอย่างที่เราจะใช้ในโปรแกรมของเรา

“ทำงานร่วมกัน” ยังไงแล้ว เราก็จะไม่เกิด spaghetti code

–

แล้วถ้า “การทำงานร่วมกัน” ของ design pattern มันเริ่ม “เยอะขึ้น”

จนการวาดภาพว่า “how the things work” หรือ software architecture เริ่มซับซ้อนหล่ะ

ก็แปลว่า โปรแกรมเราเริ่มแก้ปัญหาหลายอย่างมากขึ้นจนกลายเป็นเป็ด

เราควรแยกโปรแกรมออกจากกัน เพื่อความชัดเจนในการแก้ปัญหาของโปรแกรมแต่ละตัว

(หรือถ้ายุคนี้ เค้าชอบใช้คำว่า microservice ซึ่งมันก็คือเรื่องเดียวกันนี่แหละ)

–

สุดท้ายนี้ เอาตัวอย่าง software architecture มาให้ดูซักอัน

จะเห็นว่าไม่มีอะไรเยอะเลย เพราะ software architecture ต้อง “simple”

–

สวัสดีครับ

–