รูปแบบของ 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 การทำงานเดิม ๆ ไปหลาย ๆ ที่ นั่นคือเรากำลังเพิ่มความซับซ้อนให้กับระบบ ทดสอบก็เยอะขึ้น แก้ไขก็เยอะขึ้น เมื่อเกิดปัญหาเรื่องเดียวกัน ก็ใช้เวลาแก้มากขึ้น หรือบ่อยครั้งพบว่า แก้ไขไม่ครบ บางคนอาจจะบอกว่า มีส่วนนี้ด้วยหรือ ? ดังนั้นลด ละ เลิกเถอะนะ รู้ว่ามันง่าย แต่ผลกระทบมันเยอะกว่านะ

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

บ่อยครั้งพบว่า นักพัฒนาจะเขียน 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 แย่ ๆ ดังนั้นได้เวลาศึกษาเพิ่มเติมแล้วนะครับ