รูปแบบของ code แย่ ๆ ที่มักพบเจอ

ช่วงวันหยุดนั่งดู code เขียน code ไปเรื่อย ๆ
ได้เห็นรูปแบบของ code ที่น่าสนใจ
ไม่ใช่เรื่องของการตั้งชื่อ
แต่มันคือ รูปแบบการทำงานของ code
แน่นอนว่าเป็น code ที่สามารถทำงานได้ดีตามที่ต้องการ

แต่ดันเป็น code ที่มีคุณลักษณะเฉพาะตัว เช่น
ทำความเข้าใจยากมาก
ส่วนต่าง ๆ ของระบบสามารถแก้ไข state หรือค่าได้โดยตรง
แน่นอนว่าว่าค่านี้ ใช้ทั้งระบบ !!
แก้ไขที่หนึ่งกระทบที่อื่น ๆ อีกมากมาย

ใช้เวลาในการเพิ่ม feature เยอะขึ้น

เมื่อเกิดปัญหาบน production แล้วการค้นหาจุดเกิดเหตุยากมาก ๆ

จึงทำการสรุปสิ่งที่เจอไว้นิดหน่อย

Global state/variable

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

เมื่อต้องมานั่งอ่านและทำความเข้าใจ code
พูดได้เลยเลยว่า ไม่ง่ายเลย

Code duplication

มักเจอประจำกับ code ที่ซ้ำ ๆ
มักจะเจอกับนักพัฒนาแบบ copy-and-paste development
ทั้ง copy จากงานหรือเดียวกัน
หรือ copy มาจากระบบอื่น ๆ รวมทั้งจาก internet
หลาย ๆ คนเรียกว่า การ reuse code !!

ถ้าทำการ copy การทำงานเดิม ๆ ไปหลาย ๆ ที่
นั่นคือเรากำลังเพิ่มความซับซ้อนให้กับระบบ
ทดสอบก็เยอะขึ้น
แก้ไขก็เยอะขึ้น
เมื่อเกิดปัญหาเรื่องเดียวกัน ก็ใช้เวลาแก้มากขึ้น
หรือบ่อยครั้งพบว่า แก้ไขไม่ครบ
บางคนอาจจะบอกว่า มีส่วนนี้ด้วยหรือ ?

ดังนั้นลด ละ เลิกเถอะนะ
รู้ว่ามันง่าย แต่ผลกระทบมันเยอะกว่านะ

ไม่สนใจหรือใส่ใจเรื่องการจัดการ dependency ต่าง ๆ

บ่อยครั้งพบว่า
นักพัฒนาจะเขียน code ไปเรื่อย ๆ
ยกตัวอย่างเช่น
ถ้าเรื่องที่ 1 สำเร็จจะทำเรื่องที่ 2
ถ้าเรื่องที่ 2 สำเร็จจะทำเรื่องที่ 3
ถ้าเรื่องที่ 3 สำเร็จจะทำเรื่องที่ 4
code ที่ออกมาต้องเป็น if ซ้อน if ซ้อน if ไปเรื่อย ๆ แน่นอน
ก็ให้เกิด code แต่ละส่วนผูกมัดกันอย่างแรง
บางครั้งเราจะเรียก code เหล่านี้ว่า Spaghetti code

จะอ่านและเข้าใจก็เหนื่อย
จะทดสอบก็ยาก
จะแก้ไขก็ลำบาก
ไม่มีใครอยากไปยุ่งกับมัน

ดังนั้นแนะนำให้แยกแต่ละส่วนการทำงานหรือแต่ละเรื่องออกจากกัน
นั่นคือการ dependency ต่าง ๆ ออกจากกัน
ทดสอบแยกกันไป
จากนั้นจึงสร้างส่วนที่รวบรวมส่วนต่าง ๆ เข้าด้วยกัน
ถ้ามีการเปลี่ยนแปลง แนะนำให้สร้างส่วนที่รวบรวมใหม่
มันคือ business/service layer นะครับ
ซึ่งมันไม่สามารถ reuse ได้เลย
การมานั่งแก้ไขไม่สนุกนะ

แนะนำให้ศึกษาเรื่อง SOLID principle เพิ่มนะ

Code มันอ่านยาก

ไม่ใช่บอกว่า การตั้งชื่อไม่ดีนะ
แต่กำลังบอกว่า code มันอ่านยาก
เช่นเขียน code เพียงบรรทัดเดียว แต่เข้าใจยากมาก
หรือบางครั้งการตั้งชื่อดีมาก แต่ logic การทำงานยากและซับซ้อน
หรือทำการเข้ารหัสทาง logic ไว้ !!
บ่อยครั้งมักจะมี abstraction layer ของ code ที่ผิด

ดังนั้นสิ่งที่ควรทำและฝึกคือ
การทำ pair programming และ code review กับคนอื่น ๆ ในทีม

ไม่กล้าแก้ไข code เพราะว่าไม่รู้ว่า จะกระทบอะไรบ้าง !!

นี่คือปัญหาหลัก ๆ เลย
ดังนั้นต้องมีสิ่งที่ทำให้แน่ใจ มั่นใจว่า
ถ้าทำการเปลี่ยนแปลง code แล้วมันยังทำงานได้เช่นเดิม
หนึ่งในนั้นคือ ชุดการทดสอบแบบอัตโนมัติ
ที่เราให้ความเชื่อมั่นนะ

แต่ code ที่แย่ ๆ ส่วนใหญ่มักจะไม่มีนะสิ !!
ในการทำงานแต่ละคนจะบอกว่า
เราจะไม่แตะต้อง code ที่เราไม่ได้เขียน
แนวคิดเหล่านี้มันน่ากลัวมาก ๆ

ดังนั้นก่อนจะทำการแก้ไข code ใด ๆ
ต้องสร้างชุดการทดสอบแบบอัตโนมัติขึ้นมาก่อนนะครับ
รู้ว่ามันยากแต่ก็ต้องทำ
หรือว่าคุณไม่ทำการทดสอบระบบกัน ?

สุดท้ายแล้ว

สิ่งต่าง ๆ เหล่านี้คือสิ่งที่นักพัฒนาต้องเรียนรู้เพื่อที่จะปรับปรุง
แน่นอนว่าคือปัญหาที่คุณต้องต่อสู้
มิเช่นนั้นมันจะกลับมาทำร้ายคุณแน่นอน
เหมือนที่เป็นอยู่ตอนนี้
การทำงานเหมือนเดิมก็เจอปัญหาเดิม ๆ
ดังนั้นได้เวลาเปลี่ยนแปลงแล้วนะ

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