เมื่อมีการพูดถึงความซับซ้อนของ sourcecode ที่เหล่า developer พัฒนาขึ้นมา
มักจะสนในไปที่ Cyclomatic complexity นั่นคือสนใจไปที่
ความซับซ้อนในระดับของ class และ method
แต่ในความเป็นจริงมันยังมีความซับซ้อนในรูปแบบอื่นๆ อีกนะ เช่น
- ความซับซ้อนในการ refactor code
- Big-O notation
มันทำให้เรามีมุมมองอื่นๆ ที่กว้างขึ้น
เริ่มด้วยเรื่องของ Big-O Notation
ถ้าใครที่เรียกสาย Computer Science/Software Engineering น่าจะพอได้ยินมาบ้าง
ส่วนผมน่าจะเคยได้ยิน เรียน และ ก็ตกไปเรียบร้อย !!
นั่นคือ Big-O ในพวก Algorithm ต่างๆ ตัวอย่างเช่น
- Algorithm ที่ดีที่สุดควรมี Big-O เป็น 1 เขียนแทนด้วย O(1)
- สำหรับพวก Hash Table นั้น มีค่าการอ่านข้อมูลเป็น O(1)
- สำหรับพวก List, Array มีค่าการค้นหาข้อมูลเท่ากับขนาดของมัน คือ O(n)
ดังนั้นโครงสร้างข้อมูลที่ developer นำไปใช้งาน
ควรใส่ใจเช่นกันนะครับ ว่าไหม ?
นำเรื่อง Big-O มาเกี่ยวกับการเปลี่ยนแปลง code ได้อย่างไร ?
ลองคิดดูกันหน่อยว่า
คำถาม
ในการเปลี่ยนแปลง source code นั้น กรณีดีที่สุดต้องมีค่าการเปลี่ยนแปลงเท่าไร ?
คำตอบ
มีค่าการเปลี่ยนแปลง O(1)
นั่นคือมีการเปลี่ยนแปลง source code เพียง file/class/methdo เดียวเท่านั้น
นั่นแสดงว่า source code ของคุณดีมากเลยนะ
นั่นแสดงว่า developer เคารพในแนวคิด Single Responsibility Principle และ Open/Closed Principle
ซึ่งมันเป็นแนวคิดในฝันของใครหลายๆ คน หรือ ทุกๆ คน !!
แต่ในโลกความจริง มักไม่เป็นเช่นนั้นสินะ ใช่ไหม ?
ตัวอย่างเช่น
SQL ที่เขาบอกว่ามันคือ มาตรฐานเลยนะ
แต่เมื่อคุณเปลี่ยนชนิดของ database เท่านั้นล่ะ
ค่าในการการเปลี่ยนมีค่าเป็น O(n) ทันที
โดยที่ n คือ จำนวน SQL ที่ต้องแก้ไข
…. สิ่งนี้คุณไม่ต้องการใช่ไหมครับ …
เพราะว่าตอนที่วาง Architecture ออกแบบระบบ วิเคราะห์ระบบ
เขาบอกไว้ว่า ถ้าเปลี่ยน database มันจะไม่มีปัญหา
แต่เผอิญว่าไม่เคยทดสอบเลยนะสิ
ลองมองมาที่ระบบของเรากันบ้าง
คำถาม
ปัจจุบันระบบของเรามีค่าการแก้ไขอยู่ที่เท่าไร ? O(1), O(n) หรือ n ยกกำลังสอง ?
คำตอบ
….
เชื่อได้เลยว่า ใครมันจะไปรู้ล่ะ !!
รู้อย่างเดียวว่า source code มันแย่
- มี dependency กับระบบต่างๆ เพียบ ซึ่งมันโตแบบเส้นตรง นั่นคือ O(n)
- ในแต่ละ file/class/method มันก็มีส่วนที่เป็น dependency อีกเพียบ O(n)
- ยิ่งถ้ามีหลายระบบ จะพบว่ามันมีส่วนที่ซ้ำๆ และ เกี่ยวข้องกันเพียบ O(n)
- และอื่นๆ อีกมากมาย
ทำให้เราพบว่า
ระบบงานส่วนใหญ่มันจะมีค่าของการเปลี่ยนแปลงอยู่ที่
โดย n คือจำนวน entity ใน source code ที่เราเข้าไปแก้ไข
ซึ่งเราต้องทำการแก้ไขเยอะมากๆ !!!
ห่างจากสิ่งที่คาดหวังไว้ไกลมากๆๆๆๆๆๆๆ
นี่มันคือ Oh Big จริงๆ นะ
ถ้าถามว่ามันจะมีอะไรเยอะกว่านี้ไหม ผมตอบไม่ได้
แต่สิ่งที่พบจะตอบได้ก็คือ
มีสิ่งหนึ่งที่สามารถช่วยในเรื่องการตัดสินใจ
ว่า developer จะทำอะไรกับ source code ก็ตาม
ให้พึงคิด ตระหนัก ไว้เสมอว่า ค่าในการเปลี่ยนแปลง
จะต้องเป็น O(1) หรือ O(n) เท่านั้น
มันขึ้นอยู่กับว่า ระบบที่เกี่ยวข้องมันมีค่าใช้จ่ายสูงเท่าไร
ถ้าค่าใช้จ่ายสูงมากๆ จะต้องเป็น O(1) เท่านั้น
นี่คือ แนวปฏิบัติที่ดี ซึ่งของแนะนำครับ ง่ายจริงๆ
เพราะว่า การตามมาแก้ไข มันเป็นเรื่องที่ยาก และ สิ้นเปลืองมากๆ ครับ
