สัปดาห์ที่แล้วผมเขียนเกี่ยว methods ที่มี return values ตรงกัน และทำให้โค้ดง่ายขึ้น แตเกิดขึ้นยังไง? Refactoring ที่ถูกต้องทำให้โค้ดง่ายขึ้นยังไง? Abstraction ดีคืออะไร Abstraction แย่คืออะไร? หมายความว่าไม่ได้แค่จัดเรียงโค้ดตามลำดับจนได้ quality software
ถ้าเรียนรู้ ทำไม เทคนิคเหล่านี้ทำงาน คุณจะเข้าใจได้ดีขึ้นว่าโค้ดไหนต้องช่วยเหลือ และใช้เครื่องมือที่ถูกที่จุดสำคัญ
ปัญหายากที่สุดใน software development คืออะไร?
"มีปัญหายาก 2 อย่างใน Computer Science: cache invalidation และ naming things."
– Phil Karlton
คำพูดนี้ ทุกที่ แตจริงมีปัญหายากกว่าใน real-world: จัดการ complexity (ความซับซ้อน) Complexity มีหลาย definitions แตใจคือ ความซับซ้อนของโปรแกรม = ปริมาณสิ่งที่ต้องเก็บในหน้าคิดขณะทำงาน
เขียนซอฟต์แวร์มากขึ้น เก็บในหัวได้มากขึ้น แตแม้ dev ดีที่สุดก็มีขีดจำกัด ถ้าโปรเจกต์ซับซ้อนเกิน คุณ overload หัว เริ่มลืมพื้นที่ต่างๆ ของโปรแกรม และ bugs แย่ที่สุดเกิดตอนเปลี่ยนส่วนหนึ่งโดยไม่รู้ผลกระทบต่อส่วนอื่น
ลดความซับซ้อนผ่าน Assumptions (ข้อสมมติ)
ถ้ามี photographic memory จำได้ว่าส่วนต่างๆ เข้ากันยังไง bugs จะน้อยกว่า หน่วยความจำยากสร้าง แตได้ประโยชน์เท่าเทียมจากการโฟกัสอย่างเดียวในเวลาเดียวกัน
Best practices หลายอย่างเกี่ยวกับลดจำนวนสิ่งที่ต้องเก็บในหัว ตัวอย่าง:
Consistency ใน return values = คิดแค่จัดการชนิดข้อมูลเดียว แทนที่จะต่างกันในสถานการณ์ต่างๆ
Abstraction = ซ่อนโค้ดด้านหลัง interface เรียบง่าย ด้วย abstraction ดี คุณคิดแค่ว่ามันควรทำงานยังไง ไม่ต้องกังวลภายใน
Testing = ป้องกันการทำลายโค้ดส่วนอื่นขณะทำงานส่วนนี้ สมมติว่าสิ่งที่ทำลายโดยไม่ได้ตั้งใจจะถูกจับได้ โฟกัสโค้ดที่ทำงาน แก้สิ่งที่แตกภายหลัง
Test-Driven Development = ช่วยเขียนโค้ดทำงานแบบที่คาดหวัง เขียน simplest implementation ที่ผ่านทดสอบ ถ้า simple เกินไป ทดสอบจะจับได้
ใช้เทคนิคเหล่านี้ถูกที่ถูกที่ คุณทำ assumptions ได้ดี ด้วย assumptions นี้ ไม่ต้องเก็บในหัวมาก เขียนโค้ดดี reliable มากขึ้น เพราะไม่กังวลหลากหลายผลกระทบ
แต่ใช้ผิดที่ จะ ซ่อน โค้ดที่ต้องมองเห็น ด้วยการซ่อน assumptions ที่ทำอาจผิด ทำให้แตกง่ายขึ้น!
นั่นคือเหตุผลที่ bad abstractions แย่กว่า no abstraction และไม่ได้แค่โยน "extract method" จนโค้ดกลายดีโดยอัตโนมัติ
Refactoring ถูกที่ ถูกที่
โค้ดชัดเจน = โค้ดที่โปร่งใสว่ากำลังทำอะไร โชว์สิ่งที่ต้องรู้ สำคัญไม่แพ้การซ่อนสิ่งที่ไม่ต้องรู้ ตอน refactoring หรือใช้ best practices ควรคิดถึงโค้ดที่ได้ และช่วยลด complexity ได้ดีแค่ไหน ช่วยให้โค้ดอื่นทำ assumptions ที่ลดความซับซ้อนได้? หรือฝังความรู้สำคัญไว้หลัง interface ที่ simple เกินไป?
