วันนี้เจอประโยคทองจากเจ้านายเข้าไป ซึ้งน้ำตาแทบไหล

“Not just easier to maintain but need to be easier for enhancement..”

ซอฟแวร์ที่เรากำลังทำๆ กันอยู่นี่เราไม่มีทางรู้ได้เลยว่ามันจะมีอายุเท่าไหร่ ที่สำคัญมันจะถูกต่อเติมอะไรเข้าไปบ้าง โปรแกรมบางตัวมีอายุมากกว่าสิบปี วันหนึ่ง mobile กำลัง hit ลูกค้าอาจจะถามว่า เอาขึ้น BB นี่ทำได้มั้ย เกิดเราบอกทำไมไ่ด้ หรือต้องใช้สองปี นี่เสร็จไม่ทันรับประทาน โลกของการพัฒนาอาจจะซับซ้อน โลกธุรกิจก็ซับซ้อนไม่ต่างกัน ลองดูอย่าง tablet computer ไมโครซอฟต์มีโอกาสทำตลาด มาตั้งนาน อยู่ๆ แอ๊ปเปิลก็มาคว้าพุงปลาไปกินซะงั้น

การเพิ่มฟีเจอร์ได้ง่ายๆ บางทีมันอาจจะมีความสำคัญทางธุรกิจมากกว่า การแก้ไขได้ง่ายเฉยๆ นะ ผมว่ามันเป็นอีกขั้นของ maintainability เหมือนเป็นขั้นสอง มันต้อง maintain ได้ก่อนถึงจะเพิ่มฟีเจอร์ได้ ไปทางเดียวกัน แต่ไม่เหมือนกัน แต่สิ่งที่เราต้องเข้าใจให้ได้ก่อนก็คือ คำว่า “แก้ง่าย” นี่ไม่ใช่ “ทำเผื่ีอ” ไม่เหมือนกัน ผมว่า

แก้ง่าย = Simple, เพิ่มง่าย = Open

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

Open
แปลว่า เปิดกว้าง คือไม่ยึดติดว่า จะต้องเป็นแบบนั้นแบบนี้ เรื่องนี้อธิบายได้ยาก ที่ดูจะเป็นรูปธรรมที่สุดน่าจะเป็นตัวอย่างจากบทที่หนึ่งของ Head First : Design Patterns เขาว่า ถ้าเราทำ class เป็ด เราอาจจะได้เป็น (ขอเป็น Java ละกัน ถนัดดี)

public class เป็ด extends สัตว์ปีก
{
   public void วิ่ง() {
      ...
   }

   public void บิน() {
      ...
   }

   public void ว่ายน้ำ() {
      ...
   }
}

public class เป็ด_ไทย extends เป็ด
{
}

public class เป็ด_เทศ extends เป็ด
{
}

ทีนี้มาวันหนึ่งลูกค้าบอกอยากได้ เป็ดยาง เสร็จเลย เห็นเป็ดยางบินได้ก็วันนี้แหละ อย่างนี้เรียกว่า ไม่เปิดกว้าง (ต่อการเพิ่มขยาย) หรือวันหลังเจอเป็ดปักกิ่งเข้าไปจะทำยังไง

เอาแค่นี้ก่อน พอเป็นน้ำจิ้มให้ไปคิดกันต่อ สนุกดี

Links
http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124