วันนี้อ่านบทความเรื่อง The software architect fallacy
โดยสิ่งที่น่าสนใจคือ ภาพประกอบการอธิบายในบทความ
ซึ่งใช้การสร้างเรือมาอธิบายเรื่องของการ ออกแบบและสร้างระบบงาน
เป็นการพัฒนาเป็นรอบ ๆ ไป ตามความต้องการ
มาดูกันว่า ใครยังเป็นแบบนี้กันอยู่บ้าง ?
รอบที่ 1 ทำการสร้างเรือตกปลา ที่รองรับคนได้ 2 คนก็พอ
เป็นการสร้างให้รองรับ customer หลักก่อนเลย
จึงสร้างเรือดังภาพขึ้นมา
เมื่อผู้ใช้งานได้ลองใช้งานแล้ว
ก็มี feedback กลับมาว่า ในเรือน่าจะมีที่เก็บปลาและเครื่องดื่มด้วยนะ
ดังนั้นทีมพัฒนาจึงทำการเพิ่มความสามารถของเรือตามที่ต้องการ
แสดงดังรูป
รอบที่ 2 ทีมคิดว่า ถ้าที่เก็บเป็นแบบนี้ จะไม่สามารถเก็บความเย็นได้นานเพียงพอ
ดังนั้นจึงต้องการที่ทำความเน็นได้นาน ๆ
ต้องใช้ไฟฟ้าเข้ามาด้วย
จึงต้องมีการติดตั้ง battery เข้าไปในเรือพร้อมกับตู้เย็น ดังภาพ
รอบที่ 3 เมื่อลูกค้านำไปใช้งานอีกรอบ พบว่าการออกไปตกปลาทั้งวัน ต้องเจอแดดร้อน ๆ
ดังนั้นจึงต้องการหลังคา เพื่อกันแดด
แต่ผลที่ตามมาคือ เมื่อความเร็วของเรือสูงขึ้น
หลังคาจะต้านลม ทำให้ช้าลง
รวมทั้ง motor ของเรือมันเล็กอีกด้วย
รอบที่ 4 ในการออกไปตกปลา ต้องเจอกับความมืดได้
ดังนั้นจึงต้องการเพิ่มไฟเข้ามา
เพื่อส่องสว่างในกับเรา
ดังนั้นทีมก็แก้ไขด้วยการเพิ่มหลอดไฟ และ เพิ่ม plug เข้าอีก
เป็นการตัดสินใจที่ถูกต้องไหมนะ !!
รอบที่ 5 เนื่องจากมีการใช้ไฟ และ ตู้เย็น บนเรือ ผลที่ตามมาคือ battery มีขนาดเล็กไปแล้ว ไม่เพียงพอ
ดังนั้นจึงต้องทำการเพิ่มขนาดของ battery
เป็นการเพิ่ม technical debt เข้าไปเล็กน้อยใช่ไหมนะ ?
รอบที่ 6 ตอนนี้นำหนักเรือมากขึ้น ส่งผลให้ความเร็วของเรือตกลงไป ทำอย่างไรให้เร็วขึ้น ?
เริ่มเรื่องของ Make it Fast แล้ว
ง่าย ๆ ก็ขยายขนาดของ motor ให้ใหญ่ขึ้นสิ
ผลที่ตามมาคือ เมื่อเร็วขึ้น เรือจะเริ่มไม่นิ่ง
รอบที่ 7 เริ่มต้องการห้องอาบน้ำ !!
รอบที่ 8 ตอนนี้รู้สึกว่า เรือจะเล็กไป อยากให้รองรับคนได้มากขึ้น
ทำอย่างไรกันดี ?
รอบที่ 9 ตกปลาแล้วง่วง อยากมีที่งีบหน่อยนึง !!
มาถึงตรงนี้ คิดเห็นอย่างไรกันบ้าง ?
สำหรับ product นี้ !!
