Patterns Describe Code

ก็พอดี มีคิวต้องไปช่วยสอน Design Patterns ให้กับสมาคมโปรแกรมเมอร์ไทย

ก็เลยได้มีสติมาเรียบเรียงเรื่องที่จะพูด

–

จริงๆเรื่องนึงที่ผมชอบได้ยินจากเจ้านายเก่าผมบ่อยๆคือ

“ปัญหาของเรา (โปรแกรมเมอร์ไทย) คือไม่มี modeling”

–

คำพูดนี้ค้างอยู่ในใจมานานพอควร (นานจนแทบลืมนึกถึงมันไปแล้ว…)

แต่ก็เพราะต้องมาสอนไอ้ Design Patterns นี่แหละ

ทำให้คิดถึงคำนี้มันขึ้นมาได้

–

คำพูดนึงที่ผมชอบใช้ในการอธิบายว่าเขียน code คืออะไรคือ

“เรา describe วิธีการประมวลผลข้อมูล ของโจทย์นั้นๆ

เป็นภาษา ที่สามารถ execute บน machine ได้”

คำว่า “describe” จริงๆ อยากแปลว่า “พรรณนา”

–

ถ้าผมใช้คำว่า พรรณา แปลว่า ภาษาที่เราใช้ต้องวิจิตร

ต้องไพเราะ น่าอ่าน สบายตา เข้าใจง่าย

พอพูดถึงตรงนี้ ก็คิดถึงคำพูดอีกคำขึ้นมา

“Working Hard to Keep it Simple”

คำพูดนี้ รู้สึกเป็น key note ของ Martin Odersky

ที่พูดเกี่ยวกับภาษา Scala (ลอง search google ดูได้)

เราต้องทำงานหนัก ในการพรรณาผ่าน source code

เพื่อให้มันอ่านง่าย จะ describe วิธีการประมวลผลข้อมูลของโจทย์นั้นๆ

เหมือนที่  Martin ได้กล่าวไว้

–

แต่ไม่ใช่เรานั่ง มโน พรรณาอย่างเดียวกับ Source Code มันถึงจะเข้าใจง่ายได้

การเขียนนิยาย ก็มีโครงวิธีการเขียน

การเขียน code เพื่อ พรรณา วิธีการประมวลผลข้อมูลก็เช่นกัน

จำเป็นต้องมี “โครง”

–

คำว่า “โครง” ในที่นี้ อาจจะ imply ได้ถึง

• Modeling (ที่เจ้านายเก่าผมใช้)
• Structure หรือโครงสร้างของ Package ใน Project
• Design Patterns
• Software Architecture

คือจะเรียกอย่างไรก็สุดแล้วแต่ แต่เราต้องมี “ไอ้เหี้ยนี่”

ถ้าไม่มี “ไอ้เหี้ยนี่” จะเกิดอาการ “แมร่งรก”

–

ยกตัวอย่างอาการ “รก”

เคยทำ Project ที่ใช้ Framework ตามแนวคิด MVC มั้ยครับ?

ร้อยทั้งร้อย ก็น่าจะเคย (ใครไม่เคยนี่ Noob ขริงๆ)

–

เคยยัดงาน Batch Load Data จาก Excel ลง DB

ไปใน MVC project มั้ยครับ???

เละมั้ยครับ???

รกมั้ยครับ???

–

ถ้าบอกว่าไม่รก Software ตัวนี้ maintain มากี่ปีแล้วครับ

หรือ “เช็ดแล้วทิ้ง เช็ด เช็ด เช็ด เช็ดแล้วทิ้ง…”

–

พอยัด Batch Load Data จาก Excel ลง DB

มันก็จะเกิดอาการ…… จะเอา View ไปทำอะไร, Controller ทำอะไร

แล้วให้ Model ทั้ง แงะ data ของจาก Excel

Model Transform Data ให้พร้อมลง DB

และ Model ยัด Data ลง DB

สรุปก็คือ “Model บวม” เริ่มกลายเป็นป่าดงดิบ…

–

พอกลายเป็นป่าดงดิบ แล้วไม่มี Automate Unit Test คุม

ก็ชิบหายสิครับ เข้าตำรา

“เช็ดแล้วทิ้ง…”

–

จะเห็นว่า “งาน Batch ที่จะโหลด Data จาก Excel ลง DB”

ใช้ Pattern ของ MVC ไม่ได้

จะเห็นว่าเขียนไปแล้ว Code บวมชัวร์ (บวมตรง Model)

–

ทีนี้ จะทำเยี่ยงไร???

new Project สิครับ เปลี่ยน structure ใหม่

จาก package ที่สร้างเป็น MVC เป็นก็เป็น ETL

• Extract => แงะ Data ออกจาก Excel
• Transform => แปล Data เป็น ก้อนที่พร้อมยัดลง DB
• Loading => ยัดลง DB

ถ้าแบ่ง package แบบนี้ code ก็จะไม่รก ไม่มีอาการบวม

เพราะแค่บวม เราก็ไม่อยากแก้ อ่าน class นั้นแล้ว

เพราะกลัวมือไปโดนแล้วทำอะไรพัง…

–

ดังนั้น ก่อนเขียน code

ให้เข้าใจ model การทำงานของ Process ที่จะ automate นั้นๆ

หรือโจทย์นั้นๆนั่นเอง

แล้วจึงเลือกว่าจะวางโครงสร้างแบบไหน? (วาง Pattern แบบไหน?)

แล้ว Pattern นั้น แก้ปัญหาอะไร ตรงกับที่เราต้องการมั้ย…

–

ถ้า Pattern ดี code ที่เขียนจะเป็นระเบียบ ไม่รก ไม่กินแรง

และที่สำคัญที่สุด “define unit test ได้”

–

เช่นโจทย์โหลด data จาก excel ลง DB

วิธีวาง unit test

• Extract => ตรวจว่าดึงข้อมูลจาก excel ออกมาได้ถูกต้อง (ตรวจแค่ data ใน mem ตรงกับใน excel)
• Transform => ตรวจว่า data ที่ดึงมา แปลงเป็นก้อนสำหรับยัดลง db ได้ถูกต้อง (ตรวแค่ใน mem กับก้อนที่จะยัดลง db ว่าตรงกัน)
• Loading => ตรวจแค่ว่า ก้อนนั้นยัดลง db ได้

–

จะเห็นว่าถ้าเราใช้ MVC แก้โจทย์ โหลด data จาก excel ลง DB

จะเกิดอาการ Model บวม เมื่อ Model บวม ก็จะเขียน unit test ไม่ถูก

สุดท้าย ทุกอย่าง พันกันไป จน “ชิบหาย” หมด

–

แต่ถ้าเราเลือก pattern ได้ตรง

ดูแค่ชื่อ pattern เราจะนึกภาพออกแล้ว

ว่าใน code ใน class ตาม pattern นั้นต้องทำอะไร…

–

สวัสดีครับ

–