Over-engineering

ก่อนจะเข้าเรื่อง over-engineering ในเชิงของการเขียนโปรแกรม ขออธิบายคำนี้ก่อน ถ้าเปรียบเทียบคำนี้กับสำนวนไทยน่าจะเป็น “ขี่ช้างจับตั๊กแตน” คือเป็นการทำงานที่มากเกินความจำเป็นเพื่อให้ได้ผลลัพธ์นั้นๆ ลองนึกภาพว่าไปซื้อรถสปอร์ตอย่างเช่นแลมโบกินีเพื่อมาขนข้าวไปโรงสี ซึ่งก็สามารถขนได้เหมือนกันเพียงแค่บรรทุกได้น้อยและค่าบำรุงดูแลรักษาแพงใหนจะค่าน้ำมันอีก ด้วยความคิดนี้หากผมพบเจอคนที่ไม่ได้ใช้รถบรรทุกมาขนของผมจะมองว่าเป็นการกระทำที่ over-engineering เนื่องจากผมมองว่าสิ่งที่ได้ไม่คุ้มกับสิ่งที่เสียไป

ปัญหาคือจะรู้ได้อย่างไรว่าเรากำลังขี่ช้างจับตั๊กแตน? แล้วจะรู้ได้อย่างไรว่าแค่ใหนพอดี? ซึ่งถ้าเรามองไปยังอีกฝั่งเขาอาจจะบอกว่า “ก็มีรถคันนี้อยู่แล้ว และเป็นการขนของชั่วคราว ถ้าเขาต้องไปซื้อรถใหม่มันก็สิ้นเปลืองกว่า อย่างเช่นย้ายหอพัก เราก็ไม่ได้ย้ายกันทุกเดือน” ดังนั้นด้วยสภาพแวดล้อมที่เขาอยู่เขาเลยคิดว่าสิ่งนั้นคือสิ่งที่เหมาะสมที่สุดแล้ว เรื่องนี้ไม่มีอะไรถูกผิดครับ จะมีก็เพียงแต่เราเอาความคิดของเราไปใช้วัดคนอื่นแค่นั้นเอง

คราวนี้มาลองมองในมุมของการเขียนโปรแกรม อะไรคือ over-engineering? ถ้าจากคำนิยามข้างต้นแสดงว่าจะต้องมีคนหนึ่งที่คอยตัดสินว่าอะไรควรหรือไม่ควร อะไรมันเกินไป ซึ่งถ้าเป็นมุมมองของผม หัวใจหลักจริงๆ ของการเขียนโปรแกรมมันคือกระบวนการนำข้อมูลจากผู้ใช้มาจัดเก็บไว้ แล้วรอให้มีเหตุการณ์บางอย่างที่ทำให้ข้อมูลนี้เปลี่ยนสถานะเท่านั้นเอง เลือกเครื่องมือที่เราจะใช้ หาอันที่ถูกใจแล้วก็ตั้งโจทย์เพื่อฝึกให้ชำนาญ เพื่อที่จะได้ไปเน้นที่ business มากกว่าไปทุ่มเวลาให้ framework และต้องดูแลรักษาง่าย นี้คือสิ่งที่ผมคิดว่ามันเป็นผลดีต่อระบบ หากเกินกว่านี้ผมจะถือว่า over-engineering

ความเรียบง่าย

เวลาส่วนมากที่ผมเสียไปกับการเขียนโปรแกรมมีสองอย่าง หนึ่งคือศึกษาการทำงานจากโค้ดที่ดูรุงรัง ตีกันมั่วไปหมด (spaghetti code) และสองคือศึกษา Framework ที่ใช้ ซึ่งแต่ละบริษัทก็ใช้ไม่เหมือนกัน ถึงใช้เหมือนกันแต่เขียนคนละสไตล์ (ขึ้นกับว่าคนวาง framework ไปเอามาจาก web ใหน ซึ่งถ้าอ่านจาก document ของ framework ไม่ควรต่างกันขนาดนั้น) บางทีหนักหน่อยมีการเขียน framework เองซึ่งเวลาเกิดปัญหาบางอย่างเราไม่สามารถหาใน google ได้ ดังนั้นความเรียบง่ายมันจะช่วยในเรื่องของการดูแลรักษาระบบเมื่อคนเขียนส่วนนั้นลาออกไปแล้ว เมื่อดูแลรักษาง่าย อ่านโค้ดแล้วเข้าใจได้ทันที ต่อไปถ้าเราจะขยายระบบหรือจูนก็ไม่มีปัญหาอีกต่อไป ที่พูดมานี้คือผมไม่ได้ห้ามใช้ framework แค่อยากให้ใช้เท่าที่จำเป็นเช่น หลังบ้านใช้ spring mvc หน้าบ้านใช้ jQuery, Bootstrap สำหรับผมแค่นี้ก็เพียงพอในการทำงานแล้ว

Design ไม่ควรเผื่ออนาคตจนเกินไป

บ่อยครั้งที่ผมพบว่า คนที่วาง framework จะ design เผื่ออนาคตไว้อลังการมาก อย่างเช่นเตรียมพร้อมให้สามารถรัน business และส่วน frontend แยกส่วนกันได้ เผื่อว่าเราจะต้องสร้าง mobile app มาเรียกก็สามารถต่อกับ business ได้เลย ไม่ต้องไปเขียน service แยก ทั้งๆ ที่ mobile ไม่ได้อยู่ใน requirement แล้วในอนาคตอันใกล้นี้ก็ยังไม่มีวี่แววว่าจะต้องทำแต่เราทำเผื่อไปแล้ว ปัญหาที่ตามมาคือ cost ในการดูแลนั้นสูงโดยใช่เหตุ

ถ้าเป็นกรณีนี้ผมแนะนำให้ไปศึกษา Engineering Blog ของบริษัทใหญ่ๆ เช่น Facebook, Linkedin, Twitter ว่าเขาเริ่มสร้างยังไง แล้ววิวัฒนาการเป็นอย่างไร ตัวอย่างเช่นของ Linkedin เขาก็เริ่มมาจากระบบเล็กๆ พอรันได้ไปซักระยะก็เริ่มีปัญหาแล้วเขาก็ค่อยๆ แก้ปัญหานั้น พอเครื่องมือที่มีให้ใช้ในปัจจุบันไม่สามารถตอบโจทย์เขาได้เขาถึงจะสร้างขึ้นมาเอง

สรุปว่าถ้าเป็นมุมมองผม ผมมองว่างานที่ทำนั้นเป็นงานแบบ Over-engineering เมื่อ

  • งานง่ายๆ แต่เลือกใช้ Framework ที่มี Learning Curve สูงจนทำให้เสียเวลาศึกษานานเกินไป
  • การ Design ระบบอลังการงานสร้างแล้วไม่ได้ตอบโจทย์ทาง Business

ความจริงในใจผมยังมีอีกหลายข้อ ให้เขียนหมดคงจะนาน ผมเพียงแค่ยกตัวอย่างให้เห็นว่ามุมมองของผมที่มีต่อ Over-engineering คือการที่ผมไม่ได้ Focus กับ Business เช่นการมานั่งดูโค้ดที่อ่านยาก การดูแลรักษาโปรแกรมที่มี Architecture อลังการแต่ไม่ตอบโจทย์ต่อการทำงานของลูกค้าเป็นต้น

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s